[BusyBox 0004554]: poweroff, shutdown, halt require -f to function in 1.11.1

bugs at busybox.net bugs at busybox.net
Sun Oct 26 09:26:44 UTC 2008


A NOTE has been added to this issue. 
====================================================================== 
http://busybox.net/bugs/view.php?id=4554 
====================================================================== 
Reported By:                edwardsm
Assigned To:                BusyBox
====================================================================== 
Project:                    BusyBox
Issue ID:                   4554
Category:                   Documentation
Reproducibility:            always
Severity:                   major
Priority:                   normal
Status:                     assigned
====================================================================== 
Date Submitted:             08-12-2008 20:13 PDT
Last Modified:              10-26-2008 02:26 PDT
====================================================================== 
Summary:                    poweroff, shutdown, halt require -f to function in
1.11.1
Description: 
Poweroff, shutdown and halt return to the prompt and do nothing.  This was
not
an issue in the previous installed 1.1.0, but that version would not
properly
start my application startup scripts from /etc/rc.sysinit. The 1.11.1
starts my
applications just fine, but I can only stop the system by adding the "-f"
option
to shutdown or poweroff.

====================================================================== 

---------------------------------------------------------------------- 
 edwardsm - 08-13-08 15:17  
---------------------------------------------------------------------- 
A rebuild using the "defconfig" on a different platform yielded a working
executable.  The inotifyd had to be removed again, but otherwise it was
unchanged.
Execution of scripts and reboot work fine.  The defect is obviously config
dependent.  A build on Fedora 9 (P4) built a static image that seg faults
when
executed on the 2.4.34.1 kernel.

 

---------------------------------------------------------------------- 
 vda - 08-14-08 14:55  
---------------------------------------------------------------------- 
Please do "strace -o pwoff.log poweroff" and post the log. 

---------------------------------------------------------------------- 
 vda - 09-20-08 09:15  
---------------------------------------------------------------------- 
One of possible issues here is that init may try to print some messages:

        m = "reboot";
        ...
        message(L_CONSOLE | L_LOG, "Requesting system %s", m);

If write() to console blocks, init will be unable to proceed.

Fix: add in init_main():

        console_init();
+       fcntl(STDERR_FILENO, F_SETFL, fcntl(STDERR_FILENO, F_GETFL) |
O_NONBLOCK); 

---------------------------------------------------------------------- 
 vapier - 09-25-08 01:26  
---------------------------------------------------------------------- 
answer is obvious if you compare 1.11.2 and 1.12.0:
@@ -73,3 +73,6 @@
        /* Perform action. */
-       if (ENABLE_INIT && !(flags & 4)) {
+       rc = 1;
+       if (!(flags & 4)) { /* no -f */
+//TODO: I tend to think that signalling linuxrc is wrong
+// pity original author didn't comment on it...
                if (ENABLE_FEATURE_INITRD) {

notice how the "ENABLE_INIT" part was dropped ... in my case, we arent
using the busybox init.  i dont believe there is any standard API for
signaling the init "you need to reboot".  in my case, init ignores SIGTERM
which we can see `reboot` is attempting to do and nothing else:

if we strace this new reboot we get:
root:/> strace reboot
execve(NULL, [0x546f80], [/* 0 vars */] <unfinished ...>
ioctl(0, SNDCTL_TMR_TIMEBASE or TCGETS, {B57600 opost isig icanon echo
...}) = 0
ioctl(1, SNDCTL_TMR_TIMEBASE or TCGETS, {B57600 opost isig icanon echo
...}) = 0
getuid32()                              = 0
access("/var/log/wtmp", R_OK|W_OK)      = -1 ENOENT (No such file or
directory)
open("/var/log/wtmp", O_WRONLY|O_CREAT|O_TRUNC, 0664) = 3
close(3)                                = 0
time(NULL)                              = 51410
uname({sys="Linux", node="blackfin", ...}) = 0
open("/var/log/wtmp", O_WRONLY|O_APPEND) = 3
fcntl(3, F_SETLKW, {type=F_WRLCK, whence=SEEK_CUR, start=0, len=0}) = 0
write(3,
"\1\0\0\0\0\0\0\0~~\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"...,
384) = 384
fcntl(3, F_SETLK, {type=F_UNLCK, whence=SEEK_CUR, start=0, len=0}) = 0
close(3)                                = 0
sync()                                  = 0
kill(1, SIGTERM)                        = 0
_exit(0)                                = ? 

---------------------------------------------------------------------- 
 vda - 09-25-08 14:49  
---------------------------------------------------------------------- 
I see. I didn't realize sending SIGTERM is not a common way of asking init
to reboot.

Ok. What to do? I see no way how reboot applet can determine is current
init process from busybox or not. How can it reliably ask it to reboot? 

---------------------------------------------------------------------- 
 vapier - 09-25-08 21:40  
---------------------------------------------------------------------- 
i dont think there is a standard ... every init package has their own way
of communication with the init process.  consider the suite of binaries
{init,halt,shutdown,reboot} to be inseparable.  trying to mix and match
from different packages is a waste.

along those lines, the halt/shutdown/etc... applets should work with the
busybox init if it's enabled.  otherwise, just call straight to the kernel
via reboot(2). 

---------------------------------------------------------------------- 
 vda - 09-26-08 18:42  
---------------------------------------------------------------------- 
> along those lines, the halt/shutdown/etc... applets should work with the
busybox init if it's enabled.

How reboot applet can know that RUNNING init (as opposed to CONFIGURED at
build time) is from busybox?

> otherwise, just call straight to the kernel via reboot(2).

This makes reboot do two very different things depending on .config

Suppose you came to a computer with busybox reboot installed. How can you
know what reboot will do - graceful reboot or - BLAMM! - instantaneous
one?

I prefer more uniform behavior, when I don't need to guess. 

---------------------------------------------------------------------- 
 vapier - 10-26-08 02:26  
---------------------------------------------------------------------- 
there's only so far you can go to help people.  run time detection of init
is another dead end path which people will come up with weird use cases
where the detection fails.

if you want to avoid the "two different code paths" issue, then turn it
into a documentation one.  if CONFIG_INIT is enabled, then have it send
the signals like normal (expecting a busybox init).  if it isnt enabled,
then have a normal `reboot` spit out a message that it only works with
busybox init and people need to run `reboot -f` if they want it to reboot. 

Issue History 
Date Modified   Username       Field                    Change               
====================================================================== 
08-12-08 20:13  edwardsm       New Issue                                    
08-12-08 20:13  edwardsm       Status                   new => assigned     
08-12-08 20:13  edwardsm       Assigned To               => BusyBox         
08-13-08 15:17  edwardsm       Note Added: 0010414                          
08-13-08 15:17  edwardsm       Note Edited: 0010414                         
08-14-08 14:55  vda            Note Added: 0010424                          
09-20-08 09:15  vda            Note Added: 0011724                          
09-25-08 01:26  vapier         Note Added: 0011944                          
09-25-08 14:49  vda            Note Added: 0012094                          
09-25-08 21:40  vapier         Note Added: 0012104                          
09-26-08 18:42  vda            Note Added: 0012264                          
10-26-08 02:26  vapier         Note Added: 0014194                          
======================================================================




More information about the busybox-cvs mailing list