[systemd-devel] [PATCH] systemd.service(5): clarify behavior of SuccessExitStatus

[Dave Reisner]

On Fri, Dec 27, 2013 at 09:09:21PM +0100, Lennart Poettering wrote:
> On Fri, 27.12.13 17:00, Zbigniew Jędrzejewski-Szmek (zbyszek at in.waw.pl) wrote:
> 
> > 
> > On Fri, Dec 27, 2013 at 10:46:48AM -0500, Dave Reisner wrote:
> > > The behavior of this is a little cryptic in that $MAINPID must exit as
> > > a direct result of receiving a signal in order for a listed signal to
> > > be considered a success condition.
> > > ---
> > >  man/systemd.service.xml | 5 ++++-
> > >  1 file changed, 4 insertions(+), 1 deletion(-)
> > > 
> > > diff --git a/man/systemd.service.xml b/man/systemd.service.xml
> > > index 27f069f..c3a9307 100644
> > > --- a/man/systemd.service.xml
> > > +++ b/man/systemd.service.xml
> > > @@ -737,7 +737,10 @@ ExecStart=/bin/echo $ONE $TWO ${TWO}
> > >                                  <constant>SIGTERM</constant> and <constant>SIGPIPE</constant>. Exit status
> > >                                  definitions can either be numeric exit
> > >                                  codes or termination signal names,
> > > -                                separated by spaces. Example:
> > > +                                separated by spaces. Signals will only
> > > +                                be considered if the service does not implement
> > > +                                a signal handler and exits as a direct result
> > > +                                of receiving the signal. Example:
> > >                                  <literal>SuccessExitStatus=1 2 8
> > >                                  <constant>SIGKILL</constant></literal>, ensures that exit
> > >                                  codes 1, 2, 8 and the termination
> > This is incorrect/misleading too. Normally you're supposed to have a
> > signal handler, do cleanup, uninstall the handler, and then signal
> > yourself again.
> 
> We certainly don't do that in systemd... I never heard of that
> suggestion, I must say. (Any link where this is suggested?) I must say
> that Dave's addition sounded correct to me, even though you do have a
> point that one can uninstall the signal handler and trigger the signal
> again...

I suppose a9a305332b addresses both sides of this. Thanks!