Description of problem: Hi, I found out that when /dev/hvc0 exists agetty is automatically spawned on it even thought it's not specified on initrd line. I have 4 consoles and I'm using them for different purposes than login. I know I could mask the service, but I'm wondering why is this behavior hardcoded. Version-Release number of selected component (if applicable): systemd-195-15.fc18.x86_64 (also on systemd-44-12.fc17.x86_64) How reproducible: Always Steps to Reproduce: 1. start VM with virtio_console port (-device virtconsole) 2. systemctl status serial-getty 3. cat /run/systemd/generator/getty.target.wants/serial-getty Actual results: ad2) service serial-getty is running ad3) service serial-getty is present Expected results: ad2) service serial-getty is not running (non-existing) ad3) service serial-getty is not auto generated, when not specified on initrd line. Additional info: # cat /proc/cmdline BOOT_IMAGE=/vmlinuz-3.6.10-4.fc18.x86_64 root=/dev/mapper/fedora_atest--guest-root ro rd.md=0 rd.dm=0 console=tty0 rd.lvm.lv=fedora_atest-guest/root console=ttyS0,115200 rd.lvm.lv=fedora_atest-guest/swap vconsole.keymap=us rd.luks=0 rhgb quiet
Because it's defined as a virtual console device, it's treated in the same category as the console ttys - instead of requiring specific configuration, configure it in the absence of any other configuration.
Oh that's why. The thing that bugs me is that only hvc0 is hardcoded there. It doesn't spawn tty on hvc1 hvc2, ... Also the behaviour is new. RHEL5/6 does nothing and you have to modify rc.local in order to get mingetty on hvc*. Currently I solved my problem by masking the hvc0 service. But in case I should need tty on hvc I'd have to unmask and start the service. Or is there another way? Disabling of this service doesn't help as it's marked as 'want' during boot.
The automatic getty happens always only at the *first* device: static const char virtualization_consoles[] = "hvc0\0" "xvc0\0" "hvsi0\0";
This Lennart's blog post explains what happens: http://0pointer.de/blog/projects/serial-console.html Perhaps it does not sufficiently explain *why* spawning getty on the first VM console should be the right thing to do. And apparently the behavior is surprising to some.
Hm, I could have sworn we did this out of the box in the pre-systemd days as well, but I could be wrong.
Yes, we did that in Upstart days too.
I don't think so. I'm using virtual RHEL6 which doesn't spawn anything by default (well it spawns tty2-6 and that's all). (tested today with RHEL6.3, kernel-2.6.32-279.el6 initscripts-9.03.31-2.el6)
But anyway, is this really something to change? I mean, we start gettys on VCs too automatically, so it sounds like the right thing to treat hvcs the same? It's certainly a good idea to give the admin some way to enter his machine if SSH is down...
I have to insist that this is inconsistent, duplicitous and from my point of view bad behavior. And I can explain why: From what I know about consoles they are either specified on the boot line (console=ttyS1 console=hvc0) or there is a default console (on x86 vt/tty). I find out that Xen kernels usually need to use hvc instead of tty since they might/usually use dummy device for vt. But they do that by changing the preferred console in kernel ( https://lkml.org/lkml/2008/4/10/209 ). The beauty of systemd is that it detects the consoles from /sys/class/tty/console/active and automatically spawns the tty on the last one. (thanks for that, guys) Since Xen kernel registers hvc as preferred console, systemd should spawn the console because of this (if not override on the boot line) and not because it's named hvc0. KVM machines usually have a valid tty so hvc is not (currently) registered as preferred console thus (IMO) tty shouldn't be spawned if not set explicitly on the boot line or by enabling of the service by sysadmin. I haven't tried the Xen kernel, but I played with KVM. When I specify on boot line console=hvc1 as last console, systemd spawned tty as expected. Also it spawned another console on hvc0 because it's hard-coded. Still it didn't spawn any console on hvc2 which was also present but is not specified on the boot line nor hard-coded in systemd.