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

(0010414)
edwardsm
08-13-08 15:17
edited on: 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.

(0010424)
vda
08-14-08 14:55

Please do "strace -o pwoff.log poweroff" and post the log.

(0011724)
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);

(0011944)
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) = ?

(0012094)
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?

(0012104)
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).

(0012264)
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.

(0014194)
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.

(0014294)
vda
10-27-08 05:18

Closing, as it appears not to be a bug. If current reboot's behavior (sending busybox-style signals to init regardless of CONFIG_INIT state) can be improved, propose how.

Notes
(0010414) edwardsm 08-13-08 15:17 edited on: 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.

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

(0011724) 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);

(0011944) 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) = ?

(0012094) 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?

(0012104) 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).

(0012264) 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.

(0014194) 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.

(0014294) vda 10-27-08 05:18	Closing, as it appears not to be a bug. If current reboot's behavior (sending busybox-style signals to init regardless of CONFIG_INIT state) can be improved, propose how.

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
10-27-08 05:18	vda	Status	assigned => closed
10-27-08 05:18	vda	Note Added: 0014294
10-27-08 05:18	vda	Resolution	open => no change required

Relationships