Bugzilla – Bug 941106
Can't log in to text console because Systemd messages clobber text consoles every second if X doesn't work
Last modified: 2024-06-04 08:41:23 UTC
After updating all packages to the latest Tumbleweed, I got a new kernel, had to reboot, and wanted to reinstall the NVidia drivers. But I was never able to even log in (on a text console) because I got messages from systemd every second (or faster): systemd[1]: Stopping User Manager for UID 470... systemd[1]: Stopped User Manager for UID 470. systemd[1]: Starting User Manager for UID 470... systemd[1]: Stopping User Manager for UID 470... systemd[1]: Stopped User Manager for UID 470. systemd[1]: Starting User Manager for UID 470... systemd[1]: Stopping User Manager for UID 470... systemd[1]: Stopped User Manager for UID 470. systemd[1]: Starting User Manager for UID 470... systemd[1]: Stopping User Manager for UID 470... systemd[1]: Stopped User Manager for UID 470. systemd[1]: Starting User Manager for UID 470... etc. Switching to text console 2 / 3 / 4 didn't help: It would immediately switch back to text console 1 with those messages. UID 470 is 'gdm' (the Gnome Display Manager). The message by itself is perfectly legal because X11 didn't work at that time (still trying to use the old NVidia kernel module and X11 driver), but repeating it forever does not make any sense. Basically, this made my system completely unusable: No X11 login, no text console login. I could only fix it with ssh login from another machine. For a normal user, this kind of thing is probably a complete showstopper that would make him reinstall the system.
Created attachment 643305 [details] output of sudo zypper lr --url
Created attachment 643306 [details] output of rpm -qa Updated to latest Tumbleweed (sudo zypper dup) on 2015-08-10 10:30
Created attachment 643307 [details] output of sudo journalctl --since "2015-08-10 09:00"
BTW this happened to me before. It seems to be easy to reproduce: Every time X11 doesn't work and I reboot before trying to reinstall the NVidia drivers, I get this.
Install package syslog-service and be happy ... with this you get /usr/lib/systemd/system/klog.service which indeed uses /usr/sbin/klogconsole to switch console messages to /dev/tty10
I'll reopen this and move to gnome. I think gdm used to have a mechanism to detect crashing X that should prevent it from trying infinitely. Maybe that check got broken somehow.
Better yet, systemd should not try forever to restart *anything*, or at least drastically increase the interval between attempts after a number of failures.
(In reply to Stefan Hundhammer from comment #7) > Better yet, systemd should not try forever to restart *anything*, or at least > drastically increase the interval between attempts after a number of failures. You might set/change DefaultRestartSec in /etc/systemd/system.conf see systemd-system.conf(5) ... or set per service unit the parameters RestartPreventExitStatus= or even harder with Restart= see systemd.service(5)
I've also run into this and I must say it's very annoying. And it's important that the *default* config is something usable. There's no point in knowing which config file to tweak as systemd simply stops you from accomplishing anything at that moment. I see no reason why it couldn't stop after a few tries. Not sure why this was assigned to gnome people...
I reported this 8 years ago. I was brushed aside (which is not a solution, of course), then moved from systemd to GNOME, and years later it was reopened. Is there a solution now? Do we now have a systemd default configuration that avoids this problem? Was there any move to at least increase the restart interval for systemd services that keep failing? Was there at least a local solution for GDM not restarting forever in a one-second interval; which is completely pointless to begin with?