Process Supervision Rosetta Stone
Hi all, I just today started a Process Supervision Rosetta Stone, which shows names of similarly functioned things in daemontools, runit and s6. It's obviously incomplete and probably contains errors, but it's a start. SteveT Steve Litt November 2019 featured book: Manager's Guide to Technical Troubleshooting Second edition http://www.troubleshooters.com/mgr
Re: runit patches to fix compiler warnings on RHEL 7
On Sat, 30 Nov 2019 00:21:59 + Colin Booth wrote: > runit-init is slowly becoming less functional and it wouldn't surprise > me if it fails entirely after Debian 10. By what mechanism is runit-init slowly becoming less functional, and what changes in Debian might cause it to fail entirely? Thanks, SteveT Steve Litt November 2019 featured book: Manager's Guide to Technical Troubleshooting Second edition http://www.troubleshooters.com/mgr
Re: runit patches to fix compiler warnings on RHEL 7
On Sat, Nov 30, 2019 at 08:46:28AM +1100, Dewayne Geraghty wrote: > Jan, > > I'm also a virgin to process/service management software, learning s6-rc, > s6, execlineb is not for the faint-hearted nor the time-poor. Getting a > handle on the concepts, and the naming conventions - its really hard work. If you want to ease yourself into process supervision I suggest starting just with s6 and a smattering of execline when you are trying to describe things that are really annoying to express in shell. Usually you only need to do this when your run scripts are turning into a mess of line continuations because of the chain load utilities but there are other reasons to do it as well. s6-rc is absolutely not necessary for basic service management. It's a very nice helper utility when you're mixing non-idempotent oneshots with long-running services or handling deep dependency tries that are fairly touchy (like system bootstrap stuff), but if you don't need deep levels of dependency ordering and any initial environmental setup for a service can be handled in an idempotent way, s6-rc is intense overkill. If you need to synchronize between two services, you can hard-code startup and shutdown dependencies with s6-svwait and/or s6-svc calls reaching into the other service directory. It's a pretty low-rent but it's very easy to think about and manage. > > Execline enforces a discipline, a rigor demanding anticipatory planning (to > get right). I ran some performance tests and execlineb is marginally > better. So why persist? Largely because an execline script is immediately > obvious and explicit. Seriously, at a glance you know what the script will > achieve. Could I write a sh script to do the same task? Yes, and probably > do it a lot quicker. But. I would loose the elegance and readability - > where sh has an equivalence with assembler, execline is akin to BASIC, it > makes you think differently :) I personally like execline for run scripts because there's very little magic and it takes a lot of work to fail to get the service that you want supervised correctly parented at the end of the day. Also, since it execs into each program you end up not having to do shenanigans like execing into nested shells if you need to modify state after dropping privileges (like you do with chpst). > > I'm developing solutions for PROTECTED level security (its an Australian > Govt thing), and skarnet's service management provides assurance, and s6-log > provides near-certainty of logging completeness. I'm very happy with the > toolset, worth the time investment. -- Colin Booth
Re: runit patches to fix compiler warnings on RHEL 7
On Fri, Nov 29, 2019 at 03:09:01PM +0100, Jan Braun wrote: > Hi, > > Laurent Bercot schrob: > > - My opinion is that the most sustainable path forward, for runit > > users who need a centrally maintained supervision software suite, is to > > just switch to s6 - and it comes with several other benefits as well. > > As a relatively new convert to supervision software, my reasons for > preferring runit over s6 are, in order of priority: > > 1) Debian ships with a working and maintained runit-init package. It >provides pid 1 and hooks into /etc/rcS.d/* to integrate with other >Debian packages. s6-linux-init and s6-rc are not packaged in Debian. runit-init is slowly becoming less functional and it wouldn't surprise me if it fails entirely after Debian 10. As for s6-rc and s6-l-i, you don't need either of those to emulate runit-init and if you do want them you should talk to the current maintainer of s6 and execline about adding them. The rcS.d hooks can be covered with a shim program, though the LSB compatibility layer in runit is pretty poor to start with and I tend to suggest people avoid it if they can help it. > > 2) runit has manpages. s6 has HTML. :( Yeah, this sucks. I know Laurent isn't going to do it but I've been meaning to take some time off and dedicate it to rewriting all of the documentation into something that an compile into both mandoc and html. > > 3) s6 executables are somehow worse named than runit's. This may be >highly subjective, but I can recall and recognize the runit commands >far easier than the s6 ones. Possibly it's the "s6-" prefix getting >in the way of my brain pattern matching on visual appearance of glyph >sequences. >This point is exacerbated by #2 and the number of s6 executables. >Compare chpst with s6-envdir s6-envuidgid s6-fghack s6-setsid >s6-setuidgid s6-applyuidgid s6-softlimit. Yes, I know about the >historical reasons, but sti chpst is a monster of a program and at least with runscripts written in execline it's generally easier to understand 3-4 process state manipulators than a pile of chpst options. > > 4) s6 seems more complex (hello execline!), and I don't (yet?) see any >benefit/feature I'd appreciate except minimizing wakeups. s6 is more complex in terms of total bits than runit, but that complexity brings objective benefits like having the supervision system itself know when supervised services are ready and being able to query the supervisor for that status. If you're talking about comparisons with the supervisory portions of runit, besides the differences with chpst mentioned earlier the two are pretty comparible. As for the execline dependency, the only place where it's really required is if you use s6-log processing directives though it's a pretty nice language for writing run scripts in. > > OTOH, an active and responsive upstream is obviously a big plus for s6. > > > - But again, I'm not impartial, and alternatives are a good thing. > > So no matter what individual decisions are made, it would definitely be > > a net positive if the exact state and workflow of runit could be > > clarified, and if a real development/maintenance structure was in place. > > Agreed. > > Brainstorming possible ways forward: > > A) Gerrit Pape becomes more active in maintianing runit, at least >acknowledging patches posted here. > B) Somebody else steps in as (co-)maintainer. > C) We get a dumping ground (wiki or somesuch) for patches to allow >- contributors to publish their patches (after discussing them here) >- users to easily find and download patches they'd be interested in >- Gerrit Pape to review and apply patches at his leisure when he > feels like making a new release. > D) The maintainers of distros shipping runit work out a patch-sharing >scheme among them. > > > Just my 0.02€, I hope it helps. > > cheers, > Jan -- Colin Booth
Re: runit patches to fix compiler warnings on RHEL 7
Jan, I'm also a virgin to process/service management software, learning s6-rc, s6, execlineb is not for the faint-hearted nor the time-poor. Getting a handle on the concepts, and the naming conventions - its really hard work. Execline enforces a discipline, a rigor demanding anticipatory planning (to get right). I ran some performance tests and execlineb is marginally better. So why persist? Largely because an execline script is immediately obvious and explicit. Seriously, at a glance you know what the script will achieve. Could I write a sh script to do the same task? Yes, and probably do it a lot quicker. But. I would loose the elegance and readability - where sh has an equivalence with assembler, execline is akin to BASIC, it makes you think differently :) I'm developing solutions for PROTECTED level security (its an Australian Govt thing), and skarnet's service management provides assurance, and s6-log provides near-certainty of logging completeness. I'm very happy with the toolset, worth the time investment.
Re: runit patches to fix compiler warnings on RHEL 7
Hi, Laurent Bercot schrob: > - My opinion is that the most sustainable path forward, for runit > users who need a centrally maintained supervision software suite, is to > just switch to s6 - and it comes with several other benefits as well. As a relatively new convert to supervision software, my reasons for preferring runit over s6 are, in order of priority: 1) Debian ships with a working and maintained runit-init package. It provides pid 1 and hooks into /etc/rcS.d/* to integrate with other Debian packages. s6-linux-init and s6-rc are not packaged in Debian. 2) runit has manpages. s6 has HTML. :( 3) s6 executables are somehow worse named than runit's. This may be highly subjective, but I can recall and recognize the runit commands far easier than the s6 ones. Possibly it's the "s6-" prefix getting in the way of my brain pattern matching on visual appearance of glyph sequences. This point is exacerbated by #2 and the number of s6 executables. Compare chpst with s6-envdir s6-envuidgid s6-fghack s6-setsid s6-setuidgid s6-applyuidgid s6-softlimit. Yes, I know about the historical reasons, but still. 4) s6 seems more complex (hello execline!), and I don't (yet?) see any benefit/feature I'd appreciate except minimizing wakeups. OTOH, an active and responsive upstream is obviously a big plus for s6. > - But again, I'm not impartial, and alternatives are a good thing. > So no matter what individual decisions are made, it would definitely be > a net positive if the exact state and workflow of runit could be > clarified, and if a real development/maintenance structure was in place. Agreed. Brainstorming possible ways forward: A) Gerrit Pape becomes more active in maintianing runit, at least acknowledging patches posted here. B) Somebody else steps in as (co-)maintainer. C) We get a dumping ground (wiki or somesuch) for patches to allow - contributors to publish their patches (after discussing them here) - users to easily find and download patches they'd be interested in - Gerrit Pape to review and apply patches at his leisure when he feels like making a new release. D) The maintainers of distros shipping runit work out a patch-sharing scheme among them. Just my 0.02€, I hope it helps. cheers, Jan signature.asc Description: PGP signature
