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

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 64455 in the body.
You can then email your comments to 64455 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

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

From: "buma2023 <at> outlook.fr" <buma2023 <at> outlook.fr>
To: "bug-guix <at> gnu.org" <bug-guix <at> gnu.org>
Cc: "buma2023 <at> outlook.fr" <buma2023 <at> outlook.fr>
Subject: shepherd: unable to use redefined system/system* in 0.10.1
Date: Mon, 3 Jul 2023 17:46:33 +0000

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

Hello,

I am using happily shepherd since a few years as my init system on
Debian: amd64 (desktop and notebook), armhf (Cubox).

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 I add at the end of /etc/shepherd.scm:
(system "touch /tmp/somefile")

I have the same problem.

Strangely at build time the test tests/system-star.sh succeeds, and
after I have booted (without refering to a system/system* command) , I
can run:

# export PID=$$; herd eval root "(system \"echo success! >/proc/$PID/fd/1\")"

(in my case, output appears in /var/log/syslog so I need the redirection)

I have read a bit documentation and code to be aware that system and
system* were redefined in shepherd to be non blocking, I suspect the
problem is how this is done.

I would prefer to have new names in shepherd for the redefined
system/system* and keep the old ones intact.

I have a workaround for this problem: replacing system/system* by
helpers I use, like:

(define (system-value command)
  "Return first line of output when calling (system command)"
  (let* ((port (open-input-pipe command))
       (str (read-line port)))
    (close-pipe port)
    str))

but this is a band-aid.

[Message part 2 (text/html, inline)]

Message #8 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 00:46:05 +0200

Hi,

"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:

--8<---------------cut here---------------start------------->8---
$ 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
--8<---------------cut here---------------end--------------->8---

This is both with 0.10.1 and with
d5ed516e736ce473902cc86b5cf4f61f27ebb642.

To be continued…

Ludo’.

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’.

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

From: urb59 <at> sfr.fr
To: 64455 <at> debbugs.gnu.org
Subject: Re: bug#64455: shepherd: unable to use redefined system/system* in
 0.10.1
Date: Sun, 30 Jul 2023 19:23:10 +0200 (CEST)

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

‌Hello,

Sorry for the late reply, but release 0.10.2 didn't fix the issue.

Current workaround: suppressing redefinition of system/system* and suppressing running tests/system-star.sh

I am open to suggestions of how to help you debug that.

Don't reply to buma2023, it was me, but it's a throw away address no longer valid.
>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’.
>

Sincerely.

-- 

Bernard 

[Message part 2 (text/html, inline)]

Previous Next

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