I just ran my normal reboot script which just kills off some things systemd has problems killing sometimes then does a reboot.
Instead of rebooting, it acted like a logout.
I logged back in again, and uptime said 3 days.
I rebooted again, and it really did reboot the 2nd time. What the heck happened the first time? Any clues?
On 03/11/2020 20:54, Tom Horsley wrote:
I just ran my normal reboot script which just kills off some things systemd has problems killing sometimes then does a reboot.
Instead of rebooting, it acted like a logout.
I logged back in again, and uptime said 3 days.
I rebooted again, and it really did reboot the 2nd time. What the heck happened the first time? Any clues?
Should we assume that checking the journal didn't find anything?
--- The key to getting good answers is to ask good questions.
On 11/3/20 4:54 AM, Tom Horsley wrote:
I just ran my normal reboot script which just kills off some things systemd has problems killing sometimes then does a reboot.
It would help if you provided the script.
Instead of rebooting, it acted like a logout.
I logged back in again, and uptime said 3 days.
I rebooted again, and it really did reboot the 2nd time. What the heck happened the first time?
Maybe there was something inhibiting the reboot.
Generally if a reboot script someone wrote acts like that it means that some part of it killed something that immediately caused the logout prior to the reboot command happening.
It may be that usually whatever it kills that causes the logout does not always kill the script prior to the reboot happening (race condition).
A suggestion would be to make the script a 2 script process, the first script nohup's the 2nd script, or you can nohup the script when you run it. That will prevent a terminal kill from killing and cleaning up the script.
On Tue, Nov 3, 2020 at 3:58 PM Samuel Sieb samuel@sieb.net wrote:
On 11/3/20 4:54 AM, Tom Horsley wrote:
I just ran my normal reboot script which just kills off some things systemd has problems killing sometimes then does a reboot.
It would help if you provided the script.
Instead of rebooting, it acted like a logout.
I logged back in again, and uptime said 3 days.
I rebooted again, and it really did reboot the 2nd time. What the heck happened the first time?
Maybe there was something inhibiting the reboot. _______________________________________________ users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-leave@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org
On Tue, 3 Nov 2020 16:20:56 -0600 Roger Heflin wrote:
Generally if a reboot script someone wrote acts like that it means that some part of it killed something that immediately caused the logout prior to the reboot command happening.
Could be. I'll try it without the final reboot command and see what happens. The script is unchanged from earlier versions of fedora where it was the only way to reboot without incessant "a stop job is running" messages from systemd taking hours to timeout (well, felt like hours, anyway).
I also finally spotted this suspicious nonsense in the logs. I have no idea what it means.
Nov 3 17:31:45 zooty systemd[2615]: Condition check resulted in Mark boot as successful after the user session has run 2 minutes being skipped.
The word "boot" is the only reason it seems possibly relevant.
On Tue, 3 Nov 2020 17:40:15 -0500 Tom Horsley wrote:
Could be. I'll try it without the final reboot command and see what happens. The script is unchanged from earlier versions of fedora where it was the only way to reboot without incessant "a stop job is running" messages from systemd taking hours to timeout (well, felt like hours, anyway).
That was indeed it, thanks for the suggestion!
The script was running the program described here: https://tomhorsley.com/game/punch.html#Rebooting to kill off every systemd --user process tree because for years every time I tried to reboot I'd have to wait forever for "a stop job is running for user ..." for every user that ever logged in via ssh or anything. Killing all the user daemons was the only way to reboot in a reasonable amount of time. But now it logs me out when I kill them. I've removed it from my reboot script, I'll see if the stop job timeouts come back...