[Shepherd] Bogus value from PID file can prevent service from being stopped

  • Done
  • quality assurance status badge
Details
One participant
  • Ludovic Courtès
Owner
unassigned
Submitted by
Ludovic Courtès
Severity
normal
L
L
Ludovic Courtès wrote on 12 Nov 2023 18:45
(address . bug-guix@gnu.org)
87msvizwzh.fsf@inria.fr
Hi,

‘terminate-process’ in (shepherd service) assumes that, once it has sent
SIGKILL to a given PID, it eventually gets a SIGCHLD notification for
that PID.

Unfortunately there are corner cases where it doesn’t hold. Take PID 2:

Toggle snippet (5 lines)
$ ps x 2
PID TTY STAT TIME COMMAND
2 ? S 0:00 [kthreadd]

That’s not a “real” process, so when you (kill 2 SIGKILL), nothing
happens. Thus, ‘terminate-process’ never returns; the corresponding
service stays in “stopping” state and you cannot halt your machine.

You may wonder how we end up calling ‘terminate-process’ with a “bogus”
PID. It normally never happens, but it can happen with a combination of
‘make-forkexec-constructor’ with #:pid-file and
‘least-authority-wrapper’: the PID file of the wrapper may read “2” (the
PID inside the least-authority PID namespace), so ‘herd stop’ on that
service will end up doing (kill 2 SIGKILL).

Ludo’.
L
L
Ludovic Courtès wrote on 22 Nov 2023 11:16
(address . 67132-done@debbugs.gnu.org)
87fs0ym6t6.fsf@gnu.org
Ludovic Courtès <ludo@gnu.org> skribis:

Toggle quote (14 lines)
> ‘terminate-process’ in (shepherd service) assumes that, once it has sent
> SIGKILL to a given PID, it eventually gets a SIGCHLD notification for
> that PID.
>
> Unfortunately there are corner cases where it doesn’t hold. Take PID 2:
>
> $ ps x 2
> PID TTY STAT TIME COMMAND
> 2 ? S 0:00 [kthreadd]
>
> That’s not a “real” process, so when you (kill 2 SIGKILL), nothing
> happens. Thus, ‘terminate-process’ never returns; the corresponding
> service stays in “stopping” state and you cannot halt your machine.

Fixed in Shepherd commit cc9c5c029534458ae547d78200b6b51f729654e3.

Ludo’.
Closed
?
Your comment

This issue is archived.

To comment on this conversation send an email to 67132@debbugs.gnu.org

To respond to this issue using the mumi CLI, first switch to it
mumi current 67132
Then, you may apply the latest patchset in this issue (with sign off)
mumi am -- -s
Or, compose a reply to this issue
mumi compose
Or, send patches to this issue
mumi send-email *.patch