From 59a3e1bc46819d69df6353a86aa0e796cd821024 Mon Sep 17 00:00:00 2001 From: Lennart Poettering Date: Tue, 6 Jul 2010 03:46:31 +0200 Subject: [PATCH] man: more blurbs --- man/systemd.service.xml | 8 ++++++ man/systemd.xml | 60 ++++++++++++++++++++++++++++++++++++++++- 2 files changed, 67 insertions(+), 1 deletion(-) diff --git a/man/systemd.service.xml b/man/systemd.service.xml index 91d6d094..008ebd75 100644 --- a/man/systemd.service.xml +++ b/man/systemd.service.xml @@ -88,6 +88,14 @@ system shutdown. Only services involved with early boot or late system shutdown should disable this option. + + If a service is requested under a certain name + but no unit configuration file is found, systemd looks + for a SysV init script by the same name (with the + .service suffix removed) and + dynamically creates a service unit from that + script. This is useful for compatibility with + SysV. diff --git a/man/systemd.xml b/man/systemd.xml index 007705e4..b4a7e3ec 100644 --- a/man/systemd.xml +++ b/man/systemd.xml @@ -296,10 +296,68 @@ systemd.special7 for details about these target units. + Processes systemd spawns ared placed in + individual Linux control groups named after the unit + which they belong to in the private systemd + hierarchy. (see cgroups.txt + for more information about control groups, or short + "cgroups"). systemd uses this to effectively keep + track of processes. Control group information is + maintained in the kernel, and is accessible via the + file system hierarchy (beneath + /cgroup/systemd/), or in tools + such as + ps1 + (ps xawf -eo pid,user,cgroup,args + is particularly useful to list all processes and the + systemd units they belong to.). + + systemd is compatible with the SysV init system + to a large degree: SysV init scripts are supported and + simply read as an alternative (though limited) + configuration file format. The SysV + /dev/initctl interface is + provided, and comaptibility implementations of the + various SysV client tools available. In addition to + that various established Unix functionality such as + /etc/fstab or the + utmp database are + supported. + + systemd has a minimal transaction system: if a + unit is requested to start up or shut down it will add + it and all its dependencies to a temporary + transaction. Then, it will verify if the transaction + is consistent (i.e. whether the ordering of all units + is cycle-free). If it is not, systemd will try to fix + it up, and removes non-essential jobs from the + transaction that might remove the loop. Also, systemd + tries to suppress non-essential jobs in the + transaction that would stop a running service. Finally + it is checked whether the jobs of the transaction + contradict jobs that have already been queued, and + optionally the transaction is aborted then. If all + worked out and the transaction is consistent and + minimized in its impact it is merged with all already + outstanding jobs and added to the run + queue. Effectively this means that before executing a + requested operation, systemd will verify that it makes + sense, fixing it if possible, and only failing if it + really cannot work. + + Systemd contains native implementations of + various tasks that need to be executed as part of the + boot process. For example, it sets the host name or + configures the loopback network device. It also sets + up and mounts various API file systems, such as + /sys or + /proc. + For more information about the concepts and ideas behind systemd please refer to the Original - Announcement Document. + Design Document. -- 2.39.5