Description of problem: This looks an awful lot like bug 1023820 to me, but comments over there claim it isn't the same bug, so I'm submitting a new one. When the system has been up for a while, multiple users have logged in via ssh and fiddle with testing software and such, then I do something like install updates and reboot to get new kernel loaded or something, the reboot hangs for what seems like forever (I've given it as long as 5 minutes) with the cylon eyeball and a message about a stop job running for user XXXX (where XXXX seems to alternate between all the users that had logged in at one time or other - most of them now logged out, so I have no idea why it would need to wait for anything associated with that user). The power switch (and the nasty unclean disk shutdown that goes with it) seems to be the only way to reboot. The first time I ever say this happen, I created a brand new user, logged out then logged in as new user into a gnome 3 session, then logged out again and removed that new user. The next time I tried to reboot, I got a message about a stop job running for the user which no longer existed on the system. Version-Release number of selected component (if applicable): systemd-208-14.fc20.x86_64 How reproducible: Fairly frequent, but not every time I reboot. Steps to Reproduce: 1.Have multiple users log in and out 2.Try to reboot 3.Often hang forever Actual results: Hung at reboot. Expected results: System actually rebooting. Additional info:
Created attachment 879425 [details] pre-reboot perl script This perl script seems to allow me to reboot without waiting forever. If I run it like so: pre-reboot | sudo /bin/bash sudo reboot The reboot goes quick. The perl script find every process that is not running as me and not running as a system process (uid < 1000) and prints kill commands to first send SIGSTOP to all the processes, then kill -9 them (then SIGCONT them in case they happen to be still hung). Among other things, this gets rid of all the systemd --user processes so the reboot doesn't spend forever waiting on them. This is basically a big hammer to manually implement what --force is documented to do (more or less), but as bug 1077698 documents, --force really does hang forever on my desktop at work. I don't suppose there is any way to define a systemd unit that always gets run at the beginning on a reboot is there?
Here is a solution I found that works ..at least so far: cp /usr/lib/systemd/system/systemd-reboot.service /etc/systemd/system. edit /etc/systemd/system/systemd-reboot.service to look like: [Unit] Description=Reboot Documentation=man:systemd-halt.service(8) DefaultDependencies=no Requires=shutdown.target umount.target final.target After=shutdown.target umount.target final.target [Service] Type=oneshot #ExecStart=/usr/bin/systemctl --force reboot ExecStart=/usr/bin/systemctl reboot --force Note: According to the manual "reboot" is a legacy command & has is's own -- I just figured that we don't need systemctl forcing reboot to start & what we really need is reboot to run in it's force mode when it is started by systemctl.
Here is a solution I found that works ..at least so far: cp /usr/lib/systemd/system/systemd-reboot.service /etc/systemd/system. edit /etc/systemd/system/systemd-reboot.service to look like: [Unit] Description=Reboot Documentation=man:systemd-halt.service(8) DefaultDependencies=no Requires=shutdown.target umount.target final.target After=shutdown.target umount.target final.target [Service] Type=oneshot #ExecStart=/usr/bin/systemctl --force reboot ExecStart=/usr/bin/systemctl reboot --force Note: According to the manual "reboot" is a legacy command & has is's own --force option. I just figured that we don't need systemctl forcing reboot to start & what we really need is reboot to run in it's force mode when it is started by systemctl.
Might not work for me. See bug 1077698. Using force mode hangs forever on my system at work (not merely a long time). I have spiffed up my pre-reboot script some though and have an alias for reboot that pipes the pre-reboot generated commands to an sudo shell. It seems to work quite well after tweaking it a bit. I'll attach the new copy.
Created attachment 887953 [details] latest version of pre-reboot script
I've had a similar bug for a while now. I currently only use one user on my machine and when I shutdown or reboot, that user@$uid service times out. However, if I issue a 'systemctl stop user@$uid.service' just before rebooting or shutting down, everything runs as fast as it should. The only difference I have from others reporting this problem is that my user is a freeipa network user.
(In reply to Aaron Kling from comment #6) > I've had a similar bug for a while now. I currently only use one user on my > machine and when I shutdown or reboot, that user@$uid service times out. I got the same problem ...
(In reply to Aaron Kling from comment #6) > I've had a similar bug for a while now. I currently only use one user on my > machine and when I shutdown or reboot, that user@$uid service times out. > However, if I issue a 'systemctl stop user@$uid.service' just before > rebooting or shutting down, everything runs as fast as it should. The only > difference I have from others reporting this problem is that my user is a > freeipa network user. Same here, been suspecting FreeIPA might be related one way or the other but haven't gotten around to actually perform systematic tests until now: - no reboot/shutdown hangups occur on locally created users, regardless of low/high uid, perhaps this is why relatively few people are complaining - reboot/shutdown systematically hangs up on "stop job for user manager..." for a long time if a FreeIPA account has logged in - no reboot/shutdown hangups occur if 'systemctl stop user@$uid.service' is performed for FreeIPA users before reboot/shutdown My "wild guess" would be 'systemctl stop user@$uid.service' either runs too late for network user accounts, or relies on related lookups to work when it shouldn't, or something like that.
I wrote this on test-list : https://lists.fedoraproject.org/pipermail/test/2014-April/121142.html and I don't have FreeIPA , installed
faced the same recently at shutdown for several services inlcuding systemd-logind.service and the last major update was dracut: https://bugzilla.redhat.com/show_bug.cgi?id=1092937
*** This bug has been marked as a duplicate of bug 1088619 ***