As you will see, there is a long delay (90 seconds or so) while shutting down. If anyone can throw light on this I should be very grateful.
This is the re-boot timeline on my Thinkpad T510:
f=>Leave=>Restart command given and confirmed 19s just cursor on screen f icon appears and remains on screen 114s Thinkpad icon appears 14s automatic choice of kernel bulb appears and slowly fills 25s login screen - after logging in 5s K icon appears and horizontal bar fills 30s panel appears
It will be seen that there is a long delay (almost 2 minutes) while shutting down.
I see from "journalctl -b-1" that the delay occurs here ------------------------------ Jul 23 14:11:38 william.gayleard.com NetworkManager[908]: <info> [1469275898.3807] device (wlp3s0): supplicant interface state: completed -> disconnected Jul 23 14:11:41 william.gayleard.com wpa_supplicant[1061]: wlp3s0: Reject scan trigger since one is already pending Jul 23 14:13:02 william.gayleard.com NetworkManager[908]: <info> [1469275982.5130] connectivity: check for uri 'http://fedoraproject.org/static/hotspot.txt' failed wit Jul 23 14:13:05 william.gayleard.com systemd[1]: session-1.scope: Stopping timed out. Killing. Jul 23 14:13:05 william.gayleard.com systemd[1]: Stopped Session 1 of user tim. ------------------------------
Is the delay due to the timeout mentioned? I am not good at interpreting the output of journalctl.
On Sat, 23 Jul 2016 16:43:02 +0200 Timothy Murphy wrote:
Is the delay due to the timeout mentioned? I am not good at interpreting the output of journalctl.
I can't interpret anything systemd says either, but you'd be more likely to see something if you remove the "rhgb quiet" from the kernel boot lines in grub.cfg. Instead of useless animation, you get actual messages about what is going on.
Personally, I found that using the big hammer I wrote up here to reboot makes things go much faster:
http://tomhorsley.com/game/punch.html
The output from the program in there can be piped to sudo to kill off all the "user daemons" that never die, yet systemd waits for them forever.
Another thing that slows down my reboots is the external USB drive I have that spins down and takes a while to spin up so it can be unmounted. If I explicitly unmount them, I can at least see what it is waiting for.
Lately systemd has started waiting on apache httpd to shut down for some reason, so I added a "die apache die!" command to my "reboot" alias as well as all the above stuff.
If you have any NFS filesystems mounted, you'll want to do a "umount -l -t nfs -a" as well, otherwise systemd can take hours to timeout on nfs mounts for systems that have actually gone down. (The -l option being the important bit).
The list of things systemd waits on for no reason appears to grow every release or systemd update, but I try to track them down and hit them over the head with my hammer when new ones appear :-).
On Sat, Jul 23, 2016 at 8:43 AM, Timothy Murphy gayleard@eircom.net wrote:
As you will see, there is a long delay (90 seconds or so) while shutting down. If anyone can throw light on this I should be very grateful.
If it's exactly 90 seconds, that sounds like the user session is hung up, something isn't quitting, systemd is waiting for it, and there's a 1m30s timeout for user sessions to get killed off. And then the reboot/shutdown happens.
Here's the bug I filed for this on GNOME. https://bugzilla.redhat.com/show_bug.cgi?id=1337307
And with KillUserProcesses=yes, it still doesn't get killed. https://bugzilla.redhat.com/show_bug.cgi?id=1341837
What does appear to work, is if I logout first. That kills user processes. And then from the login screen, a restart/shutdown happens quickly.
This is the re-boot timeline on my Thinkpad T510:
f=>Leave=>Restart command given and confirmed 19s just cursor on screen f icon appears and remains on screen 114s Thinkpad icon appears 14s automatic choice of kernel bulb appears and slowly fills 25s login screen - after logging in 5s K icon appears and horizontal bar fills 30s panel appears
It will be seen that there is a long delay (almost 2 minutes) while shutting down.
I see from "journalctl -b-1" that the delay occurs here
Jul 23 14:11:38 william.gayleard.com NetworkManager[908]: <info> [1469275898.3807] device (wlp3s0): supplicant interface state: completed -> disconnected Jul 23 14:11:41 william.gayleard.com wpa_supplicant[1061]: wlp3s0: Reject scan trigger since one is already pending Jul 23 14:13:02 william.gayleard.com NetworkManager[908]: <info> [1469275982.5130] connectivity: check for uri 'http://fedoraproject.org/static/hotspot.txt' failed wit Jul 23 14:13:05 william.gayleard.com systemd[1]: session-1.scope: Stopping timed out. Killing. Jul 23 14:13:05 william.gayleard.com systemd[1]: Stopped Session 1 of user tim.
Is the delay due to the timeout mentioned? I am not good at interpreting the output of journalctl.
If you login remotely with ssh, you should be able to do 'lsof /home' and get an idea of what's holding onto home.
You can also use loginctl to get a list of sessions and also 'loginctl session-status <session#>' to get a list of stuff that's still running. One of those is the culprit. You could try to kill them in reverse order of PID and see if that releases the user session. The last one you do right before your shell session is killed is probably the culprit.
Thing is, for a pile of reasons, programs lurk around and don't quit when they should and it's not always their fault as I understand it.
Another option:
sync && reboot -f sync && poweroff -f
That's if you don't want to troubleshoot this, or logout first. I've actually been doing a lot of just 'reboot -f' for the past year or so, without sync, to no ill effect. But I'm also using Btrfs, use no databases, and pretty much have no important data on this system. So... you might not want to do this, or at least use sync first. For sure any documents you haven't saved you'll lose because it's an ungraceful kernel level reboot, your DE and its applications won't ask, you'll get a reboot in about 1-2 seconds.
Chris Murphy
On Sat, 23 Jul 2016 21:59:57 -0600 Chris Murphy wrote:
sync && reboot -f sync && poweroff -f
Might work until you try it with active NFS mounts :-).
The very clever systemd first shuts down the network connection, then tries to unmount the NFS filesystems. My projected time to reboot when I tried the force option at work was 5 hours (the power button did work though).
-
Chris Murphy -
Timothy Murphy -
Tom Horsley