Red Hat Bugzilla – Bug 752875
at runlevel 3, only 1 getty is available
Last modified: 2011-12-13 21:31:11 EST
Created attachment 532886 [details]
output from systemctl
At runlevel 3, only a single getty is available by default, and getty instances are not automatically started when I switch to a new virtual terminal. In other words, if I switch between different vts, only one of them has a login prompt. At runlevel 5, I do not have this problem (getty instances automatically start when I switch to a new vt)
systemd-logind.service loaded failed failed Login Service
Try to find out why systemd-logind failed. Did it log anything to /var/log/messages?
It looks like this might be related:
Nov 10 09:51:14 18potato systemd: Failed to read PID file /run/sm-client.pid after start. The service might be broken.
Nov 10 09:51:17 18potato systemd: systemd-logind.service: main process exited, code=exited, status=1
Nov 10 09:51:17 18potato systemd: Unit systemd-logind.service entered failed state.
systemd-logind failing is unrelated to sm-client.
(In reply to comment #3)
> systemd-logind failing is unrelated to sm-client.
Then I can't find anything in the logs to indicate why it's in the failed state (likewise for a number of other services in the failed state).
Have you customized any settings in /etc/systemd/system.conf?
What kernel version are you running?
And please rule out the possibility of interference from SELinux by testing it in permissive more or disabled.
(In reply to comment #5)
> Have you customized any settings in /etc/systemd/system.conf?
The only uncommented line in system.conf is "LogLevel=info" (in "[Manager]"), which as far as I can tell is now the default.
> What kernel version are you running?
(In reply to comment #6)
> And please rule out the possibility of interference from SELinux by testing it
> in permissive more or disabled.
SELinux is already disabled, so that should be ruled out.
Do you get anything interesting if you run /lib/systemd/systemd-logind directly as root?
(In reply to comment #9)
> Do you get anything interesting if you run /lib/systemd/systemd-logind directly
> as root?
Failed to acquire name.
Failed to fully start up daemon: File exists
# /lib/systemd/systemd-logind --help
This program takes no arguments.
# man systemd-logind
No manual entry for systemd-logind
Probably not what you were looking for. :)
That's actually interesting because it indicates that another instance of systemd-logind is already running. What do these commands say?:
systemctl show systemd-logind.service
ps aux|grep logind
(In reply to comment #11)
> That's actually interesting because it indicates that another instance of
> systemd-logind is already running. What do these commands say?:
> systemctl show systemd-logind.service
> ps aux|grep logind
Hmm. So it looks like systemd-logind got started again and the problem went away, too. I rebooted, and was again able to reproduce the problem. About reproducing the problem:
- The machine is configured to start in runlevel 3 (or the systemd equivalent).
- At boot, switching to different VTs works.
- If I do init 5 and then init 3, systemd-logind dies and switching to a different VT no longer gives a prompt.
When I run /lib/systemd/systemd-logind manually at this point, I see the following output:
"""New seat seat0.
New user gdm logged in.
New user amcnabb logged in.
New session 3 of user gdm.
Failed to reset controller cpu: No such process
Session 3 has display :1 with nonexisting socket /tmp/.X11-unix/X1.
New session 1 of user amcnabb.
Removed session 3.
The "New session 1 of user amcnabb" seems to refer to an ssh session. I don't quite know why it reports gdm being logged in, but apparently there's a running pulseaudio process owned by gdm (why I don't know).
By the way, at that point, running init 5 made my manually-run systemd-logind process quit without any error messages.
I have also noticed that switching runlevels kills all open login sessions on VTs. In other words, if I'm logged in on tty3 and switch to a different runlevel with "init 3" or "init 5", then I get automatically logged out. Is this part of the same problem, or should I open a separate bug report?
Bad runlevel switching behaviour is bug 708537.
systemd-logind is a victim of the isolate action here.
*** This bug has been marked as a duplicate of bug 708537 ***