On Wed, 25 Jan 2017 15:24:52 -0700 Chris Murphy <lists@xxxxxxxxxxxxxxxxx> wrote: Thanks for the response. > Could be a labeling problem. Might be worth 'sudo restorecon -rv /' > and then a sync and then reboot -f and see if it works with > enforcing=0 (or even without, let it enforce). This made lots of changes, but didn't seem to affect the shutdown delay problem. After the restorecon, the system delayed without setenforce 0 and with it, a few times. Some kind of race? > Stock Fedora 25 I have had a stop job for user 1000, that takes 90 > seconds to time out. Your problem seems different. But to isolate if > this is a user environment problem, or a system problem, you could try > modifying /etc/systemd/logind.conf such that KillUserProcesses=yes This was already in place. > (and remove the # so it's uncommented). The gotcha with this is that > user processes are unceremoniously killed at logout time (including > restart and shutown). So if you use screen or tmux, and logout, the > tmux/screen processes get killed by virtue of tmux/screen getting > killed. There's a work around for that also which I can't articulate - > something to do with linger or gettting it to run in a separate logind > session? Anyway... just change this option temporarily for > troubleshooting purposes. I changed some timeout options in the systemd .conf files in /ets/systemd. It doesn't seem consistent. One time if I use setenforce 0 there is no delay, and the next time there is. And there aren't useful messages in the /shutdown-log.txt file that systemd is creating. I changed journald to allow all output by setting burst to 0. The burst set to 0 didn't affect that there are lots of messages elided by shutdown because of rate limiting. I'll keep playing with that, maybe I can see what the problem is if I can see those. After more than a half dozen reboots, time for a respite. _______________________________________________ test mailing list -- test@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to test-leave@xxxxxxxxxxxxxxxxxxxxxxx
