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

[Gerrit Pape <pape@smarden.org>]

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.