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
