* runit - access to run script's exit status for finish? @ 2005-05-25 16:26 Charles Duffy 2005-05-29 5:52 ` Gerrit Pape 0 siblings, 1 reply; 22+ messages in thread From: Charles Duffy @ 2005-05-25 16:26 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: runit - access to run script's exit status for finish? 2005-05-25 16:26 runit - access to run script's exit status for finish? Charles Duffy @ 2005-05-29 5:52 ` Gerrit Pape 2005-05-30 7:42 ` Laurent Bercot 0 siblings, 1 reply; 22+ messages in thread From: Gerrit Pape @ 2005-05-29 5:52 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: runit - access to run script's exit status for finish? 2005-05-29 5:52 ` Gerrit Pape @ 2005-05-30 7:42 ` Laurent Bercot 2005-05-31 11:49 ` Gerrit Pape 0 siblings, 1 reply; 22+ messages in thread From: Laurent Bercot @ 2005-05-30 7:42 UTC (permalink / raw) > 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 ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: runit - access to run script's exit status for finish? 2005-05-30 7:42 ` Laurent Bercot @ 2005-05-31 11:49 ` Gerrit Pape 2005-05-31 14:28 ` Paul Jarc 0 siblings, 1 reply; 22+ messages in thread From: Gerrit Pape @ 2005-05-31 11:49 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: runit - access to run script's exit status for finish? 2005-05-31 11:49 ` Gerrit Pape @ 2005-05-31 14:28 ` Paul Jarc 2005-05-31 19:09 ` Gerrit Pape 0 siblings, 1 reply; 22+ messages in thread From: Paul Jarc @ 2005-05-31 14:28 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: runit - access to run script's exit status for finish? 2005-05-31 14:28 ` Paul Jarc @ 2005-05-31 19:09 ` Gerrit Pape 2005-06-01 0:05 ` Joan Picanyol i Puig 0 siblings, 1 reply; 22+ messages in thread From: Gerrit Pape @ 2005-05-31 19:09 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: runit - access to run script's exit status for finish? 2005-05-31 19:09 ` Gerrit Pape @ 2005-06-01 0:05 ` Joan Picanyol i Puig 2005-08-26 20:30 ` Charles Duffy 0 siblings, 1 reply; 22+ messages in thread From: Joan Picanyol i Puig @ 2005-06-01 0:05 UTC (permalink / raw) * 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 ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: runit - access to run script's exit status for finish? 2005-06-01 0:05 ` Joan Picanyol i Puig @ 2005-08-26 20:30 ` Charles Duffy 2005-08-27 19:24 ` Gerrit Pape 0 siblings, 1 reply; 22+ messages in thread From: Charles Duffy @ 2005-08-26 20:30 UTC (permalink / raw) 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? ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: runit - access to run script's exit status for finish? 2005-08-26 20:30 ` Charles Duffy @ 2005-08-27 19:24 ` Gerrit Pape 2005-08-27 22:56 ` Charles Duffy 2005-08-27 23:01 ` Charles Duffy 0 siblings, 2 replies; 22+ messages in thread From: Gerrit Pape @ 2005-08-27 19:24 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: runit - access to run script's exit status for finish? 2005-08-27 19:24 ` Gerrit Pape @ 2005-08-27 22:56 ` Charles Duffy 2005-08-29 8:12 ` Gerrit Pape 2005-08-27 23:01 ` Charles Duffy 1 sibling, 1 reply; 22+ messages in thread From: Charles Duffy @ 2005-08-27 22:56 UTC (permalink / raw) 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). ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: runit - access to run script's exit status for finish? 2005-08-27 22:56 ` Charles Duffy @ 2005-08-29 8:12 ` Gerrit Pape 2005-08-29 10:08 ` Charles Duffy 2005-09-12 15:11 ` Charles Duffy 0 siblings, 2 replies; 22+ messages in thread From: Gerrit Pape @ 2005-08-29 8:12 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: runit - access to run script's exit status for finish? 2005-08-29 8:12 ` Gerrit Pape @ 2005-08-29 10:08 ` Charles Duffy 2005-08-30 11:06 ` Gerrit Pape 2005-09-12 15:11 ` Charles Duffy 1 sibling, 1 reply; 22+ messages in thread From: Charles Duffy @ 2005-08-29 10:08 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: runit - access to run script's exit status for finish? 2005-08-29 10:08 ` Charles Duffy @ 2005-08-30 11:06 ` Gerrit Pape 2005-08-30 16:55 ` Charles Duffy 0 siblings, 1 reply; 22+ messages in thread From: Gerrit Pape @ 2005-08-30 11:06 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: runit - access to run script's exit status for finish? 2005-08-30 11:06 ` Gerrit Pape @ 2005-08-30 16:55 ` Charles Duffy 2005-09-01 9:13 ` Gerrit Pape 0 siblings, 1 reply; 22+ messages in thread From: Charles Duffy @ 2005-08-30 16:55 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: runit - access to run script's exit status for finish? 2005-08-30 16:55 ` Charles Duffy @ 2005-09-01 9:13 ` Gerrit Pape 0 siblings, 0 replies; 22+ messages in thread From: Gerrit Pape @ 2005-09-01 9:13 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: runit - access to run script's exit status for finish? 2005-08-29 8:12 ` Gerrit Pape 2005-08-29 10:08 ` Charles Duffy @ 2005-09-12 15:11 ` Charles Duffy 2005-09-15 9:33 ` Gerrit Pape 1 sibling, 1 reply; 22+ messages in thread From: Charles Duffy @ 2005-09-12 15:11 UTC (permalink / raw) 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? ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: runit - access to run script's exit status for finish? 2005-09-12 15:11 ` Charles Duffy @ 2005-09-15 9:33 ` Gerrit Pape 2005-09-15 12:18 ` Paul Jarc 0 siblings, 1 reply; 22+ messages in thread From: Gerrit Pape @ 2005-09-15 9:33 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: runit - access to run script's exit status for finish? 2005-09-15 9:33 ` Gerrit Pape @ 2005-09-15 12:18 ` Paul Jarc 2005-09-15 14:46 ` Gerrit Pape 0 siblings, 1 reply; 22+ messages in thread From: Paul Jarc @ 2005-09-15 12:18 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: runit - access to run script's exit status for finish? 2005-09-15 12:18 ` Paul Jarc @ 2005-09-15 14:46 ` Gerrit Pape 2005-09-15 18:10 ` Charles Duffy 0 siblings, 1 reply; 22+ messages in thread From: Gerrit Pape @ 2005-09-15 14:46 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: runit - access to run script's exit status for finish? 2005-09-15 14:46 ` Gerrit Pape @ 2005-09-15 18:10 ` Charles Duffy 2005-09-16 8:15 ` Gerrit Pape 0 siblings, 1 reply; 22+ messages in thread From: Charles Duffy @ 2005-09-15 18:10 UTC (permalink / raw) 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). ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: runit - access to run script's exit status for finish? 2005-09-15 18:10 ` Charles Duffy @ 2005-09-16 8:15 ` Gerrit Pape 0 siblings, 0 replies; 22+ messages in thread From: Gerrit Pape @ 2005-09-16 8:15 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: runit - access to run script's exit status for finish? 2005-08-27 19:24 ` Gerrit Pape 2005-08-27 22:56 ` Charles Duffy @ 2005-08-27 23:01 ` Charles Duffy 1 sibling, 0 replies; 22+ messages in thread From: Charles Duffy @ 2005-08-27 23:01 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 22+ messages in thread
end of thread, other threads:[~2005-09-16 8:15 UTC | newest] Thread overview: 22+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2005-05-25 16:26 runit - access to run script's exit status for finish? Charles Duffy 2005-05-29 5:52 ` Gerrit Pape 2005-05-30 7:42 ` Laurent Bercot 2005-05-31 11:49 ` Gerrit Pape 2005-05-31 14:28 ` Paul Jarc 2005-05-31 19:09 ` Gerrit Pape 2005-06-01 0:05 ` Joan Picanyol i Puig 2005-08-26 20:30 ` Charles Duffy 2005-08-27 19:24 ` Gerrit Pape 2005-08-27 22:56 ` Charles Duffy 2005-08-29 8:12 ` Gerrit Pape 2005-08-29 10:08 ` Charles Duffy 2005-08-30 11:06 ` Gerrit Pape 2005-08-30 16:55 ` Charles Duffy 2005-09-01 9:13 ` Gerrit Pape 2005-09-12 15:11 ` Charles Duffy 2005-09-15 9:33 ` Gerrit Pape 2005-09-15 12:18 ` Paul Jarc 2005-09-15 14:46 ` Gerrit Pape 2005-09-15 18:10 ` Charles Duffy 2005-09-16 8:15 ` Gerrit Pape 2005-08-27 23:01 ` Charles Duffy
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).