You are not logged in.
Thanks. The logind.conf file is in /etc/systemd. The man page says setting KillUserProcesses to yes will break tools "like" screen. I use tmux all of the time. But, since I rarely use it to connect to a session, remotely, I suppose it should be ok. I will try it.
Tim
Ok, for a sample size of one reboot, that worked. Thanks again, berbae.
Tim
Last edited by ratcheer (2016-03-12 19:51:20)
Offline
CPU-optimized Linux-ck packages @ Repo-ck • AUR packages • Zsh and other configs
Offline
Same problem to me.
Looks like a systemd regression bug - we've already had this some time ago.
Same issue here all time when shutting down directly from kodi, sometimes even on normal shutdown via lxde/lxqt panel.
I do not use any display/login manager.Some dirty workaround:
Edit /etc/systemd/system.conf and uncomment + set to 10s:DefaultTimeoutStartSec=10s DefaultTimeoutStopSec=10s
Now you don't have to wait the 90sec but only 10sec for shutdown when this annoying issue occurs again.
Can I solve this issue downgranding systemd to a previous version?
Offline
ratcheer wrote:Thanks. The logind.conf file is in /etc/systemd. The man page says setting KillUserProcesses to yes will break tools "like" screen. I use tmux all of the time. But, since I rarely use it to connect to a session, remotely, I suppose it should be ok. I will try it.
Tim
Ok, for a sample size of one reboot, that worked. Thanks again, berbae.
Tim
Nope. On the second reboot attempt, which I assumed was going to work smoothly (so I hadn't checked to see if some user processes were still running after logout), it waited for 90 seconds, again.
Tim
Offline
For me, downgrading to the 4.3.x series of kernels fixes this. Present on 4.4.1-4.4.5 and on 4.5rc7. Can some others affected confirm that downgrading to a 4.3.x series kernel reverses this?
CPU-optimized Linux-ck packages @ Repo-ck • AUR packages • Zsh and other configs
Offline
If the 'KillUserProcesses=yes' option is not enough, then some other processes are still running and could not be killed after the user has logged out the session.
You can try to see what is left behind after logout, in another console shell with :
systemd-cgls
Do that after the logout only, ie without the shutdown/poweroff/reboot command.
I agree that this issue could be annoying, but it's just to stop the machine; it seems to have been implemented in systemd for security, when something doesn't quit cleanly, to give time (default 90s) to fix the problem before the shutdown is forcibly resumed.
But this delay can be reduced in /etc/systemd/system.conf :
DefaultTimeoutStopSec=30s
Or the shutdown/poweroff can be forced with --force one or two times.
But it's better to solve the problem of the processes keeping running after logout though.
This issue seems to make visible problems with environments not quitting cleanly, ie leaving something behind, running after logout.
So it's not clear if it's really a systemd bug or some other environment bug when quitting a running session.
That's probably the reason why this problem/bug is not solved yet after so many time. It appears differently depending on machine/environment, but it seems to always result from processes continuing running when they should be stopped/killed.
There is a problem there, surely, but what is the real cause and how to solve it? It's not easy to answer.
Offline
Same problem here, once again. It occurred randomly some months ago, then it was apparently resolved until it reappeared a few weeks ago. And now it occurs during every shutdown, not randomly.
If this really is a systemd bug, I'm slowly starting to believe those anti-systemd people...
Offline
ratcheer wrote:Is there some setting that will make it terminate automatically after the user logs out?
Do you have:
KillUserProcesses=yes
in /etc/systemd/logind.conf ?
Edit: gave the right path to logind.conf
I love this solution, thank you ! I should really learn these systemd stuff.
Offline
In my case, it turns out systemd isn't sending a SIGTERM to my session processed - some of then die when Xorg dies, but the rest linger, including tmux, vim, less, and lots of background services.
I'll experiment with KillUserProcesses. Since I use autologin, the last session should NEVER die unless I'm shutting down.
EDIT:
KillUserProcesses did not eliminate the 90s delay. Also, setting DefaultTimeoutStartSec to very low values results in startup failing (probably due so some process legitimately taking more than 1s to start up).
Last edited by hobarrera (2016-04-12 01:51:41)
Offline
Don't change the DefaultTimeoutStartSec parameter only the DefaultTimeoutStopSec, and don't choose a too low value (I reduce it to 30s).
But since I use my new computer (two months), with the same usage as with my old one, I do not see any delay when shutting down.
So machine configuration seems to be implicated in this issue.
Offline
Don't change the DefaultTimeoutStartSec parameter only the DefaultTimeoutStopSec, and don't choose a too low value (I reduce it to 30s).
You're right, I got those mixed up. 6s seemed to work okay for me. 30s is way too long for me (10s was my previous value and getting on my nerves!).
So machine configuration seems to be implicated in this issue.
I think it strongly depends on how you manage your session, and if SIGTERMs are propagated to all running programs or not. It seems they're not in my case, which is what adds this delay.
Offline