Help alternative init systems

[Alverstone]

A terrible lack (or my ignorance of otherwise) of openrc is that while you are able to simply invoke /bin/openrc to start runlevels, you can not actually use it to stop them, at least when openrc-init is not PID 1. As the result implementing shutdown sequence on alternative init systems is a feat of reading /etc/runlevels/{sysinit,boot} and manually deciding which of these services need stopping and in which order.

Rolling a new boot sequence for each init system is a competition of who makes more bugs, but inability to gracefully stop openrc runlevels makes it unfeasible to reuse openrc's boot sequence in a fully functional way. If this became possible, life for other init systems would become significantly easier.

– A runit user

[pingtoo]

A terrible lack (or my ignorance of otherwise) of openrc is that while you are able to simply invoke /bin/openrc to start runlevels, you can not actually use it to stop them, at least when openrc-init is not PID 1.

Can you use a example to explain what you mean.

[GDH-gentoo]

If distributions implement other init systems in a way that depends on the openrc binary and OpenRC service scripts, they are doing it wrong

— A user of an s6-based init system

EDIT:

– A runit user

Now, the runit package in particular does not provide a service manager, so you might want to try using OpenRC on top of runit to provide that capability, kind of like it is used on top of sysvinit on Gentoo. In that case, the strategy would be to call the openrc program in /etc/runit/1, and then call it again as openrc shutdown in /etc/runit/3. That stops services started by other (OpenRC!) runlevels. However I don't know how well that would work in practice.

Runit on Void does not use OpenRC.

[Alverstone]

Can you use a example to explain what you mean.

Consider the default /etc/runit/{1,3} implementation:

Code: Select all

#!/bin/bash
# system one time tasks

PATH=/sbin:/usr/sbin:/bin:/usr/bin

RUNLEVEL=S /sbin/openrc sysinit
RUNLEVEL=S /sbin/openrc boot

touch /etc/runit/stopit
chmod 0 /etc/runit/stopit

and

Code: Select all

#!/bin/bash
sv -w 300 force-shutdown /etc/service/*
. /etc/runit/rc.sh
run_rc_stage 3

The function run_rc_stage 3 is

Code: Select all

#!/bin/sh
test -x /etc/runit/reboot && LAST=6    || LAST=0
test -x /etc/runit/reboot && RC=reboot || RC=shutdown
RUNLEVEL=$LAST /sbin/openrc $RC

When the "/sbin/openrc shudown" or "/sbin/openrc reboot" executes, the boot and sysinit runlevels are not stopped. That needs to be manually implemented in context of rc-service, which is messy.

If distributions implement other init systems in a way that depends on the openrc binary and OpenRC service scripts, they are doing it wrong

— A user of an s6-based init system

Why is that so? Re-implementing the boot sequence is a mess, it is a blessing when some parts of it can be simply reused to avoid over saturating universe with wheels Openrc's boot sequence isn't entirely clean to reuse just yet.

using OpenRC on top of runit to provide that capability, kind of like it is used on top of sysvinit on Gentoo

I do use openrc to manage stages 1 and 3, though not exclusively. Rather, I build my own gimmicks on top of what openrc provides out of the box. For example, my /etc/runit/1 is simply

Code: Select all

#!/bin/bash
# system one time tasks

PATH=/sbin:/usr/sbin:/bin:/usr/bin

RUNLEVEL=S /sbin/openrc sysinit
/etc/runit/bootrc early
RUNLEVEL=S /sbin/openrc boot
/etc/runit/bootrc late

touch /etc/runit/stopit
touch /etc/runit/reboot
chmod 000 /etc/runit/stopit
chmod 000 /etc/runit/reboot

Runit on Void does not use OpenRC.

Void has incomplete boot sequence that only supports the default scenario and allows very little flexibility. Gentoo's openrc boot sequence is quite superior to Void's. Also, Void isn't relevant since the question is about gentoo.

[grknight]

When the "/sbin/openrc shudown" or "/sbin/openrc reboot" executes, the boot and sysinit runlevels are not stopped. That needs to be manually implemented in context of rc-service, which is messy.

The boot and sysinit runlevels are not meant to be stopped (including any services included therein). They exist for basic tools to bring a system to a nominal usable state with all of the services can be terminated by a hardware reboot/shutdown without recourse.
Any service that is able to be stopped must be in a runlevel besides those. (Fun fact, you can create custom runlevels but hardly anyone does.)

Edit: Reread last sentence and found issues with it. Fixed

[GDH-gentoo]

If distributions implement other init systems in a way that depends on the openrc binary and OpenRC service scripts, they are doing it wrong

— A user of an s6-based init system

Why is that so?

Because the mechanism used by OpenRC for implementing the boot sequence (and shutdown sequence) is... surprise! OpenRC-specific You wouldn't be using an alternative init system, you'd just have that init system delegate to OpenRC.

Which leads me to:

[...] some parts of it can be simply reused [...]

Uh... no? Did you see the #!/sbin/openrc-run in the service scripts? It's like saying we could simply reuse systemd unit files.

Unless OpenRC is part of the init system, which is a different discussion.

What we can do is replicate the effect of OpenRC's service scripts in whatever format an alternative service manager, such as s6-rc, accepts. Harder to do for runit because, well, it hasn't any.

[Alverstone]

When the "/sbin/openrc shudown" or "/sbin/openrc reboot" executes, the boot and sysinit runlevels are not stopped. That needs to be manually implemented in context of rc-service, which is messy.

The boot and sysinit runlevels are not meant to be stopped (including any services included therein). They exist for basic tools to bring a system to a nominal usable state with all of the services can be terminated by a hardware reboot/shutdown without recourse.
Any service that is able to be stopped must be in a runlevel besides those. (Fun fact, you can create custom runlevels but hardly anyone does.)

Edit: Reread last sentence and found issues with it. Fixed

What about /etc/init.d/hwclock?

I do not want to argue with any of what GDH-gentoo says, because he's not wrong. runit does not have any service management, so it has to rely on other tools (or on manually written scripts) to manage its boot and shutdown sequences. I'm not even talking about the suckless init. For reasons described above I can't reuse openrc without uncool tweaking. Unless grknight is right, of course. If boot and sysinit do not contain services that need stopping, then my initial point is irrelevant. However, I think grknight needs to elaborate, because some things in boot have stop() functions defined for them. Other examples beside hwclock are seedrng, swap and dmcrypt. The last two definitely need stopping.

[grknight]

Other examples beside hwclock are seedrng, swap and dmcrypt. The last two definitely need stopping.

No, the last two do not need stopping normally. If a system is rebooting or halting, then the kernel will clean up. dmcrypt is encrypted at rest without any action.

[GDH-gentoo]

I'm pretty sure openrc shutdown does execute the stop() function of service scripts that correspond to services in the sysinit and boot runlevels. I'll add lvm to the examples given by Alverstone.

I'm not in front of a Gentoo computer right now, but when I am, that should be easy to test with scripts that just print messages.

[grknight]

I'm pretty sure openrc shutdown does execute the stop() function of service scripts that correspond to services in the sysinit and boot runlevels. I'll add lvm to the examples given by Alverstone.

I'm not in front of a Gentoo computer right now, but when I am, that should be easy to test with scripts that just print messages.

The docs say this is true. But, they don't need to be in most cases.

[GDH-gentoo]

When the "/sbin/openrc shudown" or "/sbin/openrc reboot" executes, the boot and sysinit runlevels are not stopped.

I'm pretty sure openrc shutdown does execute the stop() function of service scripts that correspond to services in the sysinit and boot runlevels.

Simple test then:

/etc/init.d/test-sysinit

Code: Select all

#!/sbin/openrc-run

depend() {
	before killprocs savecache
}

start() { :; }

stop() {
	ebegin "Stopping a service in the sysinit runlevel"
	sleep 5
	eend 0
}

/etc/init.d/test-boot

Code: Select all

#!/sbin/openrc-run

depend() {
	before killprocs savecache
}

start() { :; }

stop() {
	ebegin "Stopping a service in the boot runlevel"
	sleep 5
	eend 0
}

Code: Select all

# rc-update add test-sysinit sysinit
# rc-update add test-boot boot

Reboot, verify that both services have been started, and then shut down. With OpenRC on top of sysinit, I see both messages when the computer is shutting down. If this doesn't happen with OpenRC on top of runit, then that's a separate problem.

[Alverstone]

If this doesn't happen with OpenRC on top of runit, then that's a separate problem.

I do not understand what is the internal difference when OpenRC runs on top of sysinit compared to runit-init, but it would be very nice if /bin/openrc stopped services in the previous runlevel when switching to a new one, as described in the manual. As I said, since the code to build dependency graph is already there, it shouldn't be a big problem.

Or if such approach interferes with its intended operation, a command line flag to specifically stop a runlevel would be very helpful.

Or maybe I am exaggerating and it's time to roll my own boot sequence! On the other hand, I am too lazy to make wheels when they've already been invented.

[szatox]

I'm pretty sure openrc shutdown does execute the stop() function of service scripts that correspond to services in the sysinit and boot runlevels.

Try rc-status -a

but it would be very nice if /bin/openrc stopped services in the previous runlevel when switching to a new one, as described in the manual.

Code: Select all

 # grep ^l /etc/inittab
l0u:0:wait:/sbin/telinit u
l0:0:wait:/sbin/openrc shutdown
l0s:0:wait:/sbin/halt.sh
l1:1:wait:/sbin/openrc single
l2:2:wait:/sbin/openrc nonetwork
l3:3:wait:/sbin/openrc default
l4:4:wait:/sbin/openrc default
l5:5:wait:/sbin/openrc default
l6u:6:wait:/sbin/telinit u
l6:6:wait:/sbin/openrc reboot
l6r:6:wait:/sbin/reboot -dkn

No runlevel is mapped to boot or sysinit. I think those are handled internally by openrc, special-cased, and you're not supposed to be using them directly.
Since they are not really "runlevels", but more like systemd's "targets" which group critical services into boot stages, and are an implicit part of all real runlevels, there's nothing to stop when you change the runlevel.
Let me tell you, I don't want my rootfs to get unmounted when switching from boot to default

[GDH-gentoo]

I do not understand what is the internal difference when OpenRC runs on top of sysinit compared to runit-init, [...]

There is one: OpenRC never leaves the boot runlevel until the computer shuts down (the way /etc/runit/1 is probably written). I didn't check openrc's source code, but, since boot is special, it might be significant.

[...] but it would be very nice if /bin/openrc stopped services in the previous runlevel when switching to a new one, as described in the manual.

As I said, it does stop services in the sysinit and boot runlevels when shutting down and running on top of sysvinit. It probably does what the manual says when switching runlevels as well, but people usually don't switch away from the default runlevel, other than by shutting down, or define new OpenRC runlevels to switch to.

Have you tried the test service scripts? Do they show their messages during the shutdown sequence when running on top of runit, or not?

No runlevel is mapped to boot or sysinit.

They are mapped to two pseudo-runlevels:

/etc/inittab

Code: Select all

# System initialization, mount local filesystems, etc.
si::sysinit:/sbin/openrc sysinit

# Further system initialization, brings up the boot runlevel.
rc::bootwait:/sbin/openrc boot

[Alverstone]

I have spent some time with s6-init in a VM, and I am unhappy with it. It has a large sprawl, beginning with simple supervision and ending with a sudo replacement. Why do I need a sudo replacement as a part of my init system? Why do I need socket activation as a part of the init system, when it can be done by an external program? Why do I need """execline"""??? Why do I have a dozen utilities managing a "service database", God knows how (reload db? remove obsolete instances? changing service state? recompiling the db every time? what hell is all that stuff)? Due to the lack of manpages, I still find most of s6 to be incomprehensible despite reading the html documentation multiple times.

I have therefore thought (but haven't done anything to make it happen ) of a rather simple set of improvements to runit, that I thought I'd share just to get a public opinion.

Assuming that $PWD is a service directory, add:

• ./deps: a list of dependencies, one per line, that correspond to the current runsvdir. Empty means no dependencies.
• ./type: a file that contains a single line, either "c" or "o", where "o" stands for a one-shot service. This may not be needed, but for OCD's sake it would be nice to not run unnecessary `runsv` instances.
• ./notify: an executable file, that is only used for daemons (type "c" services). When the file exits 0, the daemon is considered started, if not 0, then the daemon is considered to have failed, and if ./run is still alive it is killed. While this process is ongoing, the daemon is simply considered to be down (./supervise/status).

The beautiful part about it is that it can be uglily implemented without changing anything about the runit itself, at least if you give up the OCD point. The not so beautiful part about it is that due to how udev works, it has to be started early, so that questions the whole existence of /etc/runit/1. Of course, you still may just start it out of the supervision tree, then kill it and restart it under runsv.

Giving freedom to fantasy this can be taken to an extreme. Instead of /etc/runit/{1,2,3} have /etc/runit/{init,shutdown}. The init would just directly start the runsvdir, the rest would be left to the dependency management. I think it would be the peak init system for regular desktop use cases

[flexibeast]

Why do I need socket activation as a part of the init system

Could you please elaborate on this? The s6 'socket activation' page says:

So, how do I open all my sockets first, store them, and dispatch them to daemons later ?

Again, it's not necessary to do that: you'll be fine, and quite speedy, just starting your daemons in their good time. You will not reap any noticeable benefit from performing "socket activation". But if you really want to ...

There's also this 2015 post by Laurent Bercot, the creator/maintainer of s6.

You asked:

Why do I need """execline"""???

Most of the time, you don't need to use execline. Bercot is very frustrated by people believing or claiming that s6 requires the use of execline. As i've written elsewhere:

As with s6 services, s6-rc services generally do not need to be written in the execline scripting language; service scripts can be written in any shell or scripting language, using the appropriate shebang line (e.g. #!/bin/sh) instead of #!/usr/bin/execlineb -P. The only exception to this is that up and down scripts for oneshot services must be written in execline, but even there, those scripts can simply chain load a script written in any language.

You might find the page "Why not just use /bin/sh?" answers some of your questions about execline.

In general, execline is not compulsory, but is nevertheless available for those who want to take advantage of its design (e.g. its minimality in the context of resource-constrained environments, or its smaller potential attack service relative to sh).

[Alverstone]

Socket activation does not belong with the init system. Have a separate set of utilities for it, that are distributed and documented separately. Nothing stops you from writing a program, that waits for a socket, and then exec()s into your daemon. And if you need to hold your fds in case your daemon "has to crash", that can be done by another daemon, that is hopefully more reliable, and which you hopefully will not restart accidentally. The init system has nothing to do with it. And this functionality seems ridiculous to me anyway. Why would your daemon have to restart in the middle of its operation? And if it really does, then it is the daemon's job the rebind the socket etc.

As for execline, I'd don't mind the interpreter itself, what I do mind is that I have to be even aware of its existence if I want to use s6-init. Shell was bad enough of a learning experience, and I really, really could not care less for another interpreter on my desktop system.

But those are relatively minor issues. s6-init, and I am not joking here, from user's (my) perspective, is harder to use than systemd, which is almost comic. Part of it is packaging, of course, but still. I won't tire of repeating it, but with runit, I only have to manage /etc/runit/{1,2,3,ctrlaltdel} and a bunch of almost trivial run files in /etc/service. This is literally just how easy runit is to use. I fail to imagine anything simpler that would still be functional (hello suckless init). With s6, I read the docs on skarnet again and again and I still don't begin to imagine how to merely get started with s6 and it's service management which is the only reason I consider it at all, as opposed to runit.

[flexibeast]

Socket activation does not belong with the init system. Have a separate set of utilities for it, that are distributed and documented separately.

Okay, but as far as i'm aware, that's what s6 does? Via the various s6-fdholder* commands? Could you explain why you feel 'socket activation' (in its s6 form) must be set up and used when using s6 as init / supervision?

Nothing stops you from writing a program, that waits for a socket, and then exec()s into your daemon. And if you need to hold your fds in case your daemon "has to crash", that can be done by another daemon, that is hopefully more reliable, and which you hopefully will not restart accidentally.

See above.

As for execline, I'd don't mind the interpreter itself, what I do mind is that I have to be even aware of its existence if I want to use s6-init.

i'm not sure whether by "s6-init" you mean "using s6 for init" or "using the s6-linux-init" package; could you clarify? (My guess is that you mean the former, but i wanted to check.)

Either way, it's only s6-rc that requires the use of execline (even if just to chainload) for two particular files, in the context of a oneshot service; s6 itself doesn't require it all, so if one isn't using s6-rc, why does one need to be aware of the existence of execline

I really, really could not care less for another interpreter on my desktop system.

Hm, so is the simple presence of execline on your system part of the issue? (i understand people wanting to minimise what's on their system, e.g. to reduce potential attack surface.)

s6-init, and I am not joking here, from user's (my) perspective, is harder to use than systemd, which is almost comic. Part of it is packaging, of course, but still. I won't tire of repeating it, but with runit, I only have to manage /etc/runit/{1,2,3,ctrlaltdel} and a bunch of almost trivial run files in /etc/service. This is literally just how easy runit is to use. I fail to imagine anything simpler that would still be functional (hello suckless init). With s6, I read the docs on skarnet again and again and I still don't begin to imagine how to merely get started with s6 and it's service management which is the only reason I consider it at all, as opposed to runit.

Yeah, Bercot is aware of this issue. (And i understand your comparison with runit - i contributed to the Void documentation in this regard. As a side comment, i also eventually ended up running 66 on my Void system.) He's currently working on something he hopes will make things easier.

Some of it stems from the design approach of "mechanism, not policy", where policy was expected to be provided in an OS-appropriate way (e.g. according to Linux distro) by packagers of s6 and s6-rc, but that's not happened, and users often have to do the sort of system integration work that is more usually done by distros/packagers. And on top of that, i've often felt the introductory guides i've encountered to be unnecessarily complex, which is why i made an attempt at writing such a guide myself (albeit only for user services).

[Alverstone]

Okay, but as far as i'm aware, that's what s6 does?

All of that comes from a single codebase, as far as I understand. I install s6 and see all of those creepy utilities I sure as hell do not need.

Could you explain why you feel 'socket activation' (in its s6 form) must be set up and used when using s6 as init / supervision?

I never said or implied that.

i'm not sure whether by "s6-init" you mean "using s6 for init" or "using the s6-linux-init" package; could you clarify?

Regardless of the under the hood nuances, the s6 as a whole is presented along with execline, and even requires it for one shot services. All of that is too much necessary complexity, integration and so on. My opinion is that the init system itself should only include process supervision and service management, the latter being necessary only since relatively recent times. And those should be simple enough that they wouldn't know about any specific interpreters.

Besides, you're making so much emphasis on my half-humorous mention of execline that I smell (scathing?) sarcasm. I do not care if execline is pulled in as yet another dependency, but I'm rather interested why it has to be so with software that allegedly strives to be small and reasonable.

[pingtoo]

"small" and "reasonable" all are relative terms, so what are you compare with?

s6 compare to systemd is relative small.
s6 compare to SysV init is not small. However it does offer more functions than SysV init.

When I started using s6 (in container) it does not require any specific interpreter (beside the startup script was written in execlineb script language) for any services.

I have feeling your impression may have come from how Gentoo integrate with s6 (Note I am not complaint on how Gentoo's integration). I am pretty sure if you roll your own init system using s6 as tool you can do it with much flexibility.

s6 is "small" in term of memory footprint. it does not mean it is "small" in complexity and it is based on a not so traditional concept of chain execution. for a design wish to be minimalism for memory footprint the choose of using chain execution is very reasonable.

[Alverstone]

^ I'm comparing it to runit. I have a bunch of thoughts, but they are all raw, so I'll just mention their existence without elaborating

[GDH-gentoo]

(writing this for the benefit of silent readers as well)

I have spent some time with s6-init in a VM, and I am unhappy with it. It has a large sprawl, beginning with simple supervision and ending with a sudo replacement.

OK, if you don't like it, you don't like it. Yes, s6 (the package, not the whole suite) provides in one single package a few groups of related tools that the author believes are useful: broadly, the daemontools-like supervision suite and auxiliary programs (an equivalent of about 95% of runit), the super-server and related utilities for implementing local services, s6-sudod and related utilities, and the tools for file descriptor passing and holding. Well, there's the tools for logging, notification and dynamic instances management, but you could group those with the supervision suite.

These groups of of tools are, however, independent. Almost all of them are used by the service manager —and the s6-linux-init package uses some, too—, but that is a separate package (s6-rc).

Why do I need a sudo replacement as a part of my init system?

You don't. The author just thinks that it is useful and happens to package it with his supervision suite. You as the user are not required to use it directly, but the service manager does use it internally for implementing oneshots. I don't think one can say that oneshots aren't needed.

Why do I need socket activation as a part of the init system, when it can be done by an external program?

You don't. The author does have external programs for parts of the underlying mechanism of "socket activation" that he finds useful (UNIX domain super-server and file descriptor passing and holding), he just happens to package them with his supervision suite. The service manager does use those internally for implementing longrun pipelining (search for it here), which is how you do logging with s6-rc.

Why do I need """execline"""???

You don't, flexibeast addressed that. Do look at the link to know why execline exists. And execline is a separate package. The service manager and s6-linux-init use it internally though, in part because the author finds it easy to generate 'glue' excecline scripts from C programs, I seem to remember.

Why do I have a dozen utilities managing a "service database", God knows how (reload db? remove obsolete instances? changing service state? recompiling the db every time? what hell is all that stuff)?

It's not "a dozen", the essential ones are s6-rc-compile for making one and s6-rc-update for swapping the one used by an s6-rc live state directory associated with an active supervision tree. And then there is s6-rc-db for the benefit of the human user

As to why it exists, it's for doing efficiently at runtime what a parallel service manager is supposed to do: deal with dependencies between services. Computing those from pieces if information provided by users is the costly part. I believe OpenRC also has a "runtime helper" in the form of a dependency cache.

Due to the lack of manpages, I still find most of s6 to be incomprehensible despite reading the html documentation multiple times.

There are manpages thanks to flexibeast, and if you are genuinely interested, you can ask if you don't understand the HTML documentation. The man pages are made with the contents of the HTML documentation though, if I understand correctly, so I'm not sure how they would help in this case.

I have therefore thought (but haven't done anything to make it happen ) of a rather simple set of improvements to runit, that I thought I'd share just to get a public opinion.

Assuming that $PWD is a service directory, add:

• ./deps: a list of dependencies, one per line, that correspond to the current runsvdir. Empty means no dependencies.
• ./type: a file that contains a single line, either "c" or "o", where "o" stands for a one-shot service. This may not be needed, but for OCD's sake it would be nice to not run unnecessary `runsv` instances.
• ./notify: an executable file, that is only used for daemons (type "c" services). When the file exits 0, the daemon is considered started, if not 0, then the daemon is considered to have failed, and if ./run is still alive it is killed. While this process is ongoing, the daemon is simply considered to be down (./supervise/status).

I'd like to note that first and second points are implemented by the already written s6-rc in a somewhat different way, and the last one can be handled with s6 readiness notification and the already written s6-notifyoncheck program from s6.

Socket activation does not belong with the init system. Have a separate set of utilities for it, that are distributed and documented separately. Nothing stops you from writing a program, that waits for a socket, and then exec()s into your daemon.

That sort of is the UNIX domain super-server, s6-ipcserverd. It is separate, and is documented separately, just not distributed separately.

And if you need to hold your fds in case your daemon "has to crash", that can be done by another daemon, that is hopefully more reliable, and which you hopefully will not restart accidentally.

That sort of is the file descriptor holder, s6-fdholderd. Ditto.

As for execline, I'd don't mind the interpreter itself, what I do mind is that I have to be even aware of its existence if I want to use s6-init.

You can be 99,9% unaware if you want to.

I won't tire of repeating it, but with runit, I only have to manage /etc/runit/{1,2,3,ctrlaltdel} and a bunch of almost trivial run files in /etc/service.

And, as the existence of this thread seems to imply, while you find it nice, you also seem to consider runit insufficient. You don't like this other alternative, so you wish someone would write something specifically for runit, complementing what it lacks. That's fine. Only nobody has done it yet.

I also wish to note that, if you use s6-linux-init, /etc/s6-linux-init/current/rc.init is roughly analogous to /etc/runit/1 and /etc/s6-linux-init/current/rc.shutdown is roughly analogous to /etc/runit/3. And that /etc/runit/2 doesn't need a lot of "management", since it is essentially a wrapper around runsvdir.

Regardless of the under the hood nuances, the s6 as a whole is presented along with execline, and even requires it for one shot services.

You can write oneshots as:

up

Code: Select all

/absolute/pathname/of/some-script up

down

Code: Select all

/absolute/pathname/of/some-script down

and, for all intents and purposes, treat some-script as the 'actual' oneshot, forgetting about execline.

[Alverstone]

On a whim I decided to twiddle s6 yet again. This time I even, albeit for a few minutes, managed to convince myself I have an idea of how it all works together.

However, when I started doing some rudimentary work to make the basic boot sequence, I realized that it's simply not possible to reuse Gentoo's own init scripts, because they use their own dependency resolution logic and also have these weird before/after/whatever dependency declarations, which make the process of mentally building the dependency graph a very interesting undertaking. To use Gentoo's code I'd have to adapt it, i.e. run it outside of openrc-run.

There's also Artix linux of course, but their boot sequence is specific to their distro. From what I've seen it's simpler than Gentoo's one, but also doesn't account for many edge cases.

Of course, it's possible to just do it runit-style, but that defeats the purpose of s6-rc. It makes life quite difficult for alternative inits, because it is just not realistic to redo the whole boot sequence yourself and then also maintain it on your own.

I'm not sure what can be done about it at this point. I will admit this situation is a bit annoying and I also think s6 is cleaner than openrc.

[GDH-gentoo]

To use Gentoo's code I'd have to adapt it, i.e. run it outside of openrc-run.

Yes.

There's also Artix linux of course, but their boot sequence is specific to their distro.

Exactly.

Of course, it's possible to just do it runit-style, but that defeats the purpose of s6-rc.

Exactly.

It makes life quite difficult for alternative inits, because it is just not realistic to redo the whole boot sequence yourself and then also maintain it on your own.

It is realistic though, Gentoo's OpenRC scripts exist, and can be studied and adapted. I've done it (at least for one single system, mine ), and I I'm pretty sure I'm not the only one.

[flexibeast]

Fwiw, i'm using s6-rc to manage user services (which i put in place before OpenRC user services existed), and although it doesn't involve system services (boot etc.), the guide i wrote (which i mentioned earlier) nevertheless provides something of a higher-level view of how s6/s6-rc setups work.

More generally, my user account on my daily driver is set up to facilitate switching between different approaches to user services; here's a recent email i wrote to the `supervision` list, with the details. At some point i'll probably want to add the ability to use OpenRC user services and s6-frontend, so that i can understand how they do things (and potentially help people / write relevant documentation).