This was tested on Debian packaged version 208-6, and confirmed on version 214-6, but a careful look at the code from Git head seems to indicate it still happens. Please forgive me if it is not. If a session was opened for user nobody, or probably any user with a nonexistent home directory: |-1 /sbin/init |-user.slice | |-user-65534.slice | | `-user@65534.service | | |-1353 /lib/systemd/systemd --user | | `-1354 (sd-pam) | |-user-1000.slice Aug 26 09:54:12 aimlin systemd[2719]: Failed at step CHDIR spawning /bin/kill: No such file or directory Aug 26 09:54:12 aimlin systemd[1353]: systemd-exit.service: main process exited, code=exited, status=200/CHDIR Aug 26 09:54:12 aimlin systemd[1353]: Failed to start Exit the Session. Aug 26 09:54:12 aimlin systemd[1353]: Dependency failed for Exit the Session. Aug 26 09:54:12 aimlin systemd[1353]: Unit systemd-exit.service entered failed state. That causes a 60-90 seconds timeout, making it seem shutdown is stuck. The problem is that "step CHDIR" tries to chdir to the nonexistent home directory, and considers the failure as fatal. With vesion 208, the timeout happens at shutdown and makes it appear to be stuck. With version 214, I believe that due to this commit the timeout happens immediately, fully in background; the service still goes into "fail" state: http://cgit.freedesktop.org/systemd/systemd/commit/?id=b58b227a53ee2b9feba8433a1558b51132ffb18b I am surprised to see systemd trying to spawn /bin/kill instead of just killing the processes directly, but there may be a valid reason for it that I did not thought of. Please see also the Debian bug report for a few more details: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=749268
If you add WorkingDirectory=/ at the end of /usr/lib/systemd/user/systemd-exit.service , does it fix the issue ?
In fact, can you explain how do you trigger the timeout ? ( like a step by step process, as I am not sure on how to reproduce to test myself )
I'm not the original reporter, but I have some info: Yes, setting WorkingDirectory=/ in systemd-exit.service fixes it. An easy way to reproduce is to run a cron job that su's to a user with a nonexistent home directory. I put this in root's crontab: * * * * * su -s /bin/sh -c /bin/true nobody and it triggered it.
Fixed in git.
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.