LiveCD's (possibly others, just tested these so far) continually start/stop getty every 10 seconds and fill the journal. Reproducible: Steps to Reproduce:
Created attachment 4241 [details] journal.txt
This is the same in live mode or once installed.
Also same with the LiveDVD's
Yep, I can reproduce... Colin, any thoughts about what's missing ? shouldn't udev handle this..
CC: (none) => tmbAssignee: bugsquad => mageiaSource RPM: getty => systemd
Workaround until the cause is found/fixed. ln /dev/tty0 /dev/getty
CC: (none) => davidwhodgins
Tested workaround echo '#!/bin/bash'>/etc/rc.d/rc.local echo 'ln -s /dev/tty0 /dev/getty' chmod a+x /etc/rc.d/rc.local ln -s /etc/rc.d/rc.local /etc/rc.local
Oops. Copy/paste error. Should have been echo '#!/bin/bash'>/etc/rc.d/rc.local echo 'ln -s /dev/tty0 /dev/getty' >>/etc/rc.d/rc.local chmod a+x /etc/rc.d/rc.local ln -s /etc/rc.d/rc.local /etc/rc.local
Hmm, not sure why that would be started as getty@getty.service (normally it's magically activated by systemd when switching to a tty as getty@ttyN.service (where N is the tty number), but the code inside systemd itself is only ever generating unit names via the "autovt@tty%i" sprintf string so it cannot be generating this internally. When using a serial console a generator may make serial-getty@.service instantiate for that but it doesn't seem like that's the case here. Are there any special kernel command line arguments related to console= or similar used here? For what it's worth I don't see a /dev/getty on any of my systems (mga3 and cauldron), so my first guess is that it really shouldn't be trying to start a getty@getty.service unit at all. Finding out why it's trying to start that in the first pace would be useful. Could you check your /{etc,run}/systemd/system/getty.target.wants/ folders? I cannot for the life of me think what would instantiate this unless it was explicitly enabled. On a side note, the final ln -s step in Dave's instructions above should not be needed with latest systemd.
No special boot options in use, this is right after reboot from default installs from classic isos or live or installed from live isos # ll /etc/systemd/system/getty.target.wants/ total 0 lrwxrwxrwx 1 root root 38 Aug 7 11:11 getty@.service -> /usr/lib/systemd/system/getty@.service # ll /run/systemd/system/getty.target.wants/ ls: cannot access /run/systemd/system/getty.target.wants/: No such file or directory # ll /dev/getty* ls: cannot access /dev/getty*: No such file or directory
Adding Anne too as this affects classic isos aswell.
CC: (none) => ennael1
(In reply to claire robinson from comment #9) > No special boot options in use, this is right after reboot from default > installs from classic isos or live or installed from live isos > > # ll /etc/systemd/system/getty.target.wants/ > total 0 > lrwxrwxrwx 1 root root 38 Aug 7 11:11 getty@.service -> > /usr/lib/systemd/system/getty@.service Ohhhh! That's maybe the problem. The symlink *should* be called "getty@tty1.service" not getty@.service (the symlink destination is correct tho'). I think I know why this happens... So %post scripts in systemd.spec file just do a "systemctl enable getty@.service" because the install line *used* to contain Alias=getty.target.wants/getty@tty1.service, but it no longer does. It now has a generic install rule (actually a patch originally proposed by me, but ultimately written again later by someone else!!). This caused the rule in the spec file to generate the link as you had and then the specifier stuff seems to fallback and automatically use the name of the unit itself and not fail hard when it's used. I consider this an upstream bug that it tries to continue even although the use of the specifiers is invalid in that context. I've fixed the symlink creation in the (just submitted) systemd package - so hopefully this solves this problem. Please let me know (if you want to do a non-real world test, just rename the symlink to getty@tty1.service and reboot - assuming non-live media) It should have much the same effect as what the actual committed fix achieves.
Altering the link does seem to cure the problem after a reboot. journalctl -b | grep -i getty shows only the lines below now.. Starting system-getty.slice Created slice system-getty.slice Is that what you'd expect Colin?
Yup, exactly as I'd expect :) Thanks for the debug info. This only affects fresh installs hence why it's not popped up in cauldron until now! Pretty confident this is now fixed, but I'll leave it up to you to decide when to close.
Thanks Colin, Anne/Thomas could you add the new systemd to any new build please. It could maybe wait for alpha2 at this stage if we don't want to let the release slip
fixed in latest isos
Status: NEW => RESOLVEDResolution: (none) => FIXED