Source: linux
Hi,
a user reported #1098694 against util-linux: agetty crashes. The
crash is a bug in agetty, but it points to something more
interesting. Let me explain below:
systemd starts serial-getty@%i.service for consoles the kernel deems
active.
Debian's cloud images (even the "nocloud" variants) set these
parameters on the kernel command line:
console=tty0 console=ttyS0,115200 earlyprintk=ttyS0,115200
agetty traditionally exits with EXIT_SUCCESS (after a 10sec delay)
when it cannot read from a terminal it is attached to, for example
because reading from it returns EIO.
This combination of things which all are well-intended, will cause
the following scenario in an apparently popular config:
- cloud image ("nocloud")
- x86 VM
- Hypervisor does not configure a serial port, because you have VGA
anyway
These VMs will every 10sec spawn a new agetty on ttyS0, which causes
some CPU and disk activity, to fail and exit. This repeats every
10sec.
This is *almost* silent; if you don't happen to look into journalctl
at the right moment you'll not see this.
I imagine if thousands of VMs do this, it's going to be a huge waste
of energy on our planet.
~~~~
After looking at this a bit longer, I wondered what happens on
arm64: on arm64, passing console=tty0 console=ttyS0,115200 is also
semi-common, but it seems to have a different effect!
On amd64, cat /sys/class/tty/console/active shows tty0 and ttyS0 in
this configuration.
On arm64, ttyS0 is not added to /sys/class/tty/console/active.
This leads systemd to *not* create serial-getty@ttyS0.service,
thereby avoiding the problem.
I don't know if this caused by some x86 heritage, where the 8250 is
always present, even if non-functional or something. But clearly
even then the kernel seems to know its not really working, as
reading from /dev/ttyS0 gives EIO.
Please consider improving this situation for everyone.
If this needs forwarding upstream, please do so.
I've also filed this against systemd upstream, but I imagine they'll
defer to the kernel not activating the ttyS0 console:
https://github.com/systemd/systemd/issues/36497
Thanks,
Chris
