X-Git-Url: http://www.chiark.greenend.org.uk/ucgi/~ianmdlvl/git?p=elogind.git;a=blobdiff_plain;f=man%2Fsystemd.xml;h=4f4a588a98e677e306dbe4313c19d3abb2b618a5;hp=36bce961854705331e4383b7b77fc4b1b5fcc848;hb=ad678a066b4ba5d8914dd7d5a4093572841205cf;hpb=7874bcd6028d1efbb4451c8b5cf5b2ac8d77af74 diff --git a/man/systemd.xml b/man/systemd.xml index 36bce9618..4f4a588a9 100644 --- a/man/systemd.xml +++ b/man/systemd.xml @@ -44,6 +44,7 @@ systemd + init systemd System and Session Manager @@ -61,17 +62,24 @@ systemd is a system and session manager for Linux operating systems. When run as first process on - boot (as PID 1) it may act as init system that brings - up and maintains userspace. + boot (as PID 1), it acts as init system that brings + up and maintains userspace services. - For compatibility with SysV if systemd is called + For compatibility with SysV, if systemd is called as init and a PID that is not - 1 it will execute telinit and pass + 1, it will execute telinit and pass all command line arguments unmodified. That means init and telinit are mostly equivalent when invoked from normal login sessions. See telinit8 for more information. + + When run as system instance, systemd interprets + the configuration file + system.conf, otherwise + session.conf. See + systemd.conf5 + for more information. @@ -87,6 +95,37 @@ Prints a short help text and exits. + + + + Determine startup + sequence, dump it and exit. This is an + option useful for debugging + only. + + + + + Dump understood unit + configuration items. This outputs a + terse but complete list of + configuration items understood in unit + definition files. + + + + + Extract D-Bus + interface introspection data. This is + mostly useful at install time + to generate data suitable for the + D-Bus interfaces + repository. Optionally the interface + name for the introspection data may be + specified. If omitted, the + introspection data for all interfaces + is dumped. + @@ -110,40 +149,35 @@ debugging. - + - Determine startup - sequence, dump it and exit. This is an - option useful for debugging - only. + Dump core on crash. This switch has no effect when run as session instance. - + - Dump understood unit - configuration items. This outputs a - terse but complete list of - configuration items understood in unit - definition files. + Run shell on crash. This switch has no effect when run as session instance. - Ask for confirmation when spawning processes. + Ask for confirmation when spawning processes. This switch has no effect when run as session instance. - + - Extract D-Bus - interface introspection data. This is - mostly useful at build ot install time - to generate data suitable for the - D-Bus interfaces - repository. Optionally the interface - name for the introspection data may be - specified. If omitted the - introspection data for all interfaces - is dumped. + Show terse service status information while booting. This switch has no effect when run as session instance. + + + + + Set log + target. Argument must be one of + , + , + , + , + . @@ -161,17 +195,6 @@ , . - - - - Set log - target. Argument must be one of - , - , - , - , - . - @@ -195,6 +218,170 @@ + + Concepts + + systemd provides a dependency system between + various entities called "units". Units encapsulate + various objects that are relevant for system boot-up + and maintainance. The majority of units are configured + in unit configuration files, whose syntax and basic + set of options is described in + systemd.unit5, + however some are created automatically from other + configuration or dynamically from system state. Units + may be active (meaning started, bound, plugged in, ... + depending on the unit type), or inactive (meaning + stopped, unbound, unplugged, ...), as well is in the + process of being activated or deactivated, + i.e. between the two states. The following unit types + are available: + + + Service units, which control + daemons and the processes they consist of. For + details see + systemd.service5. + + Socket units, which + encapsulate local IPC or network sockets in + the system, useful for socket-based + activation. For details about socket units see + systemd.socket5, + for details on socket-based activation and + other forms of activation, see + daemon7. + + Target units are useful to + group units, or provide well-known + synchronization points during boot-up, see + systemd.target5. + + Device units expose kernel + devices in systemd and may be used to + implement device-based activation. For details + see + systemd.device5. + + Mount units control mount + points in the file system, for details see + systemd.mount5. + + Automount units provide + automount capabilities, for on-demand mounting + of file systems as well as parallelized + boot-up. See + systemd.automount5. + + Snapshot units can be used to + temporarily save the state of the set of + systemd units, which later may be restored by + activating the saved snapshot unit. For more + information see + systemd.automount5. + + Timer units are useful for + triggering activation of other units based on + timers. You may find details in + systemd.timer5. + + Swap units are very similar to + mount units and encapsulated memory swap + partitions or files of the operating + systemd. They are described in systemd.swap5. + + Path units may be used + activate other services when file system + objects change or are modified. See + systemd.path5. + + + + Units are named as their configuration + files. Some units have special semantics. A detailed + list you may find in + systemd.special7. + + On boot systemd activates the target unit + default.target whose job it is to + activate on-boot services and other on-boot units by + pulling them in via dependencies. Usually the unit + name is just an alias (symlink) for either + graphical.target (for + fully-featured boots into the UI) or + multi-user.target (for limited + console-only boots for use in embedded or server + environments, or similar; a subset of + graphical.target). However it is at the discretion of + the administrator to configure it as an alias to any + other target unit. See + 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 + Design Document. + + Directories @@ -219,8 +406,8 @@ --variable=systemdsystemconfdir returns the path of the system configuration directory. Packages - should alter this directory only with - the + should alter the content of these directories + only with the systemd-install1 tool. @@ -260,7 +447,7 @@ SysV init script directory varies between distributions. If systemd cannot find a native unit file for a - requested service it will look for a + requested service, it will look for a SysV init script of the same name (with the .service suffix @@ -458,7 +645,7 @@ $SYSTEMD_LOG_LEVEL systemd reads the log level from this environment - variable. This can be overriden with + variable. This can be overridden with . @@ -466,7 +653,7 @@ $SYSTEMD_LOG_TARGET systemd reads the log target from this environment - variable. This can be overriden with + variable. This can be overridden with . @@ -474,7 +661,7 @@ $SYSTEMD_LOG_COLOR Controls whether systemd highlights important log - messages. This can be overriden with + messages. This can be overridden with . @@ -483,7 +670,7 @@ Controls whether systemd prints the code location along with log messages. This can be - overriden with + overridden with . @@ -549,6 +736,87 @@ + + Kernel Command Line + + When run as system instance systemd parses a few kernel command line arguments: + + + + systemd.unit= + + Overrides the unit to + activate on boot. Defaults to + default.target. This + may be used to temporarily boot into a + different boot unit, for example + rescue.target or + emergency.service. See + systemd.special7 + for details about these + units. + + + + systemd.log_target= + systemd.log_level= + systemd.log_color= + systemd.log_location= + + Controls log output, + with the same effect as the + $SYSTEMD_LOG_TARGET, $SYSTEMD_LOG_LEVEL, $SYSTEMD_LOG_COLOR, $SYSTEMD_LOG_LOCATION + environment variables described above. + + + + systemd.dump_core= + + Takes a boolean + argument. If + systemd dumps core when it + crashes. Otherwise no core dump is + created. Defaults to + . + + + + systemd.crash_shell= + + Takes a boolean + argument. If + systemd spawns a shell when it + crashes. Otherwise no core dump is + created. Defaults to + , for security + reasons, as the shell is not protected + by any password + authentication. + + + + systemd.crash_chvt= + + Takes an integer + argument. If positive systemd + activates the specified virtual + terminal when it crashes. Defaults to + -1. + + + + systemd.show_status= + + Takes a boolean + argument. If + shows terse service status updates on + the console during bootup. Defaults to + . + + + + + Sockets and FIFOs