On Sat, Jul 23, 2016 at 8:43 AM, Timothy Murphy <gayleard(a)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.
--
Chris Murphy