Re: s6-linux-init: SIGUSR1 and SIGUSR2

2016-08-22 7:15 GMT-03:00 Laurent Bercot: > > The next s6+friends version release will have major version bumps all > around, so compatibility is moot anyway. If you really think it's worth it > to swap SIGUSR1 and SIGUSR2, I'll do it. It would be more aesthetically pleasing if s6-halt sent

Re: On the feasibility of a shell that includes execline features

This is a valid and important point; but I do think the arguments in the `dieshdiedie' (well the name...) page are, though incisive wrt sh(1), mostly unfair to the shell language. I understand your pursuit of simplicity in the implementation, and agree that the overhead is unavoidable; but let's

Re: On the feasibility of a shell that includes execline features

On 21/08/2016 17:00, Casper Ti. Vector wrote: In [1], I (probably after many other people with similar ideas) came up with the idea of a "language that somehow combines execline-like chainloading and shell-like sequential execution". I understand how the idea is tempting; and if someone wants

Re: Runit debian package fix for Ubuntu 16.04

On Mon, 22 Aug 2016 13:44:45 + Gerrit Pape wrote: > For some reason, interest in the runit project raised again over the > last months, although I didn't do any work on it, In a word, systemd. Expanding, runit makes life easy, predictable, and simple. Thank you for that.

Re: s6-linux-init: SIGUSR1 and SIGUSR2

Colin Booth wrote: >Lower case -s causes s6-svscan to execute a script on receipt of: >TERM, INT, HUP, QUIT, USR1, USR2. As currently I am killing most time messing with my ugly s6 jails, it's some time I messed with PID1. As we know, quite few of the rc scripts would need to

Re: s6-linux-init: SIGUSR1 and SIGUSR2

On Mon, Aug 22, 2016 at 7:29 AM, Martin "eto" Misuth wrote: > On Mon, 22 Aug 2016 07:26:12 -0700 > > Colin Booth wrote: >> My own $0.02 is that s6-svscan -S should ignore power state signals >> (including SIGINT which it currently doesn't ignore). > > I

Re: s6-linux-init: SIGUSR1 and SIGUSR2

On 22/08/16 16:29, Martin "eto" Misuth wrote: On Mon, 22 Aug 2016 07:26:12 -0700 Colin Booth wrote: My own $0.02 is that s6-svscan -S should ignore power state signals (including SIGINT which it currently doesn't ignore). I haven't really understood this thread, but I

Re: s6-linux-init: SIGUSR1 and SIGUSR2

On Mon, 22 Aug 2016 07:26:12 -0700 Colin Booth wrote: > My own $0.02 is that s6-svscan -S should ignore power state signals > (including SIGINT which it currently doesn't ignore). I haven't really understood this thread, but I think I am starting to understand. Correct me,

Re: s6-linux-init: SIGUSR1 and SIGUSR2

On Mon, Aug 22, 2016 at 6:35 AM, Laurent Bercot wrote: > On 22/08/2016 14:02, Casper Ti. Vector wrote: >> >> Are SIGUSR1 and SIGUSR2 not just silently ignored in -S mode? > > > Uuuuh, yes, my bad, they are. > Sigh. I'm not sure what the right thing even is. Should

Re: listen(1): proposed addition to the runit suite

On Wed, Aug 10, 2016 at 11:58:55AM -0400, Daniel Kahn Gillmor wrote: > Hi Gerrit and other runit folks-- > > I'm working on a new tool that i think would fit well with runit, and i > was wondering if there is any interest in it as a contribution to the > runit suite. Hi Daniel, I'm sure many

Re: Runit debian package fix for Ubuntu 16.04

On Mon, Jul 25, 2016 at 09:02:22AM +0100, Jonathan de Boyne Pollard wrote: > Pierre Jacomet: > > >I did a couple of fixes to the debian package installer such that > >the debian/ubuntu installer deals properly with the dichotomy > >between systemd and upstart and the fact that they both may be >

Re: s6-linux-init: SIGUSR1 and SIGUSR2

On 22/08/2016 14:02, Casper Ti. Vector wrote: Are SIGUSR1 and SIGUSR2 not just silently ignored in -S mode? Uuuuh, yes, my bad, they are. Sigh. I'm not sure what the right thing even is. Should they be ignored in -S mode? Should they do something? ISTR I kept them ignored *precisely* to

Re: s6-linux-init: SIGUSR1 and SIGUSR2

Are SIGUSR1 and SIGUSR2 not just silently ignored in -S mode? On Mon, Aug 22, 2016 at 12:15:59PM +0200, Laurent Bercot wrote: > If you really think it's worth it to swap SIGUSR1 and SIGUSR2, I'll do > it. (I'd change the non-diverted meanings in s6-svscan, so that they > remain in sync with the

Re: s6-linux-init: SIGUSR1 and SIGUSR2

On 21/08/2016 23:17, Guillermo wrote: Yeah, it seems it has come to that :) But the funny thing is a few of the init systems for [GNU/]Linux are, or can be made to be, *almost* (to different degrees) compatible with this signal set: a) SIGTERM for reboot b) SIGUSR1 for halt c) SIGUSR2 for

Re: s6-linux-init: SIGUSR1 and SIGUSR2

Guillermo: > a) SIGTERM for reboot > b) SIGUSR1 for halt > c) SIGUSR2 for poweroff > d) SIGINT for a programmable CTRL + ALT + Del action > e) SIGWINCH for a programmable 'keyboard request' action > > nosh's system-manager supports e) via the 'kbrequest' target. But for > compatibility reasons,