Hello, Maxim Cournoyer <maxim.courno...@gmail.com> writes:
> Hello, > > I just noticed about this problem following a reboot. I can also > reproduce it in 'guix system vm', simply adding the opendht-service-type > to my operating-system declaration. > > The boot proceeds until 'error in finalization thread: Success' then > hangs indefinitely. > > What is troubling for me is that the service is rather straightforwardly > defined. It uses the make-forkexec-constructor/container like so: > > (define (opendht-shepherd-service config) > "Return a <shepherd-service> running OpenDHT." > (shepherd-service > (documentation "Run an OpenDHT node.") > (provision '(opendht dhtnode dhtproxy)) > (requirement '(user-processes syslogd)) > (start #~(make-forkexec-constructor/container > (list #$@(opendht-configuration->command-line-arguments config)) > #:mappings (list (file-system-mapping > (source "/dev/log") ;for syslog > (target source))) > #:user "opendht")) > (stop #~(make-kill-destructor)))) > > I'm not sure how using such basic building blocks could lead to a hang > in Shepherd ? It seems Shepherd can't cope with a failing start procedure/script when a variable was not bound. To diagnose the problem, the best way ended up being to extract the code of the constructor in a separate script to run it separately. This made the error quickly apparent: "Unbound variable: file-system-mapping". We should try to handle this class of errors in Shepherd and report a useful message and *not* crash Shepherd or otherwise hang. Pushed with commit a09cdf1f9d. Closing. Maxim