Re: runit SIGPWR support

[Laurent Bercot]

I don't generally question people that are this far above my weight class
on a topic - but I'm pretty sure this [1] implies that pid 1 is not a
requirement.


Of course, you can run runsvdir directly under a different init. But
that requires a bit of work: you now need to find another way to run
your stage 1, and also your stage 3 when shutting down the container.
Stages 1 and 3 are an integral part of using runit as an init system
instead of just a supervision mechanism (which the runsvdir invocation
in stage 2 is), so if you can't run them because you can't run the
runit binary because it's not pid 1, you need to work around that. And
it's not entirely trivial; to accomplish something similar in s6, I had
to write a whole specific package, s6-linux-init.

innerspacepilot wants to use runit with the least possible amount of
effort, so rewriting a significant portion of the init sequence doesn't
sound like a good match. ;)



I'm also confused why my suggestion would be put down so harshly outside of
the possible pid 1 issue.


Sorry if I appeared hostile, that was not my intention; I tend to be
blunt and terse when something seems obvious to me. I just wanted to
stress that any alternative solution to changing the lxc config will
be more costly, one way or another.

--
Laurent

Re: runit SIGPWR support

[John W Higgins]

Good Day,

On Fri, Feb 14, 2020 at 3:18 PM Laurent Bercot 
wrote:

> >That's a win-win
>
>   Lengthening the supervision tree in the container and using more RAM
> just to save writing one line in a configuration file does not seem
> like a win to me.
>
>   ... Besides, runit will refuse to run if it's not pid 1, so that
> wouldn't work.
>
>
I don't generally question people that are this far above my weight class
on a topic - but I'm pretty sure this [1] implies that pid 1 is not a
requirement.

I'm also confused why my suggestion would be put down so harshly outside of
the possible pid 1 issue.

If one doesn't want to require a user of their lxc image to modify the
config - but wants to use runit - what I suggested certainly would fit that
core requirement. I made no suggestion that it was perfect - but it was an
option for someone that views the reality of changing a line in a config
file differently than I would.

I have a boat load of issues with things that I work with that consume way
more time than should be necessary. I also happened to remember having seen
an init that allowed signal remapping in the past.

This smallest amount of empathy for a fellow bike shed painter meant that I
offered up what I remembered.

My apologies for the noise.

John W Higgins

[1] - http://smarden.org/runit/useinit.html

Re: runit SIGPWR support

[Laurent Bercot]

That's a win-win


 Lengthening the supervision tree in the container and using more RAM
just to save writing one line in a configuration file does not seem
like a win to me.

 ... Besides, runit will refuse to run if it's not pid 1, so that
wouldn't work.

--
 Laurent

Re: runit SIGPWR support

[John W Higgins]

Good Day,

On Wed, Feb 12, 2020 at 6:26 AM innerspacepilot 
wrote:

>
> Why not just make runit systems run inside containers out of the box?
> We are talking about one/two lines of code.
>
>
The much better option here (in terms of playing well with others) would be
this

https://github.com/Yelp/dumb-init

A very small pid 1 that sits just on top of your now pid 2 runit and will
rewrite signals for you [1] so that SIGPWR magically becomes SIGTERM for
runit. No modification to either side.

That's a win-win

John W Higgins

[1] - https://github.com/Yelp/dumb-init#signal-rewriting

Re: runit SIGPWR support

[Laurent Bercot]

You mean that adding few lines of code in one place is worse than many
users of many distros must configure their containers?
I can configure that myself, but I don't want every user of runit driven
container to walk this path. Is it necessary?


As counterintuitive as it may seem at first glance, the answers to your
questions are yes and yes. Patching software is always more complex than
configuring it.

Configuring software is using an API that has been especially thought
out to accommodate the needs of various users; if a piece of software
does what you want but requires you to tweak a configuration lever,
then it does what you want period. Because your needing to tweak the
configuration lever is *the exact reason why that lever is there*.
If you refuse to use it, you are basically putting your needs in
front of everyone else's, and demanding that the author of the software
adapt to you at the exclusion of others, instead of using the mechanism
that has been prepared for you.

Patching software:
- requires communication with upstream, so, takes support resources
- requires new deployment, which is significant effort
- is dangerous: it may introduce bugs that you haven't thought of
- may change the workflow of other users

It is, of course, a supplementary order of magnitude more difficult with
software that has no well-defined upstream, as is the case with runit
these days.
But even if your containers were using s6, which has a well-defined
upstream (me) and which does not understand SIGPWR either, I would not
apply your patch suggestion. Why? Because SIGPWR is not standardized,
and s6 aims to be portable, it works ootb on other systems than Linux
and making it use SIGPWR would endanger that. It's the exact kind of
problems you haven't thought of but run into when you want to patch
software, and makes patching always more complex than it seems from the
outside.

Explaining to users how to configure lxc to send the correct signal
to the init system running in the container is a matter of one line in
the documentation. It's extremely manageable.



Also there is a huge lack of documentation about it on the net,
especially on signals that runit accepts.


You are talking about patching the code, and you're not going to
look at runit's code to see what signals it accepts? ;)



It adds complexity to users, and that means users will choose other
distros which just work.


If your definition of "just working" is "everything is working with
the default configuration", then I don't think you'll find a single
Linux distribution that "just works".

Your runit distro is working just as well as any other. You just
need to set one variable in the lxc configuration. It's certainly not
the only variable you need to set; it's certainly not even the only
variable you need to set conditionally depending on the guest distro.
So, there's really no reason to get hung up on this.



Why can't we be just a little bit more friendly to each other?


 Most participants in this thread would benefit from taking this advice
to heart. And in your case, the friendliness will consist in using
the configuration levers that were made for you instead of demanding
that upstream change its defaults to adapt to you.

--
 Laurent

Re: runit SIGPWR support

[Casper Ti. Vector]

On Fri, Feb 14, 2020 at 05:06:40PM +0300, innerspacepilot wrote:
> If you read it carefully, there is NO signal for shutdown.
> Or lxd should also create file /etc/runit/stopit and set permissions for
> that?

Here runit provided a small machanism, and you also need a policy, like
those from Void or Gentoo.  Someone can provide a container template
with a given policy, and then the user does not need to care about
creating it by himself.  The same goes for many other init systems.

> Also what complexity you are talking about? runit.c is only 346 lines long.

Note the word "coupling" I used:
.

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

Re: runit SIGPWR support

[innerspacepilot]

Documentation says:
"
Signals
runit only accepts signals in stage 2.

If runit receives a CONT signal and the file /etc/runit/stopit exists
and has the execute by owner permission set, runit is told to shutdown
the system.

if runit receives an INT signal, a ctrl-alt-del keyboard request is
triggered.

"

If you read it carefully, there is NO signal for shutdown.
Or lxd should also create file /etc/runit/stopit and set permissions for
that?

Also what complexity you are talking about? runit.c is only 346 lines long.



On 14.02.2020 16:57, Casper Ti. Vector wrote:

On Fri, Feb 14, 2020 at 04:39:28PM +0300, innerspacepilot wrote:

You mean that adding few lines of code in one place is worse than many
users of many distros must configure their containers?
I can configure that myself, but I don't want every user of runit driven
container to walk this path. Is it necessary?
It adds complexity to users, and that means users will choose other
distros which just work.

The burden is just a few lines of code anyway, and user only need to
learn it once.  It is also easily doable with some templating mechanism.


Also there is a huge lack of documentation about it on the net,
especially on signals that runit accepts.

.
Took me less than one minute.

Re: runit SIGPWR support

[Casper Ti. Vector]

On Fri, Feb 14, 2020 at 11:46:16AM +0100, Jeff wrote:
> what should SIGPWR mean to a Linux init ?
> i would suggest: halt and power down the system ASAP.

Init signal semantics is already a mess:
.
When thinking of standardisation, we need to beware of this:
.

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

Re: runit SIGPWR support

[Casper Ti. Vector]

On Fri, Feb 14, 2020 at 04:39:28PM +0300, innerspacepilot wrote:
> You mean that adding few lines of code in one place is worse than many
> users of many distros must configure their containers?
> I can configure that myself, but I don't want every user of runit driven
> container to walk this path. Is it necessary?
> It adds complexity to users, and that means users will choose other
> distros which just work.

The burden is just a few lines of code anyway, and user only need to
learn it once.  It is also easily doable with some templating mechanism.

> Also there is a huge lack of documentation about it on the net,
> especially on signals that runit accepts.

.
Took me less than one minute.

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

Re: runit SIGPWR support

[innerspacepilot]

On 14.02.2020 16:15, Casper Ti. Vector wrote:

On Wed, Feb 12, 2020 at 05:25:56PM +0300, innerspacepilot wrote:

Why not just make runit systems run inside containers out of the box?
We are talking about one/two lines of code.

Likewise `lxc.signal.halt' only needs one/two lines of code.  It is also
a interface with well-defined semantics.  Modifying runit source code
touches the implementation, with all the potential coupling between
modules and/or between submodules.  So the increase in total complexity
of the system is almost certainly smaller when using `lxc.signal.halt'.


You mean that adding few lines of code in one place is worse than many
users of many distros must configure their containers?
I can configure that myself, but I don't want every user of runit driven
container to walk this path. Is it necessary?
Also there is a huge lack of documentation about it on the net,
especially on signals that runit accepts.

It adds complexity to users, and that means users will choose other
distros which just work.





Why can't we be just a little bit more friendly to each other?

Let's see some more examples.  Some daemons (eg. mysqld and php-fpm)
use a signal other than SIGTERM for graceful shutdown, and s6 uses a
`down-signal' file (similar to `lxc.signal.halt') for these daemons.
Instead of modifying the daemons, we configure s6 specially; likewise,
here I would definitely prefer `lxc.signal.halt'.

Re: runit SIGPWR support

[Casper Ti. Vector]

On Wed, Feb 12, 2020 at 05:25:56PM +0300, innerspacepilot wrote:
> Why not just make runit systems run inside containers out of the box?
> We are talking about one/two lines of code.

Likewise `lxc.signal.halt' only needs one/two lines of code.  It is also
a interface with well-defined semantics.  Modifying runit source code
touches the implementation, with all the potential coupling between
modules and/or between submodules.  So the increase in total complexity
of the system is almost certainly smaller when using `lxc.signal.halt'.

> Why can't we be just a little bit more friendly to each other?

Let's see some more examples.  Some daemons (eg. mysqld and php-fpm)
use a signal other than SIGTERM for graceful shutdown, and s6 uses a
`down-signal' file (similar to `lxc.signal.halt') for these daemons.
Instead of modifying the daemons, we configure s6 specially; likewise,
here I would definitely prefer `lxc.signal.halt'.

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

Re: runit SIGPWR support

[Steve Litt]

In my computer usage, I usually need about 5 minutes to gracefully exit
all my programs before powering down the computer, and I have a 40
minute UPS. If this is done at all, I'd suggest a configurable amount
of time, with a visible countdown, telling the user to get his or her
affairs in order, and also a way to cancel the shutdown.

The only reason I see to have the computer automatically power down
when signaled by the UPS is that I might not be home, but in that case
waiting 5 minutes wouldn't matter.

By the way, how would this be handled on a laptop, whose core usage
includes unplugged usage? Maybe by monitoring when the battery gets too
low?

SteveT

Steve Litt 
February 2020 featured book: Thriving in Tough Times
http://www.troubleshooters.com/thrive


On Fri, 14 Feb 2020 15:29:49 +0300
innerspacepilot  wrote:

> I would suggest it should be a graceful shutdown ( stopping all
> daemons, syncing filesystems and stuff )
> 
> 
> On 14.02.2020 13:46, Jeff wrote:
> > 12.02.2020, 22:54, "Colin Booth" :  
> >> I wasn't trying to be hostile, apologies if it came across that
> >> way. As far as I know SIGPWR is a Linux-specific signal so
> >> services that are aiming for portability will either need to have
> >> special handling for that in the linux case or need to ignore it.
> >> Ergo, runit (and all other POSIX-compliant inits) currently have
> >> no special handling around SIGPWR as they don't understand what it
> >> is.  
> > what should SIGPWR mean to a Linux init ?
> > i would suggest: halt and power down the system ASAP.
> >  
> 

Re: runit SIGPWR support

[Steve Litt]

On Fri, 14 Feb 2020 10:38:38 +0100
Jeff  wrote:

> 12.02.2020, 22:54, "Colin Booth" :
> > On Wed, Feb 12, 2020 at 05:25:56PM +0300, innerspacepilot wrote:  
> >>  Why not just make runit systems run inside containers out of the
> >> box? We are talking about one/two lines of code.  
> 
> you should patch the code, runit is dead anyway.

Oh really. No chance that Gerrit has simply taken a year or two off?
Why are you using software you consider dead? Why not move to s6 if
runit is dead?

> try something along this lines in the source:
> 
> #ifdef SIGPWR
>   /* handle that one */
>   ...
> #endif

If it's that simple, why don't YOU do it? Someone already mentioned
that BSD doesn't have this signal, so incorporating it in the wider
project could be objected to by some people as non-portable. So why
don't YOU make this change on YOUR copy?

> 
> i can't see the problem, you have to patch the runit sources to
> fulfil your requirements since that project is dead and the code
> is not maintained anymore.
> 
> >>  Why can't we be just a little bit more friendly to each other?  
> 
> that would be indeed helpful.

And you can start by not calling a project "dead".

> 
> > I wasn't trying to be hostile, apologies if it came across that
> > way. As far as I know SIGPWR is a Linux-specific signal so services
> > that are aiming for portability will either need to have special
> > handling for that in the linux case or need to ignore it. Ergo,
> > runit (and all other POSIX-compliant inits) currently have no
> > special handling around SIGPWR as they don't understand what it is.
> >
> > Is this the right behavior? I don't know. Something like SIGPWR as
> > an alerting mechanism when you're switched to UPS battery is pretty
> > nice in a general case but using that as your container shutdown
> > solution isolates you into a very SysV-specific world. Overriding
> > the default via lxc.signal.halt will allow you to modify what you
> > send to something that is within the POSIX spec and allow you to
> > trigger shutdowns the "right" way. It's a little lame but it is
> > portable, and LXC using a non-portable signal is a little bit of a
> > bummer.  
> 
> just BS. adding a bit of handler code for SIGPWR is no big deal,
> please stop your lamento, it's so boring.

I guess your resolution to be a little bit more friendly to each other
didn't last too long.

You're one guy who wants this change. You have many alternatives:

* s6
* lxc.signal.halt
* Patch runit yourself

Everyone else: Just to express my opinion: I use runit every day and
personally have no need to have it react to SIGPWR.

SteveT

Steve Litt 
February 2020 featured book: Thriving in Tough Times
http://www.troubleshooters.com/thrive

Re: runit SIGPWR support

[innerspacepilot]

I would suggest it should be a graceful shutdown ( stopping all daemons,
syncing filesystems and stuff )


On 14.02.2020 13:46, Jeff wrote:

12.02.2020, 22:54, "Colin Booth" :

I wasn't trying to be hostile, apologies if it came across that way. As
far as I know SIGPWR is a Linux-specific signal so services that are
aiming for portability will either need to have special handling for
that in the linux case or need to ignore it. Ergo, runit (and all other
POSIX-compliant inits) currently have no special handling around SIGPWR
as they don't understand what it is.

what should SIGPWR mean to a Linux init ?
i would suggest: halt and power down the system ASAP.

Re: runit SIGPWR support

[Jeff]

12.02.2020, 22:54, "Colin Booth" :
> I wasn't trying to be hostile, apologies if it came across that way. As
> far as I know SIGPWR is a Linux-specific signal so services that are
> aiming for portability will either need to have special handling for
> that in the linux case or need to ignore it. Ergo, runit (and all other
> POSIX-compliant inits) currently have no special handling around SIGPWR
> as they don't understand what it is.

what should SIGPWR mean to a Linux init ?
i would suggest: halt and power down the system ASAP.

Re: runit SIGPWR support

[Jeff]

12.02.2020, 22:54, "Colin Booth" :
> I wasn't trying to be hostile, apologies if it came across that way. As
> far as I know SIGPWR is a Linux-specific signal so services that are

this is a SysV signal that is sent in case of power suply problems.
it has no special meaning per se and can be (ab)used for everything
the coder sees fit.

is the abuse of SIGTSP in BSD init "POSIX-compliant" or even necessary ?
certainly not.

> aiming for portability will either need to have special handling for
> that in the linux case or need to ignore it. Ergo, runit (and all other
> POSIX-compliant inits) currently have no special handling around SIGPWR
> as they don't understand what it is.

what is a "POSIX-compliant init" btw ?

> Is this the right behavior? I don't know.

yes. what should power suply problems mean to container ?

> Something like SIGPWR as an
> alerting mechanism when you're switched to UPS battery is pretty nice in
> a general case but using that as your container shutdown solution
> isolates you into a very SysV-specific world.

BS. Linux provides this signal so you can (ab)use it for anything
you wish.

> Overriding the default via
> lxc.signal.halt will allow you to modify what you send to something that
> is within the POSIX spec and allow you to trigger shutdowns the "right"
> way. It's a little lame but it is portable, and LXC using a non-portable
> signal is a little bit of a bummer.

why "fix" LXC when adding handler code for SIGPWR to runit is not
much of a deal:

#ifdef SIGPWR
  /* handle it analogous to SIGTERM or else */
#endif

this is also very portable to systems that do not provide SIGPWR.

not in any way, the signal is portable between Linux and SysV unices.
it is a good idea to use it since it is rarely used for anything, another
solution could be usage of real time signals.

Re: runit SIGPWR support

[Jeff]

12.02.2020, 22:54, "Colin Booth" :
> On Wed, Feb 12, 2020 at 05:25:56PM +0300, innerspacepilot wrote:
>>  Why not just make runit systems run inside containers out of the box?
>>  We are talking about one/two lines of code.

you should patch the code, runit is dead anyway.
try something along this lines in the source:

#ifdef SIGPWR
  /* handle that one */
  ...
#endif

i can't see the problem, you have to patch the runit sources to
fulfil your requirements since that project is dead and the code
is not maintained anymore.

>>  Why can't we be just a little bit more friendly to each other?

that would be indeed helpful.

> I wasn't trying to be hostile, apologies if it came across that way. As
> far as I know SIGPWR is a Linux-specific signal so services that are
> aiming for portability will either need to have special handling for
> that in the linux case or need to ignore it. Ergo, runit (and all other
> POSIX-compliant inits) currently have no special handling around SIGPWR
> as they don't understand what it is.
>
> Is this the right behavior? I don't know. Something like SIGPWR as an
> alerting mechanism when you're switched to UPS battery is pretty nice in
> a general case but using that as your container shutdown solution
> isolates you into a very SysV-specific world. Overriding the default via
> lxc.signal.halt will allow you to modify what you send to something that
> is within the POSIX spec and allow you to trigger shutdowns the "right"
> way. It's a little lame but it is portable, and LXC using a non-portable
> signal is a little bit of a bummer.

just BS. adding a bit of handler code for SIGPWR is no big deal,
please stop your lamento, it's so boring.