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-36-3.fc16.x86_64
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[1]: Failed to read PID file /run/sm-client.pid after start. The service might be broken. Nov 10 09:51:17 18potato systemd[1]: systemd-logind.service: main process exited, code=exited, status=1 Nov 10 09:51:17 18potato systemd[1]: 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? kernel-3.1.0-7.fc16.x86_64
(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? # /lib/systemd/systemd-logind 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 ***