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

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 >

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

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

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 } >

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 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

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

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

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

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 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

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

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

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

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

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 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

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