Super User is a question and answer site for computer enthusiasts and power users. It's 100% free, no registration required.

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

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?

share|improve this question

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

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?

share|improve this answer
'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 '13 at 10:05
Actually I guess (a) means that this whole question is moot now. :( – Lightness Races in Orbit Mar 14 '13 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 '13 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 '13 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 '13 at 11:23

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.