[BusyBox 0004554]: poweroff, shutdown, halt require -f to function in 1.11.1
bugs at busybox.net
bugs at busybox.net
Sat Sep 27 01:42:14 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: 09-26-2008 18:42 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.
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
======================================================================
More information about the busybox-cvs
mailing list