Arch Linux

Description:

I think there is a race when exiting the from a "systemd --user" session. That makes the unit user@1000.service not finishing until it timeouts. The more obvious consequence is that when I command a power-off, it takes about two minutes to complete it. It does not happen always, only about 80% of the tries. Less if I have a lot of programs opened.

However, when logging from a VT the logoff works normally.

After some debugging I am now pretty sure that it is a race between the running of systemd-exit.service and the closing of the PAM session. My guess about the scenario is:

* systemd --user is told to start the exit.target.
* It start systemd-exit.service as Wants= from above. It has a oneshot command: "/usr/bin/kill -s 58 $MANAGERPID".
* A new process is forked to run that "kill" command.
* Then, I don't know exactly why, the "(sd-pam)" process finishes and the "kill" process is terminated _before_ it is able to send the signal 58.
* Since signal 58 is never deliverd the "systemd --user" process never finishes.

However, sometimes the "(sd-pam)" process finishes before systemd-exit.service is started, and then everything goes well.

The above information includes a lot of guessing, because if I look too close to the processes (strace, log_debug...) then it never fails.

For now I have this workaround: add a dummy "ExecStart=/usr/bin/true" before the kill command in systemd-exit.service. The dummy command may not be run, but the kill will.

Additional info:
* systemd-208-9
* pam-1.1.8-2
* lxde-common 0.5.5-3
* i686, single core


Steps to reproduce:

* Start a session in LXDE
* Start the debug shell: `systemctl start debug-shell`
* Select log-off from the LXDE menu.
* Go to the VT9 and type `systemctl list-jobs`.
* You will see the user@PID.service as "stop waiting" for a couple of minutes.