From: Lennart Poettering Date: Tue, 6 Jul 2010 01:46:31 +0000 (+0200) Subject: man: more blurbs X-Git-Tag: v1~28 X-Git-Url: https://www.chiark.greenend.org.uk/ucgi/~ianmdlvl/git?p=elogind.git;a=commitdiff_plain;h=59a3e1bc46819d69df6353a86aa0e796cd821024;hp=99ffae46d38f05b6c8bc09fe29e50a507ae8b79b man: more blurbs --- diff --git a/man/systemd.service.xml b/man/systemd.service.xml index 91d6d0940..008ebd752 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 007705e49..b4a7e3ec9 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.