GNU bug report logs - #64455
shepherd: unable to use redefined system/system* in 0.10.1

Previous Next

Full log

Message #13 received at 64455 <at> debbugs.gnu.org (full text, mbox):

From: Ludovic Courtès <ludo <at> gnu.org>
To: buma2023 <at> outlook.fr
Cc: 64455 <at> debbugs.gnu.org
Subject: Re: bug#64455: shepherd: unable to use redefined system/system* in
 0.10.1
Date: Tue, 11 Jul 2023 15:22:50 +0200

Hi,

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

> "buma2023 <at> outlook.fr" <buma2023 <at> outlook.fr> skribis:
>
>> I am using happily shepherd since a few years as my init system on
>> Debian: amd64 (desktop and notebook), armhf (Cubox).
>
> Interesting!  I didn’t know of such uses.
>
>> I was using 0.9.1 with guile-3.0.5 and fibers-1.1.1.
>>
>> I recently tried 0.10.1 with guile-3.0.9 and fibers 1.3.1 and
>> encountered a problem with using system and system* in my services:
>> the simple fact to have the symbol system or system* in
>> /etc/shepherd.scm or included files (even if the command is not
>> executed) leads to a misbehaving shepherd, more specifically the
>> shepherd socket disappears; the system boots but with multiple
>> instances of the launched daemons.
>>
>> If a system/system* command is executed while booting, shepherd
>> blocks at the point of its execution.
>>
>> Example of service causing the failure:
>>
>> (register-services
>>  (make <service>
>>    #:provides '(mytest)
>>    #:start (lambda args
>>            (system "touch /tmp/somefile")
>>            #t)
>>    ))
>>
>> The service is not started at boot, I have to do it manually afterwards,
>> but I never can go there, as the shepherd socket is missing.
>
> I can reproduce it like this:
>
> $ cat /tmp/t.conf
> (register-services
>  (make <service>
>    #:provides '(mytest)
>    #:start (lambda args
>              (system "touch /tmp/somefile")
>              #t)))
>
> (start 'mytest)
> $ shepherd -I -c/tmp/t.conf -s /tmp/sock 
> Starting service root...
> Service root started.
> Service root running with value #t.
> Service root has been started.
> Starting service mytest...
>   C-c C-z
> [1]+  Stopped                 shepherd -I -c/tmp/t.conf -s /tmp/sock
> $ bg
> [1]+ shepherd -I -c/tmp/t.conf -s /tmp/sock &
> $ herd -s /tmp/sock status
> herd: error: /tmp/sock: Connection refused
>
> This is both with 0.10.1 and with
> d5ed516e736ce473902cc86b5cf4f61f27ebb642.

Sorry, the bug is reproducible with 0.10.1 but *not* with
d5ed516e736ce473902cc86b5cf4f61f27ebb642.

I believe this was fixed by Shepherd commit
2b310bd3b0ba0d7a08c77b456d34369cd6444edb (that is, after 0.10.1).

I think I’ll release 0.10.2 within a couple of weeks, but it would be
great if you could confirm that current Shepherd ‘master’ works for you.

Thanks!

Ludo’.

Previous Next

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