Re: s6: something like runit's ./check script

On Thu, Sep 17, 2015 at 9:44 AM, Buck Evan wrote: > My proposal was to read a /start-timeout file for this purpose. > > It seems like seq | xargs would do what you need. > I suppose s6 doesn't want to depend on those. > seq | xargs would work too. s6 wouldn't depend on those, the service in questi

Re: s6: something like runit's ./check script

On Thu, Sep 17, 2015 at 9:44 AM, Buck Evan wrote: > My proposal was to read a /start-timeout file for this purpose. > > It seems like seq | xargs would do what you need. > I suppose s6 doesn't want to depend on those. > seq | xargs would work too. s6 wouldn't depend on those, the service in questi

Re: s6: something like runit's ./check script

My proposal was to read a /start-timeout file for this purpose. It seems like seq | xargs would do what you need. I suppose s6 doesn't want to depend on those. On Thu, Sep 17, 2015 at 7:17 AM, Colin Booth wrote: > On Thu, Sep 17, 2015 at 3:02 AM, Laurent Bercot > wrote: > > > > Sure, that's d

Re: s6: something like runit's ./check script

On Thu, Sep 17, 2015 at 3:02 AM, Laurent Bercot wrote: > > Sure, that's doable. > However, remember that s6-maximumtime is part of s6-portable-utils, > so you're introducing an additional dependency there. > True. I'm simply not sure it's possible to make something with a variable length timed d

Re: s6: something like runit's ./check script

On 17/09/2015 07:21, Colin Booth wrote: Laurent, would you consider changing s6-maximumwait to accept 0 as "fork and wait forever"? Sure, that's doable. However, remember that s6-maximumtime is part of s6-portable-utils, so you're introducing an additional dependency there. -- Laurent

Re: s6: something like runit's ./check script

I think I've found what should be the cannonical timered ./check equivalent script. On Tue, Sep 8, 2015 at 9:29 AM, Buck Evan wrote: Original normalized versions: > > Laurent's: > #!/command/execlineb -P > background -d > { > fdmove 1 3 > forx -x 0 dummy { 1 2 3 4 5 6 7 } > ifelse { ./check

Re: s6: something like runit's ./check script

On Tue, Sep 8, 2015 at 9:29 AM, Buck Evan wrote: > Putting them side by side for my own benefit, and normalizing Colin's > terminology and formatting: > > It looks to me like the only notable difference is Colin's 'fdmove -c 2 1'. > If I understand it, this is redirecting stderr to stdout, which w

Re: s6: something like runit's ./check script

Putting them side by side for my own benefit, and normalizing Colin's terminology and formatting: Laurent's: #!/command/execlineb -P background -d { fdmove 1 3 forx -x 0 dummy { 1 2 3 4 5 6 7 } ifelse { ./check } { echo } foreground { sleep 1 } exit 1 } fdclose 3 ./run.real Colin's: #!/

Re: s6: something like runit's ./check script

Ok that solves my confusion. I think we all agree that a runit style sv-check doesn't fit in s6-packaging; we can safely call that topic closed. Whether there should a an eased path to supporting services that need polling is another topic, I feel sure. Laurent is theoretically amenable to adding

Re: s6: something like runit's ./check script

On 08/09/2015 15:04, Jan Bramkamp wrote: Not if something kills the polling script e.g. stray kill -9 $WRONG_PID. Yeah, yeah. It's a question of risk assessment. We supervise long-lived processes because in the course of their lives, they may receive a stray signal, but more likely, they may

Re: s6: something like runit's ./check script

On 08/09/15 14:50, Laurent Bercot wrote: On 08/09/2015 14:10, Jan Bramkamp wrote: How would the ./run script or more likely the daemon it exec()ed into die from a failed child process? The child process could s6-svc -t if it fails to find readiness, for instance. There should be an option i

Re: s6: something like runit's ./check script

On 08/09/2015 14:10, Jan Bramkamp wrote: How would the ./run script or more likely the daemon it exec()ed into die from a failed child process? The child process could s6-svc -t if it fails to find readiness, for instance. There should be an option in the polling tool to kill the daemon if th

Re: s6: something like runit's ./check script

On 08/09/15 14:05, Laurent Bercot wrote: On 08/09/2015 13:51, Jan Bramkamp wrote: If the script fails for any reason the service is stuck and won't come up. Such simple scripts shouldn't fail but they might still run into resource limits or other (temporary) problems. If the polling script

Re: s6: something like runit's ./check script

On 08/09/2015 13:51, Jan Bramkamp wrote: If the script fails for any reason the service is stuck and won't come up. Such simple scripts shouldn't fail but they might still run into resource limits or other (temporary) problems. If the polling script fails, it will die. The run script will the

Re: s6: something like runit's ./check script

On 08/09/15 13:24, Laurent Bercot wrote: On 08/09/2015 10:49, Jan Bramkamp wrote: - Have one polling daemon. - A wrapper registers polled services with the polling daemon. No can do, sorry. You can't make a supervision infrastructure depend on daemons, because daemons depend on a supervis

Re: s6: something like runit's ./check script

On 08/09/2015 10:49, Jan Bramkamp wrote: - Have one polling daemon. - A wrapper registers polled services with the polling daemon. No can do, sorry. You can't make a supervision infrastructure depend on daemons, because daemons depend on a supervision infrastructure. The polling daemon would

Re: s6: something like runit's ./check script

On 03/09/15 20:23, Laurent Bercot wrote: On 03/09/2015 18:25, Buck Evan wrote: An s6-checkhelper wrapper that implements exactly the above would make me happy enough. Yes, that's envisionable. I'll think about it. I pondered over the problem and came up with the following conclusions: -

Re: s6: something like runit's ./check script

On Sep 7, 2015 2:53 PM, "Buck Evan" wrote: > Here you go. I made a few minor changes after this thread started (pulling the fdmove into the background block for example) which are reflected here: #!/command/execlineb -P fdmove -c 2 1 background -d { fdmove 1 3 loopwhilex -o 1 ifelse { /bin/

Re: s6: something like runit's ./check script

On Sep 7, 2015 2:53 PM, "Buck Evan" wrote: > > Colin: > > Can we have a look at the script you're referring to? > > Are you making a point in favor of explicit ./check support in s6, or against, or something else? I can't quite tell. > > --phone is hard. > Sorry! Explicit ./check-like behavior bak

Re: s6: something like runit's ./check script

Colin: Can we have a look at the script you're referring to? Are you making a point in favor of explicit ./check support in s6, or against, or something else? I can't quite tell. --phone is hard. On Sep 4, 2015 9:44 AM, "Colin Booth" wrote: > On Wed, Sep 2, 2015 at 3:07 PM, Laurent Bercot > w

Re: s6: something like runit's ./check script

On Wed, Sep 2, 2015 at 3:07 PM, Laurent Bercot wrote: > echo 3 > notification-fd > > mv run run.real > > cat > run < #!/command/execlineb -P > background -d > { > fdmove 1 3 > forx -x 0 dummy { 1 2 3 4 5 6 7 } > ifelse { ./check } { echo } > foreground { sleep 1 } > exit 1 > } > fdclose

Re: s6: something like runit's ./check script

On 03/09/2015 18:25, Buck Evan wrote: An s6-checkhelper wrapper that implements exactly the above would make me happy enough. Yes, that's envisionable. I'll think about it. if a ./check exists, the framework does the polling for me. The thing is, the command that does the polling is "sv

Re: s6: something like runit's ./check script

My apologies. I should have known you wanted an actual discussion. An s6-checkhelper wrapper that implements exactly the above would make me happy enough. This is probably what I'll implement for myself in the meantime. What I was picturing originally was the same as the runit contract: if a ./ch

Re: s6: something like runit's ./check script

On 03/09/2015 12:44, Crest wrote: Starting an unsupervised background process is a brittle workaround. It's not a brittle workaround, it's the exact right way to do it. You want to poll for service readiness until a certain timeout? well, then start a process that polls for service readiness u

Re: s6: something like runit's ./check script

On 03.09.2015 09:26, Laurent Bercot wrote: > On 03/09/2015 03:18, Buck Evan wrote: >> I'll just take that as a no. > > I honestly don't understand what a "yes" would entail. > What functionality would you like to see, what changes > to the current s6 behaviour would you like to see? > Starting

Re: s6: something like runit's ./check script

On 03/09/2015 03:18, Buck Evan wrote: I'll just take that as a no. I honestly don't understand what a "yes" would entail. What functionality would you like to see, what changes to the current s6 behaviour would you like to see? -- Laurent

Re: s6: something like runit's ./check script

I'll just take that as a no. Thanks :) On Wed, Sep 2, 2015 at 5:50 PM, Laurent Bercot wrote: > On 03/09/2015 01:55, Buck Evan wrote: > >> That seems like a lot of brain surgery for this essential feature. >> > > Brain surgery? That's just spawning a process running ./check up to > seven times a

Re: s6: something like runit's ./check script

On 03/09/2015 01:55, Buck Evan wrote: That seems like a lot of brain surgery for this essential feature. Brain surgery? That's just spawning a process running ./check up to seven times and sending the notification newline to the right fd if one of the invocations succeeds. That's exactly what

Re: s6: something like runit's ./check script

That seems like a lot of brain surgery for this essential feature. My users are CSS experts. I think I'll spawn such a background process from my framework by default if ./check exists. I suppose you have no inkling of making ./check an s6 feature? On Wed, Sep 2, 2015 at 3:07 PM, Laurent Bercot

Re: s6: something like runit's ./check script

On 02/09/2015 23:14, Buck Evan wrote: Given a daemon that doesn't have a readyfile feature, I'd like to write a `check` script and hook it up to s6's readiness notification . echo 3 > notification-fd mv run run.real cat > run <

s6: something like runit's ./check script

Given a daemon that doesn't have a readyfile feature, I'd like to write a `check` script and hook it up to s6's readiness notification . It's not immediately clear to me how to do this without introducing mounds of bugs. Do any of you have prior a