Re: runit SIGPWR support

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

Re: runit SIGPWR support

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

Re: runit SIGPWR support

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

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

Re: runit SIGPWR support

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

Re: runit SIGPWR support

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

Re: runit SIGPWR support

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

Re: runit SIGPWR support

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

Re: runit SIGPWR support

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

Re: runit SIGPWR support

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

Re: runit SIGPWR support

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.

Re: runit SIGPWR support

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,

Re: runit SIGPWR support

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

Re: runit SIGPWR support

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

Re: runit SIGPWR support

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.

Re: runit SIGPWR support

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

Re: runit SIGPWR support

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