GNU bug report logs - #63717
[Shepherd] Replaced services remain active in the shadows

Previous Next

Full log

View this message in rfc822 format

From: help-debbugs <at> gnu.org (GNU bug Tracking System)
To: Ludovic Courtès <ludovic.courtes <at> inria.fr>
Subject: bug#63717: closed (Re: bug#63717: [Shepherd] Replaced services
 remain active in the shadows)
Date: Mon, 29 May 2023 22:21:01 +0000

[Message part 1 (text/plain, inline)]

Your bug report

#63717: [Shepherd] Replaced services remain active in the shadows

which was filed against the guix package, has been closed.

The explanation is attached below, along with your original report.
If you require more details, please reply to 63717 <at> debbugs.gnu.org.

-- 
63717: https://debbugs.gnu.org/cgi/bugreport.cgi?bug=63717
GNU Bug Tracking System
Contact help-debbugs <at> gnu.org with problems

[Message part 2 (message/rfc822, inline)]

From: Ludovic Courtès <ludo <at> gnu.org>
To: 63717-done <at> debbugs.gnu.org
Subject: Re: bug#63717: [Shepherd] Replaced services remain active in the
 shadows
Date: Tue, 30 May 2023 00:20:14 +0200

Ludovic Courtès <ludo <at> gnu.org> skribis:

> Ludovic Courtès <ludovic.courtes <at> inria.fr> skribis:
>
>> What seems to happen is that, in both cases, the registry points to the
>> new service; ‘herd status’ & co. look up the service by name in the
>> registry, find the new service, and rightfully show that it’s stopped.
>> But the old service still exists: it’s no longer in the registry, but it
>> handles SIGCHLD, incoming connections on port 22, etc.
>
> Fixed in Shepherd commit 63af9d7c4460b55953bfa199ea44ac0114289b64.
>
> We’ll have to make a new release soon.

Released 0.10.1, and updated the package in commit
b8f89ab2c9d0c459ce158ee16a4f4a6542b88ce0.

Ludo’.

[Message part 3 (message/rfc822, inline)]

From: Ludovic Courtès <ludovic.courtes <at> inria.fr>
To: bug-guix <at> gnu.org
Subject: [Shepherd] Replaced services remain active in the shadows
Date: Thu, 25 May 2023 14:59:22 +0200

Hello!

A bug we noticed with the Shepherd 0.10.0 on berlin: after
reconfiguring, which registers a “replacement” for services currently
running, restarting said services (with ‘herd restart’ or similar, which
is supposed to instate the replacement) happens to leave the old service
behind.

Example: ‘ssh-daemon’ is marked as stopped because it cannot bind to
port 22; indeed, there’s still a service listening on port 22, the one
service that should have been replaced.

Likewise for ‘cuirass-web’ for instance: it’s marked as failing to
start, but in fact it’s running; if you try to kill the ‘cuirass web’
process, you can see it’s respawned and /var/log/messages shows that
very clearly.

What seems to happen is that, in both cases, the registry points to the
new service; ‘herd status’ & co. look up the service by name in the
registry, find the new service, and rightfully show that it’s stopped.
But the old service still exists: it’s no longer in the registry, but it
handles SIGCHLD, incoming connections on port 22, etc.

Ludo’.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.