openrc-init vs sysvinit
Message
openrc-init vs sysvinit
Hi everyone. I use OpenRC together with sysvinit, but recently discovered that besides sysvinit there's also openrc-init. Can anyone explain what its real advantages are? I couldn't find a comprehensive answer in the wiki. I don't think I'll switch from sysvinit to openrc-init, I'm just curious who uses it (and why), and also why it's still not used as the primary init in standard Gentoo profiles during install
- GDH-gentoo
- Advocate
- Posts: 2111
- Joined: Sat Jul 20, 2019 7:02 pm
- Location: South America
See section "Providing a complete init system" here for a model for describing init system components. Then read on.
sysvinit + OpenRC the way Gentoo sets it up: Components 1, 2 3 are implemented by the init program from the sysvinit package, component 4, the service manager, is implemented by the OpenRC package, and init is configured for delegating to it.
"pure OpenRC" (as I prefer to call it): Components 1 and 2 are implemented by OpenRC's openrc-init program, component 3 is implemented by OpenRC's supervise-daemon program, and the rest is the same.
Because the service manager is the most visible part for the user, and it is the same in both setups, there isn't much difference between them. Except for one thing: the handling of the agetty processes, the ones that allow you to log in to the computer and get a text user interface (TUI) for interacting with it.
agetty processes terminate when you log out, so they have to be restarted for allowing you to log in again. This is handled by component 3, the process supervisor. For a "pure OpenRC" setup, this is taken care of by symlinks to the agetty service in the appropriate runlevel. The service then relies on supervise-daemon:
For Gentoo's sysvinit + OpenRC setup, this is taken care of by init itself:
/etc/inittab
The "respawn" action tells init to restart agetty when it terminates.
There is a theoretical disadvantage for the "pure OpenRC" setup: the supervisors are regular processes that can terminate, and nobody will restart them, leaving the processes that they care about unsupervised, while, in contrast, for the sysvinit + OpenRC setup, the supervisor is process 1, which is "indestructible".
Well, not really, but if it terminates, the whole computer goes down with a kernel panic, so PID 1 program (component 2) authors are supposed to do their best to prevent that. You could say that staying alive is pretty much one of the PID 1 program's important job descriptions
sysvinit + OpenRC the way Gentoo sets it up: Components 1, 2 3 are implemented by the init program from the sysvinit package, component 4, the service manager, is implemented by the OpenRC package, and init is configured for delegating to it.
"pure OpenRC" (as I prefer to call it): Components 1 and 2 are implemented by OpenRC's openrc-init program, component 3 is implemented by OpenRC's supervise-daemon program, and the rest is the same.
Because the service manager is the most visible part for the user, and it is the same in both setups, there isn't much difference between them. Except for one thing: the handling of the agetty processes, the ones that allow you to log in to the computer and get a text user interface (TUI) for interacting with it.
agetty processes terminate when you log out, so they have to be restarted for allowing you to log in again. This is handled by component 3, the process supervisor. For a "pure OpenRC" setup, this is taken care of by symlinks to the agetty service in the appropriate runlevel. The service then relies on supervise-daemon:
Code: Select all
supervisor=supervise-daemon/etc/inittab
Code: Select all
c1:12345:respawn:/sbin/agetty --noclear 38400 tty1 linux
c2:2345:respawn:/sbin/agetty 38400 tty2 linux
...There is a theoretical disadvantage for the "pure OpenRC" setup: the supervisors are regular processes that can terminate, and nobody will restart them, leaving the processes that they care about unsupervised, while, in contrast, for the sysvinit + OpenRC setup, the supervisor is process 1, which is "indestructible".
Well, not really, but if it terminates, the whole computer goes down with a kernel panic, so PID 1 program (component 2) authors are supposed to do their best to prevent that. You could say that staying alive is pretty much one of the PID 1 program's important job descriptions
Ionen wrote:As a packager I just don't want things to get messier with weird build systems and multiple toolchains requirements though
I expect we may at some point change defaults. openrc-init was written when sysvinit maintenance was in a very poor state. It's since been taken over and still has some issues though. But nobody's had the drive to then push for an openrc-init migration, including a news item, documentation updates, and so on.