diff --git a/man/systemd.service.xml b/man/systemd.service.xml
index 91d6d09409..008ebd752e 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 007705e494..b4a7e3ec93 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.