Two items of possible interest on OpenRC, with a relevant excerpt therefrom:
https://urldefense.proofpoint.com/v2/url?u=https-3A__en.wikipedia.org_wiki_OpenRC&d=DwICaQ&c=gRgGjJ3BkIsb5y6s49QqsA&r=gd8BzeSQcySVxr0gDWSEbN-P-pgDXkdyCtaMqdCgPPdW1cyL5RIpaIYrCn8C5x2A&m=v1LZ0AOmrEFqAsVSE3_C6xv0CIWsfyumh9o1u4_GiSE&s=q44E0Ul4MkCa8w5AH0Q6bwCteiyOcbSvcqwH_J3hKW4&e=
OpenRC is made up of several modular components, the main ones being an
init(optional), the core dependency management system and a daemon
supervisor(optional). It is written in C and POSIX compliant shell
making it usable on BSD and Linux systems.
The core part of OpenRC handles dependency management and init script
parsing. OpenRC works by scanning the runlevels, building a dependency
graph, then starting the needed service scripts. It exits once the
scripts have been started. By default, OpenRC uses a modified version of
start-stop-daemon for daemon management.[10]
Init scripts share similarities with scripts used in sysvinit, but offer
several features to simplify their creation. Scripts are assumed to have
start(), stop() and status() and the system uses variables already
declared to create the default functions.[11] The depend function is
used to declare dependencies to other services that would be done with
LSB headers in sysvinit. Configuration and mechanism are separated with
configuration files in the conf.d directory and init files in the init.d
directory.
Features
Portable between Linux, FreeBSD, and NetBSD
Parallel service startup (Off by default)
Dependency based boot-up
Process segregation through cgroups[15]
Per-service resource limits (ulimit)
Separation of code and configuration (init.d / conf.d)
Extensible startup scripts
Stateful init scripts (is it started already?)
Complex init scripts to start multiple components (Samba (smbd and
nmbd), NFS (nfsd, portmap, etc.))
Automatic dependency calculation and service ordering
Modular architecture and separation of optional components (Cron,
syslog)
Expressive and flexible network handling (including VPN, bridges, etc.)
Verbose debug mode
https://urldefense.proofpoint.com/v2/url?u=https-3A__wiki.gentoo.org_wiki_Project-3AOpenRC&d=DwICaQ&c=gRgGjJ3BkIsb5y6s49QqsA&r=gd8BzeSQcySVxr0gDWSEbN-P-pgDXkdyCtaMqdCgPPdW1cyL5RIpaIYrCn8C5x2A&m=v1LZ0AOmrEFqAsVSE3_C6xv0CIWsfyumh9o1u4_GiSE&s=BvoXUmXW55PjvDZsL8AqsEees9iYiaV5b8F8qVzyIF8&e=
OpenRC, however, is not exclusively used by Gentoo Linux, so the goal is
to be platform-agnostic.
On 1/24/21 10:17 PM, Nico Kadel-Garcia wrote:
On Mon, Jan 25, 2021 at 12:14 AM Benson Muite
<benson_mu...@emailplus.org> wrote:
On 1/24/21 9:37 PM, Nico Kadel-Garcia wrote:
On Sun, Jan 24, 2021 at 11:26 AM Serguei Mokhov <serg...@gmail.com> wrote:
On Sun, Jan 24, 2021 at 11:00 AM Mark Rousell <markrlon...@hotmail.co.uk> wrote:
BUT... the fact that SysVInit is seen as outdated is NOT a reason in and of
itself to support SystemD.
There may have been and, in many people's opinion, there were and are better
init systems
to replace SysVInit than SystemD. "Better" being both a technical and a
political/social/industrial construct.
Mark, please name the better ones. And possibly why have they not been
widely adopted?
daemontools. I publish RPM wrappers for it at
OpenRC is used in Alpine Linux, which has widespread adoption for
containers. Any thoughts on it? Busybox/Toybox also have their own init
systems.
I never had occasion to touch it.
