GNU bug report logs - #36731
shepherd lost track of nginx

Previous Next

Full log

View this message in rfc822 format

From: Mark H Weaver <mhw <at> netris.org>
To: Ludovic Courtès <ludo <at> gnu.org>
Cc: 36731 <at> debbugs.gnu.org, Robert Vollmert <rob <at> vllmrt.net>
Subject: bug#36731: shepherd lost track of nginx
Date: Sat, 20 Jul 2019 19:07:58 -0400

Hello,

Ludovic Courtès <ludo <at> gnu.org> writes:

> Robert Vollmert <rob <at> vllmrt.net> skribis:
>
>> The result was this:
>>
>> $ sudo herd restart nginx
>> Service nginx is not running.
>> herd: exception caught while executing 'start' on service 'nginx':
>> Throw to key `srfi-34' with args `("#<condition &invoke-error
>> [program:
>> \"/gnu/store/mlg0xfbiq03s812rm3v7mrlhyngas4xp-nginx-1.17.1/sbin/nginx\"
>> arguments: (\"-c\"
>> \"/gnu/store/r6gl9n7pwf4npiri05qxr40vdihdm2yy-nginx.conf\" \"-p\"
>> \"/var/run/nginx\") exit-status: 1 term-signal: #f stop-signal: #f]
>> 147e000>")’.

[…]

>> That error message could also be clearer about what’s going on. At any
>> rate, after I killed the nginx process, “herd start nginx” worked fine.
>
> I agree that we could and should improve the error message.

On the subject of this error message, why was the &invoke-error
condition serialized to a string before apparently being embedded within
another exception?  In other words, why did it print:

  Throw to key `srfi-34' with args `("#<condition &invoke-error [program: \"/gnu/store/mlg0xfbiq03s812rm3v7mrlhyngas4xp-nginx-1.17.1/sbin/nginx\" arguments: (\"-c\" \"/gnu/store/r6gl9n7pwf4npiri05qxr40vdihdm2yy-nginx.conf\" \"-p\" \"/var/run/nginx\") exit-status: 1 term-signal: #f stop-signal: #f] 147e000>")’.

instead of something closer to:

  Throw to key `srfi-34' with args `(#<condition &invoke-error [program: "/gnu/store/mlg0xfbiq03s812rm3v7mrlhyngas4xp-nginx-1.17.1/sbin/nginx" arguments: ("-c" "/gnu/store/r6gl9n7pwf4npiri05qxr40vdihdm2yy-nginx.conf" "-p" "/var/run/nginx") exit-status: 1 term-signal: #f stop-signal: #f] 147e000>)’.

We may want to go further in this specific case to make a user-friendly
error message, but in the more general case of printing arbitrary
exceptions, eliminating that second layer of string serialization would
help make the error reports a bit nicer to read.

What do you think?

      Mark

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.