often a shell script - to completion). There are also _bgprocess_ services
and _internal_ services.
-Many programs that you might want to run under dinit's supervision can run
+Many programs that you might want to run under Dinit's supervision can run
either "in the foreground" or as a daemon ("in the background"), and the
choice is dictated by a command line switch (for instance the -D and -F
switches to Samba's "smbd"). Although it might seem counterintuitive,
the "foreground" mode should be used for programs registered as process
-services in dinit; this allows dinit to monitor the process.
+services in Dinit; this allows Dinit to monitor the process.
Process services are attractive due to the ease of monitoring (and
restarting) the service, however, they have one inherent problem, which is
-that dinit cannot tell when the service is truly started. Once the process
-has been launched, dinit assumes that the service has started, but in fact
+that Dinit cannot tell when the service is truly started. Once the process
+has been launched, Dinit assumes that the service has started, but in fact
there will be a short delay before the process sets itself up, starts
listening on sockets, etc; during this time any other process (including
one from a service listed as dependent) which tries to contact it will not
matches the name of the service. Service descriptions are loaded lazily, as
needed by Dinit.
+(An example of a complete set of system service descriptions can be found in
+the [doc/linux/services](doc/linux/services) directory).
+
A service description file consists of a number of parameter settings.
Settings in the SDF are denoted as a parameter name followed by either an
equal sign or colon and then the parameter value (all on the same line).
(although it may then immediately restart, depending on how it and its
dependents are configured).
-Use the "-s" switch to talk the "system" instance of dinit, rather than a
+Use the "-s" switch to talk the "system" instance of Dinit, rather than a
personal instance, e.g:
dinitctl -s start mysql # start system mysql service
## Dinit as init: using Dinit as your Linux system's init
Modern linux is a relatively complex system, these days. You can use Dinit,
-in conjunction with other software, to boot your system and replace your current
-init system (which on most main distributions is now Systemd, Sys V init, or
-OpenRC).
+in conjunction with other software, to boot your system and replace your
+current init system (which on most main distributions is now Systemd, Sys V
+init, or OpenRC).
+
+To have Dinit as your system init, replace your system's `/sbin/init` with a
+link to the `dinit` executable.
+
+*Note*: if your system boots via an "initrd" (initial ramdisk image), you
+might need to either adjust the ramdisk image to include `dinit` or switch
+to mounting the root filesystem directly; consult kernel, bootloader and
+distribution documentation for details.
Be warned that it is not a trivial task to take a system based on a typical
Linux distribution and make it instead boot with Dinit. You need to set up
The additional software required can be broken into _essential_ and
_optional_ packages, which are detailed in following sections. For example service
-files, please check the "services" subdirectory.
+files, please check the `services` subdirectory.
# General notes
order to perform the initial fsck). You must configure your kernel
appropriately for this to happen.
-(actually, it seems that dinit manages output without /dev/console; probably
+(actually, it seems that Dinit manages output without /dev/console; probably
the kernel is giving it appropriate stdin/out/err file descriptors. I'm not
sure if this was the case for older kernels).
Some packages may rely on the "logind" functionality of Systemd for
session/seat management. This same functionality is also provided by
-ConsoleKit2, though I'm not to what degree nor level of compatibility.
+Elogind and ConsoleKit2, though I'm not to what degree nor level of
+compatibility.
In general I've found it quite possible to run a desktop system with Dinit
in place of SystemD, but my needs are minimal. If you're running a
- start other daemons as appropriate (dhcpcd, any networking daemons)
- start getty instances virtual terminals
-The service description files and scrips in the "services" subdirectory
+The service description files and scripts in the `services` subdirectory
provide a template for accomplishing the above, but may need some adjustment
for your particular configuration.
# Boot performance compared to Systemd
-Boot performance using Dinit suffers slightly compared to Systemd due to
-several factors:
+Boot performance using Dinit _theoretically_ suffers slightly compared to
+Systemd due to several factors:
- Dinit doesn't handle file system mounts/checks and spawns external
processes and/or scripts to manage these
recognized before they are configured. With Dinit, the simplest approach
is to wait until udev "settles" (via "udevadm settle") before attempting
mounts and network configuration etc.
-- Dinit doesn't do socket activation (yet). What it can do is pre-open a
+- Dinit doesn't do full socket activation (yet). What it can do is pre-open a
socket while it launches a daemon, which probably improves boot times a
little but potentially still results in more daemons getting started than
is strictly necessary.
projects / oweals / dinit.git / commitdiff