Bug #1175
closed
reboot gets stuck in some rcK script
100%
Description
/sbin/reboot from restart.xml used to use -f but was changed by RM #1048 because rcK was fixed.
But it's clear that some init script is not coming down gracefully, or is getting stuck for some reason.
I need to enable a debug in rcK to allow following what is getting stuck.
Or go back to reboot -f.
Updated by Hammel about 1 month ago
- Subject changed from Reboot failed on RPi3 Media System to reboot gets stuck in some rcK script
- Description updated (diff)
Updated by Hammel 28 days ago
- Status changed from New to In Progress
- % Done changed from 0 to 50
It looks like the problem is with SMB mounts. If I run the following, in this order, the reboot is faster.
- /etc/init.d/S91smb stop
- /etc/init.d/S89piboxd stop
- reboot
This makes the launcher exit much faster, albeit to tty1 and a login screen. But then the reboot cleans up very quickly and clears the screen.
The real trick is to sync piboxd exit with reboot. piboxd needs to umount it's smb mounts before anything else starts to shutdown. But "kill" isn't synchronous. Neither is start-stop-daemon. So how do I know piboxd is done?
The only way I can think of is to poll the pid to see if it responds to a kill signal. The kill command will exit with an error message and a non-zero value if the process is not found. So, using SIGUSR2 (which piboxd doesn't catch), we could loop on
kill -12 $(cat /var/run/piboxd.pid)until it returns an error. Then we cleanup the pid file and continue the reboot.
This implies I have a shutdown script that I call instead of /sbin/reboot. It will call the S89piboxd init script which will handle the poll of the pid, then do a chvt to clear the screen (making it look like reboot is happening faster), then call reboot. Alternatively, I can call rcK manually, followed by a umount -af and then /sbin/reboot -f to make it even faster, although reboot might not be available after umount -af. In that case, I can do a kill -15 1 to tell the init process to run it's shutdown instead of the umount/reboot sequence.
Updated by Hammel 28 days ago
Using a signal doesn't work, but there is a simpler way. Just check for the existance of /proc/$(cat /var/run/piboxd.pid). If that directory is gone, then piboxd has exited.
Of course, it's possible that this will take a long time. In that case, we can put a limit on how long we poll for the directory. If the limit runs out then we punt to reboot -f.
The timeout should be no more than the time it takes to reboot without timing out.
Updated by Hammel 28 days ago
Another problem is that restart.xml is in launcher and calls /sbin/reboot. But piboxd should have the polling script in its init script.
So the polling will have to be done in piboxd. If it times out then we kill -9 piboxd and iterate over /media/smb, extracting the directory names to manually and forcefully unmount them. Or possibly lazily unmount them. Whatever works to get them out of the way for the reboot.
Updated by Hammel 20 days ago
- Status changed from Closed to In Progress
- % Done changed from 100 to 90
Reopening this due to git mess up.
rpi2 sandbox has two commits to functions.
commit 2b37f4af2bd6e639fd33e439f113595850d7e6c6
Author: Michael J. Hammel <mjhammel@graphics-muse.org>
Date: Mon Feb 10 21:10:20 2025 -0700
RM #1178: Fix genConfig to properly identify TFT displays.
and
commit 76390d0780fe9101be9f4339d5efa9552be14b54
Author: Michael J. Hammel <mjhammel@graphics-muse.org>
Date: Mon Feb 10 17:45:55 2025 -0700
RM #1175: Add support for cleaner reboot.
The latter added piboxWaitOnPid() for S89piboxd to use to deal with SMB shutdowns. The former seems to have removed those. I'm not sure what I did to make that happen, but I need to put the latter back in.