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 ***