bug#64455: shepherd: unable to use redefined system/system* in 0.10.1
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 gnu.org> skribis: > >> "buma2023 outlook.fr" 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 >>> #: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 >> #: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
bug#64455: shepherd: unable to use redefined system/system* in 0.10.1
Hi, Ludovic Courtès skribis: > "buma2...@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 >>#: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 >#: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’.
bug#64455: shepherd: unable to use redefined system/system* in 0.10.1
Hi, "buma2...@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 >#: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 #: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’.
bug#64455: shepherd: unable to use redefined system/system* in 0.10.1
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 #: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.
