Bug 920648

Summary: Why is agetty spawned automatically on hvc0
Product: [Fedora] Fedora Reporter: Lukáš Doktor <ldoktor>
Component: systemdAssignee: systemd-maint
Status: CLOSED NOTABUG QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: 18CC: johannbg, lnykryn, metherid, mschmidt, msekleta, notting, plautrba, systemd-maint, vpavlin, zbyszek
Target Milestone: ---   
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2013-04-09 11:08:59 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description Lukáš Doktor 2013-03-12 13:38:07 UTC 
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
Comment 1 Bill Nottingham 2013-03-13 20:39:07 UTC 
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.
Comment 2 Lukáš Doktor 2013-03-14 09:50:36 UTC 
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.
Comment 3 Kay Sievers 2013-03-20 12:58:35 UTC 
The automatic getty happens always only at the *first* device:
  static const char virtualization_consoles[] =
      "hvc0\0"
      "xvc0\0"
      "hvsi0\0";
Comment 4 Michal Schmidt 2013-03-20 13:13:18 UTC 
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.
Comment 5 Bill Nottingham 2013-03-20 14:20:57 UTC 
Hm, I could have sworn we did this out of the box in the pre-systemd days as well, but I could be wrong.
Comment 6 Lennart Poettering 2013-03-22 15:32:49 UTC 
Yes, we did that in Upstart days too.
Comment 7 Lukáš Doktor 2013-03-26 15:25:46 UTC 
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)
Comment 8 Lennart Poettering 2013-04-09 11:08:59 UTC 
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...
Comment 9 Lukáš Doktor 2013-04-10 17:52:11 UTC 
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.