Bug 195899 - reboot(2): inaccurate text about interaction with pid namespaces
Summary: reboot(2): inaccurate text about interaction with pid namespaces
Status: RESOLVED CODE_FIX
Alias: None
Product: Documentation
Classification: Unclassified
Component: man-pages (show other bugs)
Hardware: All Linux
: P1 normal
Assignee: documentation_man-pages@kernel-bugs.osdl.org
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2017-05-28 19:47 UTC by Michał Zegan
Modified: 2017-09-24 09:12 UTC (History)
1 user (show)

See Also:
Kernel Version:
Tree: Mainline
Regression: No


Attachments

Description Michał Zegan 2017-05-28 19:47:24 UTC
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.
Comment 1 Michał Zegan 2017-09-16 13:41:22 UTC
ping
Comment 2 Michael Kerrisk 2017-09-24 09:12:07 UTC
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.

Note You need to log in before you can comment on or make changes to this bug.