Re: Bug in s6-svc -wr?

2021-04-26 Thread Laurent Bercot



 The latest s6 git now supports -r and -R operations for s6-svwait.
 If testing shows it's good, it will be integrated into the next
release.

--
 Laurent



Re: Bug in s6-svc -wr?

2021-04-25 Thread Laurent Bercot

"s6-svwait -wD foo && s6-svwait -wu foo".


 Hmf. "s6-svwait -D foo && s6-svwait -U foo", obviously.

--
 Laurent



Re: Bug in s6-svc -wr?

2021-04-25 Thread Laurent Bercot

And you mean, just -wr is invalid at all, but -wu not?


 s6-svc -w options are really a shortcut for longer command lines
involving s6-svwait and/or s6-svlisten1; I added them as an afterthought
because people wanted them. Then, I added -r options by popular demand
as well.
 The problem with adding features as an afterthought under popular
pressure is that not all interactions can be perfectly thought out,
and yes, there is an inconsistency here.

 Waiting for a restart is an inherently more complicated case than
other waits, because it involves waiting for a stop *then* for a start.
And depending on whether there are other operations involved other
than the wait, the command that s6-svc rewrites itself into is not
the same. You found the case that was not handled in the same manner
as others. :/

 I will fix the s6-svc -wr case. In the meantime, to just wait for
a restart without triggering a restart yourself, please use:
"s6-svwait -wD foo && s6-svwait -wu foo".

--
 Laurent



Re: Bug in s6-svc -wr?

2021-04-25 Thread Oliver Schad
On Sat, 24 Apr 2021 17:33:05 +
Colin Booth  wrote:

> That said, the documentation could be more clear about -wr/-wR
> requiring an action to differentiate them from the other wait states.

Even if I didn't get immediatly, that the waiting is independent from
the action (I expected that waiting means also "do that" - after
waiting forever I've got that), I would expect that all "wrong" options
are refused by the called tool itself instead of calling another tool
with invalid options.

And you mean, just -wr is invalid at all, but -wu not?

Best Regards
Oli

-- 
Automatic-Server AG •
Oliver Schad
Geschäftsführer
Turnerstrasse 2
9000 St. Gallen | Schweiz

www.automatic-server.com | oliver.sc...@automatic-server.com
Tel: +41 71 511 31 11 | Mobile: +41 76 330 03 47


pgpTsn6tAPZMv.pgp
Description: OpenPGP digital signature


Re: Bug in s6-svc -wr?

2021-04-24 Thread Colin Booth
On Sat, Apr 24, 2021 at 02:46:12PM +0200, Oliver Schad wrote:
> Hi everbody,
> 
> if I call "s6-svc -wr servicedir", I get an error message:
> 
> s6-svwait: usage: s6-svwait [ -U | -u | -d | -D ] [ -a | -o ] [ -t
> timeout ] servicedir...
> 
> If I strace that, I find:
> 
> execve("/usr/bin/s6-svwait", ["/usr/bin/s6-svwait", "-r", "--",
> "/run/s6-rc/scandir/nginx/"], [/* 19 vars */]) = 0
> 
> But my s6-svwait doesn't support the option "-r". Is the option missing
> or the call broken?
> 
In this case it's user error. s6-svc does different things depending on
if you give it an action in addition to a wait option or only a wait
option. `s6-svc -wX service' runs `s6-svwait -X service' whereas 
`s6-svc -wX -Y service' runs `s6-svlisten1 -X service s6-svc -Y service'
instead. Unlike s6-svwait, s6-svlisten1 does have the -r option and will
behave mostly as expected.

The thing to keep in mind here is that the -wX options are for
synchronization only - `s6-svc -wu' does not actually tell the service
to go up. In the case of -wr/-wR, those are edge-triggered waits ("wait
for a service to transition from down to up") as opposed to the rest
which are level-triggered ("wait for the service to reach the up
status") and can be true immediately if the service is already at the
desired state. Ergo, it doesn't particularly make sense to wait on
restart events without also triggering a state change.

That said, the documentation could be more clear about -wr/-wR requiring
an action to differentiate them from the other wait states.

-- 
Colin Booth