s6 supervision

[billa chaitanya]

Hi Team,

Is there an API/ command in s6 code to get the information of a process and
its pid by giving the service name that has started the process?

And does s6-svscan/s6-supervise have the knowledge of  service-name&
process name & process pid so that it can be fetched to another process
using IPC?


Thanks,
Chaitanya

Re: Some suggestions on old-fashioned usage with s6 2.10.x

[Casper Ti. Vector]

On Thu, Jan 28, 2021 at 10:41:24PM -0300, Guillermo wrote:
> Out of curiosity, do you have a reason for wanting to keep the
> "old-fashioned way"? Is it a goal of your project to depend on s6 and
> s6-rc, but not current s6-linux-init? It seems to me that doing so
> would be easier. It even looks like you could use the current
> /etc/slew/init/rc.{init,fin} scripts (perhaps with minor adjustments)
> as s6-linux-init's rc.init and rc.shutdown for slew, respectively.

Not using s6-linux-init has never been an explicit goal, but using
static scripts was a natural choice when s6-linux-init only provided
`s6-linux-init-maker', which produced scripts that were not that
flexible.

Currently I do not understand the `s6-linux-init-shutdown(d)' way
well, so the old-fashioned way is retained at least for now, given its
simplicity in implementation and seemingly better flexibility.  Frankly
it is my intuition that the new way costs more than the old way, but
does not provide that much in return.  (Feel free to prove me wrong.)

-- 
My current OpenPGP key:
RSA4096/0x227E8CAAB7AA186C (expires: 2022.09.20)
7077 7781 B859 5166 AE07 0286 227E 8CAA B7AA 186C

Re: Some suggestions on old-fashioned usage with s6 2.10.x

[Casper Ti. Vector]

On Fri, Jan 29, 2021 at 12:07:11AM +, Laurent Bercot wrote:
>  I may change it back, but I don't think the current state is broken,
> because you're not supposed to access git.skarnet.org via HTTP(S)! :P

Actually I do visit the CGit web interface fairly often, using it as
a poor man's GitHub workalike :)  Perhaps I need to batch change all
 references in the UP2020 document to
...

-- 
My current OpenPGP key:
RSA4096/0x227E8CAAB7AA186C (expires: 2022.09.20)
7077 7781 B859 5166 AE07 0286 227E 8CAA B7AA 186C

Re: Some suggestions on old-fashioned usage with s6 2.10.x

[Guillermo]

El jue, 28 ene 2021 a las 7:08, Casper Ti. Vector escribió:
>
> I did not actively follow the recent evolution of s6, and have just been
> bitten badly by s6 2.10.x on my Alpine servers (where slew [1] is used
> of course) when it comes along with other updates.
>
> [1] 
> [...]
> it will be nice if the old-fashioned way (with stage 1 and stage 3 as
> static scripts) is supported as well [...]

Out of curiosity, do you have a reason for wanting to keep the
"old-fashioned way"? Is it a goal of your project to depend on s6 and
s6-rc, but not current s6-linux-init? It seems to me that doing so
would be easier. It even looks like you could use the current
/etc/slew/init/rc.{init,fin} scripts (perhaps with minor adjustments)
as s6-linux-init's rc.init and rc.shutdown for slew, respectively.

G.

Re: Some suggestions on old-fashioned usage with s6 2.10.x

[Laurent Bercot]

BTW,  seems to be returning empty HTTP replies
now; both  and  work as
expected though.


 That is a side effect of a recent s6-networking addition, where
s6-tlsd passes the SNI server name to the application via an
environment variable. Which allows me to serve virtual hosts even with
a HTTP/1.0 server, but only under TLS. Fun experiment. :)

 I may change it back, but I don't think the current state is broken,
because you're not supposed to access git.skarnet.org via HTTP(S)! :P

--
 Laurent

Re: Some suggestions on old-fashioned usage with s6 2.10.x

[Casper Ti. Vector]

On Thu, Jan 28, 2021 at 05:21:59PM +, Laurent Bercot wrote:
>  There is no really good solution, and I prefer a short, sharp pain
> (when things break) followed by relief (when they're fixed) to a long
> dull ache (maintaining compat code).

I see.  I personally prefer to retain compat code if said code is so
small that it can hardly be incorrect, especially when the breakage
(like kernel panics) can be very severe.  Arguably a major stylistic
difference.

>  You seem to have found the proper way of managing this with SIG files,
> but just in case: "s6-svscanctl -tb" will net you the old behaviour.

Now I see; thanks.  I also realised that the revised `s6-svc -X'
proposal would result in wrong behaviour when there exists a `./finish'
script, because the supervisor would exit early (and prematurely).

BTW,  seems to be returning empty HTTP replies
now; both  and  work as
expected though.

-- 
My current OpenPGP key:
RSA4096/0x227E8CAAB7AA186C (expires: 2022.09.20)
7077 7781 B859 5166 AE07 0286 227E 8CAA B7AA 186C

Re: Some suggestions on old-fashioned usage with s6 2.10.x

[Roy Lanek]

> major version upgrades may break things.
As plain as day.

> I prefer a short, sharp pain (when things break) followed by
> relief (when they're fixed) to a long dull ache (maintaining
> compat code).

I could not agree more, it would also bring zero anyhow except
than extra, likely convoluted, code added which only increases
the risk of introducing new errors even after being removed.

/Roy Lanek (Yogyakarta)
-- 
555  5 l 4 c K W 4 r 3  L1NuX  555   air tenang menghanyutkan
555  5 l 4 c K W 4 r 3  L1NuX  555   still water runs deep

Re: Some suggestions on old-fashioned usage with s6 2.10.x

[Laurent Bercot]

I did not actively follow the recent evolution of s6, and have just been
bitten badly by s6 2.10.x on my Alpine servers (where slew [1] is used
of course) when it comes along with other updates.


 Sorry. This bears repeating: major version upgrades may break things.

 Compatibility is a good thing, that's why I try to keep major version
changes few and far between; but the other side of the coin is that
when I'm doing one, I want to make use of it and cram all the
incompatible changes that may be needed in the foreseeable future.
 So, you have to pay attention less often, but when it happens, you do
have to pay attention. Previous major version changes may have gone
smoothly - I try to keep it as smooth as possible when there's no need
to break UX - but it's no guarantee that it will always be smooth
sailing. This time, there were very visible user changes; sorry for
the inconvenience, but I reserve the right to do this, and I try to
document the breaking changes in the release notes.

 It is, admittedly, a drawback of distributions that they make major
version upgrades very silent - so, if you have local software that
relies on an old API, and the distro updates it under your feet,
you're caught unaware. I don't have a satisfying solution to this;
maybe I should have added a post-upgrade file printing red blinking
bold text, but that doesn't address automated or afk updates.



better if we kept the option supported for a transition period, and that
only removed it from the manual pages while urging users to get rid of
it.  After all, in this case, silently ignoring `-s' is behaviourly
similar to (if not perfectly compatible with) old `s6-svscan'.


 It's always a delicate balance, because "better" is not 
one-dimensional.

It would be better UX, yes, definitely. But also legacy code to maintain
until the next major update (which can take a while), and I tend to
assign a *very* high cost to legacy code in s6-svscan and s6-supervise,
for obvious reasons. And in my experience, few people (and you,
Casper, certainly belong to them!) actually bother changing their
scripts as long as they keep working - most only spring into action when
something breaks. A compromise I've found relatively efficient was to
add nagging warnings on deprecated option use, but 1. that's even more
code that will be removed, and 2. I hate nagware, with a passion, in
all its forms.
 There is no really good solution, and I prefer a short, sharp pain
(when things break) followed by relief (when they're fixed) to a long
dull ache (maintaining compat code). Especially when I'm not the one
experiencing the sharp pain ;)



Second, `s6-svscan' now waits for its `s6-supervise' children to exit
before exec()ing `.s6-svscan/finish'


 You seem to have found the proper way of managing this with SIG files,
but just in case: "s6-svscanctl -tb" will net you the old behaviour.

--
 Laurent

Re: Some suggestions on old-fashioned usage with s6 2.10.x

[Casper Ti. Vector]

On Thu, Jan 28, 2021 at 07:09:08PM +0800, Casper Ti. Vector wrote:
> Moreover, `.s6-svscan/finish' (linked to `rc.halt') will still need its
> $1 set to `reboot', `halt' or `poweroff' by `s6-svscan' on exec().

I did not realise the great simplification to the command line options
of `s6-svscanctl' would not have been possible if s6-svscan(ctl) need
to, for example, know about halt, poweroff and reboot.  Here I retract
the quoted statement; instead, I will rework the mechanism around
`.s6-svscan/SIG*' in slew, and yet attempt to make the behaviour
mostly backwards compatible.

-- 
My current OpenPGP key:
RSA4096/0x227E8CAAB7AA186C (expires: 2022.09.20)
7077 7781 B859 5166 AE07 0286 227E 8CAA B7AA 186C

Re: Some suggestions on old-fashioned usage with s6 2.10.x

[Casper Ti. Vector]

On Thu, Jan 28, 2021 at 06:08:36PM +0800, Casper Ti. Vector wrote:
> then move the `s6-svc -X' invocation from `rc.halt' into `rc.fin'

The `s6-svc -a' invocation in `rc.halt' needs to be moved accordingly.
Moreover, `.s6-svscan/finish' (linked to `rc.halt') will still need its
$1 set to `reboot', `halt' or `poweroff' by `s6-svscan' on exec().

-- 
My current OpenPGP key:
RSA4096/0x227E8CAAB7AA186C (expires: 2022.09.20)
7077 7781 B859 5166 AE07 0286 227E 8CAA B7AA 186C

Some suggestions on old-fashioned usage with s6 2.10.x

[Casper Ti. Vector]

I did not actively follow the recent evolution of s6, and have just been
bitten badly by s6 2.10.x on my Alpine servers (where slew [1] is used
of course) when it comes along with other updates.

[1] 

First, kernel panic on booting.  With some tentative echo(1) invocations
(with I/O redirections to /dev/console when necessary) and messing with
console resolution (so I could see the outputs before the panic), I
found the problem occurred with `s6-svscan' exiting because of the
legacy `-s' option in [2].  The fix itself is trivial, but it would be
better if we kept the option supported for a transition period, and that
only removed it from the manual pages while urging users to get rid of
it.  After all, in this case, silently ignoring `-s' is behaviourly
similar to (if not perfectly compatible with) old `s6-svscan'.

[2] 

Second, `s6-svscan' now waits for its `s6-supervise' children to exit
before exec()ing `.s6-svscan/finish', so it hangs forever (save for
magic SysRq) due to the catch-all logger on halting.  I do know that the
recommended way to shut down is to use `s6-linux-init-shutdown', but
it will be nice if the old-fashioned way (with stage 1 and stage 3 as
static scripts) is supported as well after minimal modifications to both
s6 and (for instance) slew.  I also understand that `s6-svc -X' has been
removed, and that the invocation in [3] would no longer work anyway
because [3] is exec()ed by `s6-svscan'.  However, I think the following
way is practical yet minimal: introduce an option (perhaps still `-X')
of `s6-svc', but that tells `s6-supervise' to exit normally *upon
receiving SIGTERM or SIGHUP* (this is where the behaviour differs from
the old `s6-svc -X') without waiting for the children to exit; then move
the `s6-svc -X' invocation from `rc.halt' into `rc.fin' (where `s6-rc -d
change all' is also spawn).

[3] 

Any suggestions?

-- 
My current OpenPGP key:
RSA4096/0x227E8CAAB7AA186C (expires: 2022.09.20)
7077 7781 B859 5166 AE07 0286 227E 8CAA B7AA 186C