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.