OpenRC

From Gentoo Wiki
Revision as of 17:28, 20 May 2012 by Lu zero (Talk | contribs)

Jump to: navigation, search

OpenRC is a dependency based init system that works with the system provided init program, normally /sbin/init. It is not a replacement for /sbin/init. OpenRC is 100% compatible with Gentoo init scripts, which means you can probably find one for the daemons you want to start in the Gentoo Portage Tree. OpenRC, however, is not exclusively used by Gentoo Linux and can be used on different Linux and BSD systems.

Contents

Features

OpenRC provides a number of features touted as innovative by recent init systems like systemd or upstart, such as hardware initiated initscript run or cgroups support, without requiring large layout changes to accomodate radically different designs and dependencies.

The tabular comparison appears to be biased negatively against sysvinit and upstart. It is copied from the systemd website.

sysvinit Upstart systemd OpenRC
Mandatory DBus dependency no yes yes no
Hard-to-debug monolitic startup in undocumented C no no yes no
Modular C coded early boot services included no no yes optional
Read-Ahead no no[1] yes no
Socket-based Activation no no[2] yes no
Bus-based Activation no no[3] yes no
Device-based Activation no no[4] yes  ??
Configuration of device dependencies with udev rules no no yes  ??
Path-based Activation (inotify) no no yes no
Timer-based Activation cron/at cron/at proprietary cron/at
Mount handling no no[5] yes  ????
fsck handling no no[5] yes  ????
Quota handling no no yes
Automount handling no no yes no
Swap handling no no yes yes(?)
Snapshotting of system state no no yes  ??
XDG_RUNTIME_DIR Support no no yes no
Optionally kills remaining processes of users logging out no no yes no
Linux Control Groups Integration no no yes yes
Audit record generation for started services no no yes no
SELinux integration no no yes yes
PAM integration no no yes yes
Encrypted hard disk handling (LUKS) no no yes yes
SSL Certificate/LUKS Password handling, including Plymouth, Console, wall(1), TTY and GNOME agents no no yes mostly yes
Network Loopback device handling no no yes yes
binfmt_misc handling no no yes yes
System-wide locale handling no no yes yes
Console and keyboard setup no no yes yes
Infrastructure for creating, removing, cleaning up of temporary and volatile files no no yes yes
Handling for /proc/sys sysctl no no yes yes
Plymouth integration no yes yes buggy
Save/restore random seed no no yes yes
Static loading of kernel modules no no yes yes
Automatic serial console handling no no yes  ??
Unique Machine ID handling no no yes yes
Dynamic host name and machine meta data handling no no yes  ??
Reliable termination of services no no yes yes
Early boot /dev/log logging no no yes yes
Minimal kmsg-based syslog daemon for embedded use no no yes  ??
Respawning on service crash without losing connectivity no no yes  ??
Gapless service upgrades no no yes  ??
Graphical UI no no yes no.
Built-In Profiling and Tools no no yes yes (shell)
Instantiated services no yes yes yes
PolicyKit integration no no yes no
Remote access/Cluster support built into client tools no no yes no
Can list all processes of a service no no yes yes(cgroup)
Can identify service of a process no no yes  ???
Automatic per-service CPU cgroups to even out CPU usage between them no no yes yes
Automatic per-user cgroups no no yes  ??
SysV compatibility yes yes yes (which part?!)
SysV services controllable like native services yes no yes no
SysV-compatible /dev/initctl yes no yes yes
Reexecution with full serialization of state yes no yes yes
Interactive boot-up no[6] no[6] yes yes
Container support (as advanced chroot() replacement) no no yes yes
Dependency-based bootup no[7] no yes yes
Disabling of services without editing files yes no yes yes
Masking of services without editing files no no yes  ??
Robust system shutdown within PID 1 no no yes no (wrong place)
Built-in kexec support no no yes yes
Dynamic service generation no no yes  ???
Upstream support in various other OS components yes no yes not needed
Service files compatible between distributions no no yes yes
Signal delivery to services no no yes yes
Reliable termination of user sessions before shutdown no no yes no
utmp/wtmp support yes yes yes yes
Easily writable, extensible and parseable service files, suitable for manipulation with enterprise management tools no no yes yes

OpenRC bonus features:

sysvinit Upstart systemd OpenRC
multiple distributions using it yes yes yes yes
portable to non-x86 non-linux yes yes NO YES
parallel service startup mostly-no mostly-no yes yes
per-service resource limits (ulimit) no no  ?? yes
separation of code and configuration (init.d / conf.d ) mostly-yes no no yes
easily extensible startup scripts yes mostly-yes NO yes
friendly upstream yes no NO YES
friendly license (BSD) no no no YES
stateful init scripts (is it started already?) no mostly-no yes yes
complex init scripts to start multiple components (samba -> smbd nmbd, nfs ->) yes yes NO yes
automatic dependency calculation and service ordering no mostly-no mostly-yes yes
minimal dependencies and footprint (CC + posix sh) yes yes NO yes
proper integration into container/virtualization (linux-vserver, openvz, ...) mostly-yes mostly-yes  ??? yes
proper modular architecture and separation of optional components (cron, syslog) yes mostly-yes NO yes
expressive and flexible network handling (including vpn, bridges, ...)  ??  ?? mostly-no yes
support for bare-metal bare-dependency servers yes yes NO yes
verbose debug mode yes yes mostly-no yes

Size and complexity

OpenRC (0.9.3): sysvinit + 300 files, ~30k lines, 3.3k posix sh, ~12k C

Upstart (1.5): 285 files, ~185k lines, ~97k C

Debian: sysvinit + 120 files, 5.8k lines

SystemD (v44+): dbus + glib + 900 files, 224k lines, 125k C

sysvinit: 560kB, 75 files, ~15k lines

DBus: 11MB, ~500 files. 300k lines, 120k C

glib: 72MB, ~2500 files, ~1.7M lines, ~430k C


Debian startup is smallest, it's only shell with sysvinit (C) as dependency

Upstart is about 10 times bigger in terms of lines of code/text. Most of the extra complexity size comes from C.

OpenRC is about twice as big as debian startup. The size difference is mostly the OpenRC core written in C, which expands the footprint from ~3k LoC to ~15k LoC compared to shell.

SystemD is about 10 times bigger, like upstart. But with the mandatory deps it blows up to about one hundred times the code footprint! Most of the extra code is in mandatory dependencies, but the systemd core is also bigger than anything else.

OpenRC Busybox Integration

Busybox can be used replace most of the userspace needed by OpenRC (init, shell, awk and other posix tools), by using a complete busybox as shell for openrc all the calls that normally would cause a fork/exec would be spared, improving the overall speed. The process isn't yet streamlined.

Replacing init

The sysvinit inittab provided by Gentoo is not compatible to the busybox init.

File/etc/inittabExample inittab compatible with busybox init

::sysinit:/sbin/rc sysinit
::wait:/sbin/rc boot
::wait:/sbin/rc

In order to set a specific runlevel from the bootloader the variable `softlevel=` should be used.

busybox specific init.d files

TODO: busybox provides a number of applets that could be used to replace third party software like acpid or dhcp/dhcpcd.

Replacing udev with mdev

See Mdev


Using runlevels

OpenRC can be controlled and configured using rc, rc-update and rc-status.

Named runlevels

OpenRC runlevels are directories living in "/etc/runlevels" to create additional runlevels is enough to issue

root # install -d /etc/runlevels/$runlevel

Stacked runlevels

Is possible manage variants using rc-update -s

Select specific runlevel at boot

Prefix usage

Gentoo Prefix installs Gentoo within an offset, known as a prefix, allowing users to install Gentoo in another location in the filesystem hierarchy, hence avoiding conflicts. Next to this offset, Gentoo Prefix runs unprivileged, meaning no root user or rights are required to use it.

By using an offset (the "prefix" location), it is possible for many "alternative" user groups to benefit from a large part of the packages in the Gentoo Linux Portage tree. Currently users of the following systems successfully run Gentoo Prefix: Mac OS X on PPC and x86, Linux on x86, x86_64 and ia64, Solaris 10 on Sparc, Sparc/64, x86 and x86_64, FreeBSD on x86, AIX on PPC, Interix on x86, Windows on x86 (with the help of Interix), HP-UX on PARISC and ia64.

OpenRC runscript already support prefix-installed daemons, during the SummerOfCode2012 work will be done to implement full secondary/session daemon behaviour to complete the overall featureset provided by Prefix.

OpenRC/Prefix, a tutorial for trying it out.

Other Usages

  • stateful init scripts and automatic respawning (run "rc")
Personal tools
Namespaces

Variants
Actions
Gentoo Websites logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Navigation
Toolbox
Categories