Bug 195899

Summary: reboot(2): inaccurate text about interaction with pid namespaces
Product: Documentation Reporter: Michał Zegan (webczat)
Component: man-pagesAssignee: documentation_man-pages (documentation_man-pages)
Status: RESOLVED CODE_FIX    
Severity: normal CC: mtk.manpages
Priority: P1    
Hardware: All   
OS: Linux   
Kernel Version: Tree: Mainline
Regression: No

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.