1

reboot appears to make the root file system read-only almost immediately, causing a race condition with one of my processes which tries to write settings out to a file during its approx 1-2 second shutdown.

The result, intermittently, is an empty settings file as it's truncated but not filled back up in time.

I'm creating a workaround within the process in question itself, but I'd still like to add some sanity to the reboot command.

Now, I thought about aliasing reboot to reboot -d 5 for the only account on the system, so that no-one will inadvertently perform this immediate shutdown, since -d introduces a delay:

[hostname /root]# reboot --help 2>&1 | grep Delay
        -d      Delay interval for rebooting

However, BusyBox v1.13.3 doesn't appear to support alias in its sh implementation:

[hostname /root]# alias reboot=reboot -d 5
-sh alias: not found

What are my options?

Improve this question

1 Answer 1

Reset to default
0

The alias equivalent of a function could be achieved with something like this in your .bashrc:

reboot() {
   cmd=/path/to/reboot
   $cmd -d 5
}

If that's not practical are you able to modify the BB reboot applet to have a default delay, or rename it and replace with a forwarding wrapper script?

Improve this answer
7
  • 'fraid not - (a) turns out the delay option is useless anyway - the applet simply does sleep before invoking Linux reboot (and doesn't do any signalling of its own), and (b) we would not be able to distribute an upgrade to the applet with [y]our software. The function approach could work, though... hmm.
    – Lightness Races in Orbit
    Mar 14, 2013 at 10:05
  • Actually I guess (a) means that this whole question is moot now. :(
    – Lightness Races in Orbit
    Mar 14, 2013 at 10:07
  • How about have the wrapper script or function perform any custom pre-shutdown signalling to any processes you desire, wait for (completion | specified delay | completion with specified timeout) then handover to busybox reboot?
    – boycy
    Mar 14, 2013 at 10:25
  • Yeah I suppose injecting a bit of signalling to the specific processes I'm concerned about would do it. I wouldn't be comfortable signalling everything myself, though, making this less of a catch-all workaround than I'd originally hoped. I'll give this a go; thanks :)
    – Lightness Races in Orbit
    Mar 14, 2013 at 10:32
  • How about calling kill(-1, SIGTERM) (<signal.h>) before the delay; if run as root it gives all processes the 'SIGTERM' heads up before the reboot applet does its own SIGTERM - sleep(1) - SIGKILL cycle
    – boycy
    Mar 14, 2013 at 11:23

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .