runit - access to run script's exit status for finish?

runit - access to run script's exit status for finish?

[Charles Duffy]

It would be useful to let my finish script take different actions based on
the exit status of my run script.

Is a mechanism for doing this available? If not, consider this a feature
request.

Re: runit - access to run script's exit status for finish?

[Gerrit Pape]

On Wed, May 25, 2005 at 11:26:21AM -0500, Charles Duffy wrote:
> It would be useful to let my finish script take different actions based on
> the exit status of my run script.

Would you mind giving an example of that usage?

> Is a mechanism for doing this available? If not, consider this a feature
> request.

It's not supported AFAIK.  Do you already have an idea how this
information should be passed to ./finish?

Regards, Gerrit.

Re: runit - access to run script's exit status for finish?

[Laurent Bercot]

> It's not supported AFAIK.  Do you already have an idea how this
> information should be passed to ./finish?

 Why not as an argument to the finish script ?

-- 
 Ska

Re: runit - access to run script's exit status for finish?

[Gerrit Pape]

On Mon, May 30, 2005 at 09:42:33AM +0200, Laurent Bercot wrote:
> > It's not supported AFAIK.  Do you already have an idea how this
> > information should be passed to ./finish?
> 
>  Why not as an argument to the finish script ?

This was my first idea also.  But when starting to add arguments to
service scripts, maybe there's more information we can pass.  How about
the basename of the service directory, or what about ./run knowing the
exit code from ./finish?

Thanks, Gerrit.

Re: runit - access to run script's exit status for finish?

[Paul Jarc]

Gerrit Pape <pape@smarden.org> wrote:
> But when starting to add arguments to service scripts, maybe there's
> more information we can pass.

Environment variables make that easy.  How about setting $RUN_STATUS?


paul

Re: runit - access to run script's exit status for finish?

[Gerrit Pape]

On Tue, May 31, 2005 at 10:28:25AM -0400, Paul Jarc wrote:
> Gerrit Pape <pape@smarden.org> wrote:
> > But when starting to add arguments to service scripts, maybe there's
> > more information we can pass.
> 
> Environment variables make that easy.  How about setting $RUN_STATUS?

Yes, this would be more flexible.  But on the other hand this is a
change to the process state of all service daemons, currently their
environment is well-defined through /etc/runit/2, or runsvdir-start.

What about adding the return code to ./supervise/status?

Regards, Gerrit.

Re: runit - access to run script's exit status for finish?

[Joan Picanyol i Puig]

* Gerrit Pape <pape@smarden.org> [20050531 21:07]:
> On Tue, May 31, 2005 at 10:28:25AM -0400, Paul Jarc wrote:
> > 
> > Environment variables make that easy.  How about setting $RUN_STATUS?
> 
> But on the other hand this is a change to the process state of all
> service daemons, currently their environment is well-defined through
> /etc/runit/2, or runsvdir-start.
> 
> What about adding the return code to ./supervise/status?

I usually empty the environment in my run scripts, so I'd prefer this
solution.

qvb
-- 
pica

Re: runit - access to run script's exit status for finish?

[Charles Duffy]

On Wed, 01 Jun 2005 02:05:21 +0200, Joan Picanyol i Puig wrote:

> * Gerrit Pape <pape@smarden.org> [20050531 21:07]:
>> On Tue, May 31, 2005 at 10:28:25AM -0400, Paul Jarc wrote:
>> > 
>> > Environment variables make that easy.  How about setting $RUN_STATUS?
>> 
>> But on the other hand this is a change to the process state of all
>> service daemons, currently their environment is well-defined through
>> /etc/runit/2, or runsvdir-start.
>> 
>> What about adding the return code to ./supervise/status?
> 
> I usually empty the environment in my run scripts, so I'd prefer this
> solution.

I thought the format of supervise/status was opaque, and prone to changing
between releases. Am I incorrect? (Certainly, it doesn't look trivial to
parse from a shell script).

Also, what's the status of this enhancement?

Re: runit - access to run script's exit status for finish?

[Gerrit Pape]

On Fri, Aug 26, 2005 at 03:30:23PM -0500, Charles Duffy wrote:
> On Wed, 01 Jun 2005 02:05:21 +0200, Joan Picanyol i Puig wrote:
> > * Gerrit Pape <pape@smarden.org> [20050531 21:07]:
> >> On Tue, May 31, 2005 at 10:28:25AM -0400, Paul Jarc wrote:
> >> > 
> >> > Environment variables make that easy.  How about setting $RUN_STATUS?
> >> 
> >> But on the other hand this is a change to the process state of all
> >> service daemons, currently their environment is well-defined through
> >> /etc/runit/2, or runsvdir-start.
> >> 
> >> What about adding the return code to ./supervise/status?
> > 
> > I usually empty the environment in my run scripts, so I'd prefer this
> > solution.
> 
> I thought the format of supervise/status was opaque, and prone to changing
> between releases. Am I incorrect? (Certainly, it doesn't look trivial to
> parse from a shell script).

It's not easy to use in a shell script, true.

> Also, what's the status of this enhancement?

I still don't know what's the best way to pass this information to the
./finish script.  Providing the exit code of ./run through the
environment seems to be the best solution, but (1) only the ./finish
script's environment should be altered, not the ./run script's, and (2)
runsv currently doesn't allocate memory dynamically, I don't want to
change that.

So, nothing has been done until now.

Regards, Gerrit.

Re: runit - access to run script's exit status for finish?

[Charles Duffy]

On Sat, 27 Aug 2005 19:24:35 +0000, Gerrit Pape wrote:

> I still don't know what's the best way to pass this information to the
> ./finish script.  Providing the exit code of ./run through the
> environment seems to be the best solution, but (1) only the ./finish
> script's environment should be altered, not the ./run script's, and (2)
> runsv currently doesn't allocate memory dynamically, I don't want to
> change that.

Hmm.

I suppose doing an unsetenv() is unacceptable because it would interfere
wih run's environment if run had set (or was expecting the outside world
to set) a variable with the same name. Personally, to be honest, I'd
consider this acceptable so long as it was documented and the chosen name
was unlikely to collide with anything -- but even so, I can appreciate our
reluctance to go this route.

Your suggestion of stuffing it in the status file makes sense, then -- but
a convenient way to get the info still out is still needed. How about
having an argument to runsvstat to retrieve *only* this piece of
information? (For that matter, being able to do the same with other data
in the status file would be likewise useful).

Re: runit - access to run script's exit status for finish?

[Charles Duffy]

As an addendum to my last post -- if we decide on an interface, I wouldn't
excessively mind trying my hand at writing a patch to implement it, if
you'd prefer that I do so.

WRT why this would be useful, btw -- there are a few cases right now where
I'd like my run script to end with an exec, but it can't because there
needs some action to be taken based on exit status. Moving these actions
into the finish script would thus make my life somewhat easier.

Re: runit - access to run script's exit status for finish?

[Gerrit Pape]

On Sat, Aug 27, 2005 at 05:56:34PM -0500, Charles Duffy wrote:
> On Sat, 27 Aug 2005 19:24:35 +0000, Gerrit Pape wrote:
> > I still don't know what's the best way to pass this information to the
> > ./finish script.  Providing the exit code of ./run through the
> > environment seems to be the best solution, but (1) only the ./finish
> > script's environment should be altered, not the ./run script's, and (2)
> > runsv currently doesn't allocate memory dynamically, I don't want to
> > change that.
> 
> I suppose doing an unsetenv() is unacceptable because it would interfere
> wih run's environment if run had set (or was expecting the outside world
> to set) a variable with the same name. Personally, to be honest, I'd
> consider this acceptable so long as it was documented and the chosen name
> was unlikely to collide with anything -- but even so, I can appreciate our
> reluctance to go this route.
> 
> Your suggestion of stuffing it in the status file makes sense, then -- but
> a convenient way to get the info still out is still needed. How about
> having an argument to runsvstat to retrieve *only* this piece of
> information? (For that matter, being able to do the same with other data
> in the status file would be likewise useful).

This sounds like a very good idea.  I didn't re-check, but it should be
possible to extend the supervise/status file by two bytes, being the
last return code from ./run and ./finish, initially 0, without breaking
backward compatibility.

To query this information, I would prefer to extend the sv program, not
runsvstat.  runsvctrl, runsvstat, svwaitdown, svwaitup, most probably
will get obsolete some time, as the functionality is integrated into sv.
I'm not sure about the user interface, whether sv should support special
commands for this, or command line switches, or so.

Regards, Gerrit.

Re: runit - access to run script's exit status for finish?

[Charles Duffy]

Gerrit Pape wrote:
> To query this information, I would prefer to extend the sv program, not
> runsvstat.  runsvctrl, runsvstat, svwaitdown, svwaitup, most probably
> will get obsolete some time, as the functionality is integrated into sv.
> I'm not sure about the user interface, whether sv should support special
> commands for this, or command line switches, or so.

How about a subcommand with switches? Something like:

$ sv status <service1> <service2> ...
service1 STATUS (up|down|...)
service1 TIME <number-of-seconds>
service1 LASTEXIT <last run command's exit status>
service2 STATUS (up|down|...)
service2 TIME <number-of-seconds>
service2 LASTEXIT <last run command's exit status>
...

$ sv status -s <service1> <service2> ...
<state-of-service1>
<state-of-service2>

$ sv status -t <service1> <service2> ...
<number-of-seconds-for-service1>
<number-of-seconds-for-service2>

$ sv status -e <service1> <service2> ...
<last run command's exit status for service1>
<last run command's exit status for service2>

and so forth.

The full "sv status" output is trivially handlable with gawk, whereas 
the specific items (selectable w/ a flag) don't require even that, 
particularly if there's only one service named.

Re: runit - access to run script's exit status for finish?

[Gerrit Pape]

On Mon, Aug 29, 2005 at 05:08:16AM -0500, Charles Duffy wrote:
> Gerrit Pape wrote:
> >To query this information, I would prefer to extend the sv program, not
> >runsvstat.  runsvctrl, runsvstat, svwaitdown, svwaitup, most probably
> >will get obsolete some time, as the functionality is integrated into sv.
> >I'm not sure about the user interface, whether sv should support special
> >commands for this, or command line switches, or so.
> 
> How about a subcommand with switches? Something like:
> 
> $ sv status <service1> <service2> ...
> service1 STATUS (up|down|...)
> service1 TIME <number-of-seconds>
> service1 LASTEXIT <last run command's exit status>
> service2 STATUS (up|down|...)
> service2 TIME <number-of-seconds>
> service2 LASTEXIT <last run command's exit status>
> ...

I would prefer not to change the current output of 'sv status'.

> $ sv status -s <service1> <service2> ...
> <state-of-service1>
> <state-of-service2>
> 
> $ sv status -t <service1> <service2> ...
> <number-of-seconds-for-service1>
> <number-of-seconds-for-service2>
> 
> $ sv status -e <service1> <service2> ...
> <last run command's exit status for service1>
> <last run command's exit status for service2>
> 
> and so forth.

This I like.  Instead of command line switches to the status command, we
could also use specific commands, such as
 $ sv status-pid <service1> <service2>
 <pid-service1>
 <pid-service2>
 $ sv status-uptime <service1>
 <number-of-seconds-for-service1>
 $ 
 ...
 
> The full "sv status" output is trivially handlable with gawk, whereas 
> the specific items (selectable w/ a flag) don't require even that, 
> particularly if there's only one service named.

Jup, thanks, Gerrit.

Re: runit - access to run script's exit status for finish?

[Charles Duffy]

Gerrit Pape wrote:
> On Mon, Aug 29, 2005 at 05:08:16AM -0500, Charles Duffy wrote:
>>$ sv status -e <service1> <service2> ...
>><last run command's exit status for service1>
>><last run command's exit status for service2>
>>
>>and so forth.
> 
> This I like.  Instead of command line switches to the status command, we
> could also use specific commands, such as
>  $ sv status-pid <service1> <service2>
>  <pid-service1>
>  <pid-service2>
>  $ sv status-uptime <service1>
>  <number-of-seconds-for-service1>
>  $ 
>  ...

Yes, that'd work too. My instinct would be to use flags if we have a 
particularly large number of items that could be queried, or subcommands 
if it's going to remain a fairly small set.

Right now we've got:
- PID
- uptime
- current state
- desired state
- last exit status
...anything I'm missing?

Five is a small enough number to be reasonable -- I'm just a bit leery 
after GNU Arch (where one of the constant complaints from new users was 
the sheer number of subcommands).

It's your baby, though, and if I'm going to be writing a patch, my 
intent is for it to meet your standards.

Re: runit - access to run script's exit status for finish?

[Gerrit Pape]

On Tue, Aug 30, 2005 at 11:55:23AM -0500, Charles Duffy wrote:
> Gerrit Pape wrote:
> >On Mon, Aug 29, 2005 at 05:08:16AM -0500, Charles Duffy wrote:
> >>$ sv status -e <service1> <service2> ...
> >><last run command's exit status for service1>
> >><last run command's exit status for service2>
> >>
> >>and so forth.
> >
> >This I like.  Instead of command line switches to the status command, we
> >could also use specific commands, such as
> > $ sv status-pid <service1> <service2>
> > <pid-service1>
> > <pid-service2>
> > $ sv status-uptime <service1>
> > <number-of-seconds-for-service1>
> > $ 
> > ...
> 
> Yes, that'd work too. My instinct would be to use flags if we have a 
> particularly large number of items that could be queried, or subcommands 
> if it's going to remain a fairly small set.
> 
> Right now we've got:
> - PID
> - uptime
> - current state
> - desired state
> - last exit status
> ...anything I'm missing?
> 
> Five is a small enough number to be reasonable -- I'm just a bit leery 
> after GNU Arch (where one of the constant complaints from new users was 
> the sheer number of subcommands).

Yes, that's what I'm worried about too.  I think best is to use switches
to the command 'status' as you suggested, and also move the current
switches (-v, -w) behind the commands:

 sv <command> [-v] [-w sec] <service> ...
 sv status [-v] [-w sec] [-puswrf] <service> ...

 -p: pid
 -u: uptime
 -s: state
 -w: want state
 -r: last rc of ./run
 -f: last rc of ./finish

The switches that can also be combined, e.g.

 # sv status -sp <service0>
 <state> <pid>

> It's your baby, though, and if I'm going to be writing a patch, my 
> intent is for it to meet your standards.

Thanks a lot for your contribution.

Regards, Gerrit.

Re: runit - access to run script's exit status for finish?

[Charles Duffy]

Gerrit Pape wrote:
> This sounds like a very good idea.  I didn't re-check, but it should be
> possible to extend the supervise/status file by two bytes, being the
> last return code from ./run and ./finish, initially 0, without breaking
> backward compatibility.

 From what I've seen from the code so far, I agree that there shouldn't 
be backwards-compatibility issues.

However, on actually attempting to implement the interface we discussed, 
I've found it to be somewhat inadequate: It permits the user to retrieve 
the last exit status, but does *not* have any way to track there has 
been any exit at all within this run, nor whether the program terminated 
via a signal without calling exit() [and thus without setting an exit 
status].

I'm considering extending by sizeof(int)*2 and storing wait()'s output 
verbatim; that way, WIFEXITED/WIFSIGNALED/WTERMSIG/WEXITSTATUS are all 
available, and it's possible to determine if the last exit was via a 
signal (and if so, what).

This leaves open the question of how to expose this information to the 
user. I'm considering the following:

  -r: last exit type and value for ./run
  -f: last exit type and value for ./finish

could return instead of <rc>, <type>:<rc>, as in "signal:11", "exit:0", 
"exit:1" or "none:0" (if there has, as of yet, been no exit).


Thoughts?

Re: runit - access to run script's exit status for finish?

[Gerrit Pape]

On Mon, Sep 12, 2005 at 10:11:58AM -0500, Charles Duffy wrote:
> Gerrit Pape wrote:
> >This sounds like a very good idea.  I didn't re-check, but it should be
> >possible to extend the supervise/status file by two bytes, being the
> >last return code from ./run and ./finish, initially 0, without breaking
> >backward compatibility.
> 
> From what I've seen from the code so far, I agree that there shouldn't 
> be backwards-compatibility issues.
> 
> However, on actually attempting to implement the interface we discussed, 
> I've found it to be somewhat inadequate: It permits the user to retrieve 
> the last exit status, but does *not* have any way to track there has 
> been any exit at all within this run, nor whether the program terminated 
> via a signal without calling exit() [and thus without setting an exit 
> status].
> 
> I'm considering extending by sizeof(int)*2 and storing wait()'s output 
> verbatim; that way, WIFEXITED/WIFSIGNALED/WTERMSIG/WEXITSTATUS are all 
> available, and it's possible to determine if the last exit was via a 
> signal (and if so, what).
> 
> This leaves open the question of how to expose this information to the 
> user. I'm considering the following:
> 
>  -r: last exit type and value for ./run
>  -f: last exit type and value for ./finish
> 
> could return instead of <rc>, <type>:<rc>, as in "signal:11", "exit:0", 
> "exit:1" or "none:0" (if there has, as of yet, been no exit).
> 
> Thoughts?

It's a good idea to include this additional information into
supervise/status.  What I'm not sure about is the output "<type>:<rc>".
How about simply having the exit code (0-255) printed if ./run
terminated cleanly, the signal number prefixed with '-' if it
terminated due to an uncatched signal, and nothing if ./run didn't
terminate at all yet?:

 # sv status -r .
 0
 # 
./run terminated with return code 0.

 # sv status -r .
 -13
 # 
./run terminated due to uncatched SIGPIPE.

 # sv status -r .
 # 
./run didn't terminate yet, since the supervisor started.

Regards, Gerrit.

Re: runit - access to run script's exit status for finish?

[Paul Jarc]

Gerrit Pape <pape@smarden.org> wrote:
>  # sv status -r .
>  # 
> ./run didn't terminate yet, since the supervisor started.

Since the supervisor started, or since the last time ./run was
started?  The latter seems more useful to me.


paul

Re: runit - access to run script's exit status for finish?

[Gerrit Pape]

On Thu, Sep 15, 2005 at 08:18:06AM -0400, Paul Jarc wrote:
> Gerrit Pape <pape@smarden.org> wrote:
> >  # sv status -r .
> >  # 
> > ./run didn't terminate yet, since the supervisor started.
> 
> Since the supervisor started, or since the last time ./run was
> started?  The latter seems more useful to me.

Yes, I agree.  It should print nothing if ./run (or ./finish with -f) is
currently running.

Thanks, Gerrit.

Re: runit - access to run script's exit status for finish?

[Charles Duffy]

Gerrit Pape wrote:
> On Thu, Sep 15, 2005 at 08:18:06AM -0400, Paul Jarc wrote:
> 
>>Gerrit Pape <pape@smarden.org> wrote:
>>
>>> # sv status -r .
>>> # 
>>>./run didn't terminate yet, since the supervisor started.
>>
>>Since the supervisor started, or since the last time ./run was
>>started?  The latter seems more useful to me.
> 
> Yes, I agree.  It should print nothing if ./run (or ./finish with -f) is
> currently running.

That's not very useful when chaining, though.

If you run "sv status -r -p -s ." in a shell script, you're probably 
going to pipe it into something like "read exitstatus pid state"; 
excluding the exit status entirely if the program is currently running, 
then, means that you'd end up with your values stored in the wrong 
variables -- certainly not a desirable outcome.

At minimum, a placeholder like "-" or "N/A" should be printed if one 
desires to indicate that no exit has occured. (That said, I'm still fond 
of my type:value syntax).

Re: runit - access to run script's exit status for finish?

[Gerrit Pape]

On Thu, Sep 15, 2005 at 01:10:04PM -0500, Charles Duffy wrote:
> Gerrit Pape wrote:
> >On Thu, Sep 15, 2005 at 08:18:06AM -0400, Paul Jarc wrote:
> >>Gerrit Pape <pape@smarden.org> wrote:
> >>># sv status -r .
> >>># 
> >>>./run didn't terminate yet, since the supervisor started.
> >>Since the supervisor started, or since the last time ./run was
> >>started?  The latter seems more useful to me.
> >
> >Yes, I agree.  It should print nothing if ./run (or ./finish with -f) is
> >currently running.
> 
> That's not very useful when chaining, though.
> 
> If you run "sv status -r -p -s ." in a shell script, you're probably 
> going to pipe it into something like "read exitstatus pid state"; 
> excluding the exit status entirely if the program is currently running, 
> then, means that you'd end up with your values stored in the wrong 
> variables -- certainly not a desirable outcome.

True.

> At minimum, a placeholder like "-" or "N/A" should be printed if one 
> desires to indicate that no exit has occured. (That said, I'm still fond 
> of my type:value syntax).

Okay, if you prefer that type:value output, it's fine with me also.  If
for some reason it turns out to be inconvenient, we can still change it
afterwards.

Regards, Gerrit.