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