Bug 195899
| Summary: | reboot(2): inaccurate text about interaction with pid namespaces | ||
|---|---|---|---|
| Product: | Documentation | Reporter: | Michał Zegan (webczat) |
| Component: | man-pages | Assignee: | documentation_man-pages (documentation_man-pages) |
| Status: | RESOLVED CODE_FIX | ||
| Severity: | normal | CC: | mtk.manpages |
| Priority: | P1 | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Kernel Version: | Subsystem: | ||
| Regression: | No | Bisected commit-id: | |
ping Thanks for the report. Yes, the existing text was confused (mea culpa).
I changed it to the following:
Behavior inside PID namespaces
Since Linux 3.4, if reboot() is called from a PID namespace other
than the initial PID namespace with one of the cmd values listed
below, it performs a "reboot" of that namespace: the "init"
process of the PID namespace is immediately terminated, with the
effects described in pid_namespaces(7).
The values that can be supplied in cmd when calling reboot() in
this case are as follows:
LINUX_REBOOT_CMD_RESTART, LINUX_REBOOT_CMD_RESTART2
The "init" process is terminated, and wait(2) in the parent
process reports that the child was killed with a SIGHUP
signal.
LINUX_REBOOT_CMD_POWER_OFF, LINUX_REBOOT_CMD_HALT
The "init" process is terminated, and wait(2) in the parent
process reports that the child was killed with a SIGINT
signal.
For the other cmd values, reboot() returns -1 and errno is set to
EINVAL.
I'll close this now. Please reopen if you see something that still needs fixing.
|
It seems that the text about interaction of reboot(2) system call and pid namespaces is inaccurate. The manpage says: Behavior inside PID namespaces Since Linux 3.4, when reboot() is called from a PID namespace (see pid_namespaces(7)) other than the initial PID namespace, the effect of the call is to send a signal to the namespace "init" process. The LINUX_REBOOT_CMD_RESTART and LINUX_REBOOT_CMD_RESTART2 cmd values cause a SIGHUP signal to be sent. The LINUX_REBOOT_CMD_POWER_OFF and LINUX_REBOOT_CMD_HALT cmd values cause a SIGINT signal to be sent. For the other cmd values, -1 is returned and errno is set to EINVAL. However, this description seems to be wrong. That is, if a signal like SIGHUP or SIGINT would be sent to a pid namespace init process as it is stated, then no matter what would send this signal, it should be handled normally, that is it should terminate the init process unless a signal handler is established, in which case it should be invoked. However, it seems that even though it seems sighup/sigint is sent to the init process, it is killed unconditionally without invoking a signal handler. Verified that by running "unshare -Upfr --mount-proc", and in the spawned bash shell performing poweroff -f command. The expected behavior would be that bash is not terminated, as it does not really react on sigint in normal cases. However, in case of poweroff -f it is just killed without a warning. And yes, I verified that pid1 is actually bash, not some kind of init process stub.