Re: Can you use s6-rc with the sysvinit PID1?
On Fri, Oct 23, 2020 at 12:48:47PM -0400, Steve Litt wrote:
> Hi all,
>
> If I use sysvinit's PID1, is it possible for me to use s6-rc by
> declaring an s6-rc program in /etc/inittab?
>
> Also, and this is offtopic, is there a way to tell sysvinit not to run
> the programs in /etc/rc.d/rc3.d or whatever? This would make it trivial
> to switch between an sysvinit initted system and an s6-rc/s6 supervised
> system just by commenting in or out the inittab entry and switching
> sysvinit to looop /etc/rc.d/rc3.d?
>
> Thanks,
>
> SteveT
>
Yes. In your /etc/inittab call a script that backgrounds the rc call
hanging on some event. Here's an execline fragment that'll do what you
want, though it could obviously be made a lot better by taking advantage
of the native readyness notification that s6-svscan provides instead of
sleeping for a second.
background {
foreground { sleep 1 }
foreground { s6-rc-init /path/to/scandir }
s6-rc change up
}
s6-svscan /path/to/scandir
Jam that into the startup script that you use for booting your
supervision tree and you'll be good to go.
--
Colin Booth
Re: Can you use s6-rc with the sysvinit PID1?
If I use sysvinit's PID1, is it possible for me to use s6-rc by declaring an s6-rc program in /etc/inittab? Yes. You have to tell /etc/inittab to launch a s6 supervision tree first, then s6-rc-init, then s6-rc -u change top (if "top" is the bundle containing all the services you need), as one-time services. There is an example with OpenRC in Adélie: a sysvinit init, that controls a s6 supervision tree then runs an openrc service manager. https://code.foxkit.us/adelie/packages/-/blob/master/system/sysvinit/inittab-2.88 (The s6-svscanboot code is in the same directory in the repository.) If you remove the 'openrc sysinit' and 'openrc boot' lines, and change the 'openrc $runlevel' lines below to 's6-rc change $runlevel' invocations, then you will have a s6-rc managed system running on top of sysvinit. However, it's much more work to convert a set of init scripts to s6-rc than it is to switch from sysvinit to s6-linux-init, so you may just as well switch to s6-linux-init first and spare yourself some unnecessary work and some ugly init code. ;) Also, and this is offtopic, is there a way to tell sysvinit not to run the programs in /etc/rc.d/rc3.d or whatever? This would make it trivial to switch between an sysvinit initted system and an s6-rc/s6 supervised system just by commenting in or out the inittab entry and switching sysvinit to looop /etc/rc.d/rc3.d? You can just comment out the lines you don't want in /etc/inittab. However, controlling init via a file is awkward and fragile, and you may find yourself performing a lot of scripting (and making your system unbootable and having to recover via init=/bin/sh once or twice), which is another reason why s6-svscan makes a better pid 1. -- Laurent
Re: External health Check Process
On Fri, 23 Oct 2020 13:44:55 + "Laurent Bercot" wrote: > >I just miss the elegance of the solution: I personally want to model > >one service with one s6 service. For me it would mean thinking about > >a wrapper around s6 to get that. Maybe I get now the slew thing. > > The thing is, s6 is a *process supervision* suite, so one s6 > "service" is really one long-running process. When you want health > checks, you have two long-running processes: your daemon, and your > health checker. So two s6 "services" is really the most elegant, most > idiomatic and most natural solution. > > What you could have, on the other hand, is a s6-rc bundle, that > contains > both your daemon and your health checker: so you would be able to > handle both the daemon and the health checker (2 longruns) with a > single s6-rc/svctl command, using the name of the bundle. > > It's probably something that I can add to the next version of s6-rc: > a command or an option to automatically add a health checker service > to a longrun that is declared in the database, so you wouldn't have to > write the health checker longrun manually. How does that sound? I'd poll s6 users, and if less than 1/2 eagerly want this new feature, I'd leave well enough alone. SteveT Steve Litt Autumn 2020 featured book: Thriving in Tough Times http://www.troubleshooters.com/thrive
Can you use s6-rc with the sysvinit PID1?
Hi all, If I use sysvinit's PID1, is it possible for me to use s6-rc by declaring an s6-rc program in /etc/inittab? Also, and this is offtopic, is there a way to tell sysvinit not to run the programs in /etc/rc.d/rc3.d or whatever? This would make it trivial to switch between an sysvinit initted system and an s6-rc/s6 supervised system just by commenting in or out the inittab entry and switching sysvinit to looop /etc/rc.d/rc3.d? Thanks, SteveT Steve Litt Autumn 2020 featured book: Thriving in Tough Times http://www.troubleshooters.com/thrive
Re: External health Check Process
I just miss the elegance of the solution: I personally want to model one service with one s6 service. For me it would mean thinking about a wrapper around s6 to get that. Maybe I get now the slew thing. The thing is, s6 is a *process supervision* suite, so one s6 "service" is really one long-running process. When you want health checks, you have two long-running processes: your daemon, and your health checker. So two s6 "services" is really the most elegant, most idiomatic and most natural solution. What you could have, on the other hand, is a s6-rc bundle, that contains both your daemon and your health checker: so you would be able to handle both the daemon and the health checker (2 longruns) with a single s6-rc/svctl command, using the name of the bundle. It's probably something that I can add to the next version of s6-rc: a command or an option to automatically add a health checker service to a longrun that is declared in the database, so you wouldn't have to write the health checker longrun manually. How does that sound? And it's ok to need a wrapper to get useability, but the advertisement of that should be better on the website that you SHOULD use that wrapper (and for me this wrapper should be part of the s6 project). This is indeed a UI problem and I'm still working on it. ;) -- Laurent
Re: External health Check Process
On Fri, 23 Oct 2020 09:27:53 +0200 Oliver Schad wrote: > On Thu, 22 Oct 2020 20:03:17 -0400 > Steve Litt wrote: > > > But most of the other suggestions that in my opinion are just > > answers to systemd weenie's "but s6 doesn't have _" arguments, > > and don't add nearly enough functionality or convenience for the > > complexity, or just plain size added to the user manual, to justify. > > > > The OP already stated there's a way to do it currently. Why > > complexify s6 to do something already doable? > > I just miss the elegance of the solution: I get that. But there's a pretty significant cost. Every new feature added to a piece of software makes it harder to understand, creates new nooks and crannies for bugs to hide out in, and increases the number of interactions very significantly. To see interactions at their worst, see my systemd cartoon: http://troubleshooters.com/linux/systemd/lol_systemd.htm I'm not saying s6 is anywhere near that yet. But in my opinion, every feature complexifies the software even more than the last one, and every feature should be evaluated similar to a new purchase of a possession: 1) Where am I going to keep it? How much will it clutter the house? 2) What will I not buy to free up money to buy this thing. > I personally want to model > one service with one s6 service. I'm not sure what you mean by "model". I thought this was about checking the health of each service. Anyway, I understand that you personally want to match the healthchecks one to one with the services, and that would be nice, but not if it adds complexity. [snip the rest of the email, which I didn't understand at all] I'm on probably 25 software mailing lists, and have this discussion on every one of them. Somebody wants some feature. I write back that you can already do that by doing . They write back saying my idea is a kludge. I write back and say I like a nice, simple program that can be written and maintained by one person, features tend to wreck that, all sorts of people want their pet features, and those features are usually unimportant (for instance, way to do it with existing software) to the suggester and *absolutely* unimportant to everyone else. Features clutter up software, and should be done only if they're very important to a large swath of users. With healthchecks, it would be trivial for you to create a shellscript called healthcheck in every service directory that required a healthcheck, then have a program that loops around all the service directories, runs the healthcheck shellscript, and if unhealthy, performs actions listed in the healthcheck subscript. If you do this for awhile, you'll slowly evolve the thing into a more and more convenient form, until others use it. I mean, you'd need to roll it into a tarball and write a bit of documentation, but nothing like changing the whole program. The real beauty of this approach is that, as more and more people use your system and more and more people contribute feedback, sooner or later it reaches a state where it would be much easier to add it as a feature of the whole program, with an interface people like. SteveT Steve Litt Autumn 2020 featured book: Thriving in Tough Times http://www.troubleshooters.com/thrive
Re: External health Check Process
On Thu, 22 Oct 2020 20:03:17 -0400 Steve Litt wrote: > But most of the other suggestions that in my opinion are just answers > to systemd weenie's "but s6 doesn't have _" arguments, and don't > add nearly enough functionality or convenience for the complexity, or > just plain size added to the user manual, to justify. > > The OP already stated there's a way to do it currently. Why complexify > s6 to do something already doable? I just miss the elegance of the solution: I personally want to model one service with one s6 service. For me it would mean thinking about a wrapper around s6 to get that. Maybe I get now the slew thing. And it's ok to need a wrapper to get useability, but the advertisement of that should be better on the website that you SHOULD use that wrapper (and for me this wrapper should be part of the s6 project). Best Regards Oli -- Automatic-Server AG • Oliver Schad Geschäftsführer Turnerstrasse 2 9000 St. Gallen | Schweiz www.automatic-server.com | oliver.sc...@automatic-server.com Tel: +41 71 511 31 11 | Mobile: +41 76 330 03 47 pgpHNHOSShYBI.pgp Description: OpenPGP digital signature
