From a3ac47cb32b9fd6bfad75c2adf3e01bb495c1ff7 Mon Sep 17 00:00:00 2001 From: Davin McCall Date: Thu, 13 Sep 2018 13:42:10 +0100 Subject: [PATCH] Minor documentation updates. --- README.md | 13 ++++++++----- doc/linux/DINIT-AS-INIT.md | 29 +++++++++++++++++++---------- 2 files changed, 27 insertions(+), 15 deletions(-) diff --git a/README.md b/README.md index 379a555..6c295dc 100644 --- a/README.md +++ b/README.md @@ -62,17 +62,17 @@ and a _scripted_ service (which is started and stopped by running a process - 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 @@ -110,6 +110,9 @@ reside in a directory (/etc/dinit.d is the default "system" location, with 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). @@ -281,7 +284,7 @@ command by default acts as a "release" which also forces the service to stop (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 diff --git a/doc/linux/DINIT-AS-INIT.md b/doc/linux/DINIT-AS-INIT.md index 03717e3..8d047d1 100644 --- a/doc/linux/DINIT-AS-INIT.md +++ b/doc/linux/DINIT-AS-INIT.md @@ -1,9 +1,17 @@ ## 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 @@ -13,7 +21,7 @@ scripts from other systems. 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 @@ -26,7 +34,7 @@ as the block device used for the root mount, which must be available in 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). @@ -58,7 +66,8 @@ functionality, although at the cost of the losing automated integration. 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 @@ -79,15 +88,15 @@ The basic procedure for boot (to be implemented by services) is as follows: - 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 @@ -98,7 +107,7 @@ several factors: 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. -- 2.25.1