1SYSTEMD(1)                          systemd                         SYSTEMD(1)
2
3
4

NAME

6       systemd, init - systemd system and service manager
7

SYNOPSIS

9       systemd [OPTIONS...]
10
11       init [OPTIONS...] {COMMAND}
12

DESCRIPTION

14       systemd is a system and service manager for Linux operating systems.
15       When run as first process on boot (as PID 1), it acts as init system
16       that brings up and maintains userspace services.
17
18       For compatibility with SysV, if systemd is called as init and a PID
19       that is not 1, it will execute telinit and pass all command line
20       arguments unmodified. That means init and telinit are mostly equivalent
21       when invoked from normal login sessions. See telinit(8) for more
22       information.
23
24       When run as a system instance, systemd interprets the configuration
25       file system.conf and the files in system.conf.d directories. See
26       systemd-system.conf(5) for more information.
27

OPTIONS

29       The following options are understood:
30
31       --test
32           Determine startup sequence, dump it and exit. This is an option
33           useful for debugging only.
34
35       --dump-configuration-items
36           Dump understood unit configuration items. This outputs a terse but
37           complete list of configuration items understood in unit definition
38           files.
39
40       --unit=
41           Set default unit to activate on startup. If not specified, defaults
42           to default.target.
43
44       --system
45           --system, tell systemd to run a system instance, even if the
46           process ID is not 1, i.e. systemd is not run as init process.
47           Normally it should not be necessary to pass this options, as
48           systemd automatically detects the mode it is started in. This
49           option is hence of little use except for debugging. Note that it is
50           not supported booting and maintaining a full system with systemd
51           running in --system mode, but PID not 1. In practice, passing
52           --system explicitly is only useful in conjunction with --test.
53
54       --dump-core
55           Dump core on crash.
56
57       --crash-shell
58           Run shell on crash.
59
60       --confirm-spawn
61           Ask for confirmation when spawning processes.
62
63       --show-status=
64           Show terse service status information while booting. Takes a
65           boolean argument which may be omitted which is interpreted as true.
66
67       --log-target=
68           Set log target. Argument must be one of console, journal, kmsg,
69           journal-or-kmsg, null.
70
71       --log-level=
72           Set log level. As argument this accepts a numerical log level or
73           the well-known syslog(3) symbolic names (lowercase): emerg, alert,
74           crit, err, warning, notice, info, debug.
75
76       --log-color=
77           Highlight important log messages. Argument is a boolean value. If
78           the argument is omitted, it defaults to true.
79
80       --log-location=
81           Include code location in log messages. This is mostly relevant for
82           debugging purposes. Argument is a boolean value. If the argument is
83           omitted it defaults to true.
84
85       --default-standard-output=, --default-standard-error=
86           Sets the default output or error output for all services and
87           sockets, respectively. That is, controls the default for
88           StandardOutput= and StandardError= (see systemd.exec(5) for
89           details). Takes one of inherit, null, tty, journal,
90           journal+console, syslog, syslog+console, kmsg, kmsg+console. If the
91           argument is omitted --default-standard-output= defaults to journal
92           and --default-standard-error= to inherit.
93
94       -h, --help
95           Print a short help text and exit.
96
97       --version
98           Print a short version string and exit.
99

CONCEPTS

101       systemd provides a dependency system between various entities called
102       "units" of 12 different types. Units encapsulate various objects that
103       are relevant for system boot-up and maintenance. The majority of units
104       are configured in unit configuration files, whose syntax and basic set
105       of options is described in systemd.unit(5), however some are created
106       automatically from other configuration, dynamically from system state
107       or programmatically at runtime. Units may be "active" (meaning started,
108       bound, plugged in, ..., depending on the unit type, see below), or
109       "inactive" (meaning stopped, unbound, unplugged, ...), as well as in
110       the process of being activated or deactivated, i.e. between the two
111       states (these states are called "activating", "deactivating"). A
112       special "failed" state is available as well, which is very similar to
113       "inactive" and is entered when the service failed in some way (process
114       returned error code on exit, or crashed, or an operation timed out). If
115       this state is entered, the cause will be logged, for later reference.
116       Note that the various unit types may have a number of additional
117       substates, which are mapped to the five generalized unit states
118       described here.
119
120       The following unit types are available:
121
122        1. Service units, which start and control daemons and the processes
123           they consist of. For details see systemd.service(5).
124
125        2. Socket units, which encapsulate local IPC or network sockets in the
126           system, useful for socket-based activation. For details about
127           socket units see systemd.socket(5), for details on socket-based
128           activation and other forms of activation, see daemon(7).
129
130        3. Target units are useful to group units, or provide well-known
131           synchronization points during boot-up, see systemd.target(5).
132
133        4. Device units expose kernel devices in systemd and may be used to
134           implement device-based activation. For details see
135           systemd.device(5).
136
137        5. Mount units control mount points in the file system, for details
138           see systemd.mount(5).
139
140        6. Automount units provide automount capabilities, for on-demand
141           mounting of file systems as well as parallelized boot-up. See
142           systemd.automount(5).
143
144        7. Snapshot units can be used to temporarily save the state of the set
145           of systemd units, which later may be restored by activating the
146           saved snapshot unit. For more information see systemd.snapshot(5).
147
148        8. Timer units are useful for triggering activation of other units
149           based on timers. You may find details in systemd.timer(5).
150
151        9. Swap units are very similar to mount units and encapsulate memory
152           swap partitions or files of the operating system. They are
153           described in systemd.swap(5).
154
155       10. Path units may be used to activate other services when file system
156           objects change or are modified. See systemd.path(5).
157
158       11. Slice units may be used to group units which manage system
159           processes (such as service and scope units) in a hierarchical tree
160           for resource management purposes. See systemd.slice(5).
161
162       12. Scope units are similar to service units, but manage foreign
163           processes instead of starting them as well. See systemd.scope(5).
164
165       Units are named as their configuration files. Some units have special
166       semantics. A detailed list is available in systemd.special(7).
167
168       systemd knows various kinds of dependencies, including positive and
169       negative requirement dependencies (i.e.  Requires= and Conflicts=) as
170       well as ordering dependencies (After= and Before=). NB: ordering and
171       requirement dependencies are orthogonal. If only a requirement
172       dependency exists between two units (e.g.  foo.service requires
173       bar.service), but no ordering dependency (e.g.  foo.service after
174       bar.service) and both are requested to start, they will be started in
175       parallel. It is a common pattern that both requirement and ordering
176       dependencies are placed between two units. Also note that the majority
177       of dependencies are implicitly created and maintained by systemd. In
178       most cases, it should be unnecessary to declare additional dependencies
179       manually, however it is possible to do this.
180
181       Application programs and units (via dependencies) may request state
182       changes of units. In systemd, these requests are encapsulated as 'jobs'
183       and maintained in a job queue. Jobs may succeed or can fail, their
184       execution is ordered based on the ordering dependencies of the units
185       they have been scheduled for.
186
187       On boot systemd activates the target unit default.target whose job is
188       to activate on-boot services and other on-boot units by pulling them in
189       via dependencies. Usually the unit name is just an alias (symlink) for
190       either graphical.target (for fully-featured boots into the UI) or
191       multi-user.target (for limited console-only boots for use in embedded
192       or server environments, or similar; a subset of graphical.target).
193       However, it is at the discretion of the administrator to configure it
194       as an alias to any other target unit. See systemd.special(7) for
195       details about these target units.
196
197       Processes systemd spawns are placed in individual Linux control groups
198       named after the unit which they belong to in the private systemd
199       hierarchy. (see cgroups.txt[1] for more information about control
200       groups, or short "cgroups"). systemd uses this to effectively keep
201       track of processes. Control group information is maintained in the
202       kernel, and is accessible via the file system hierarchy (beneath
203       /sys/fs/cgroup/systemd/), or in tools such as ps(1) (ps xawf -eo
204       pid,user,cgroup,args is particularly useful to list all processes and
205       the systemd units they belong to.).
206
207       systemd is compatible with the SysV init system to a large degree: SysV
208       init scripts are supported and simply read as an alternative (though
209       limited) configuration file format. The SysV /dev/initctl interface is
210       provided, and compatibility implementations of the various SysV client
211       tools are available. In addition to that, various established Unix
212       functionality such as /etc/fstab or the utmp database are supported.
213
214       systemd has a minimal transaction system: if a unit is requested to
215       start up or shut down it will add it and all its dependencies to a
216       temporary transaction. Then, it will verify if the transaction is
217       consistent (i.e. whether the ordering of all units is cycle-free). If
218       it is not, systemd will try to fix it up, and removes non-essential
219       jobs from the transaction that might remove the loop. Also, systemd
220       tries to suppress non-essential jobs in the transaction that would stop
221       a running service. Finally it is checked whether the jobs of the
222       transaction contradict jobs that have already been queued, and
223       optionally the transaction is aborted then. If all worked out and the
224       transaction is consistent and minimized in its impact it is merged with
225       all already outstanding jobs and added to the run queue. Effectively
226       this means that before executing a requested operation, systemd will
227       verify that it makes sense, fixing it if possible, and only failing if
228       it really cannot work.
229
230       Systemd contains native implementations of various tasks that need to
231       be executed as part of the boot process. For example, it sets the
232       hostname or configures the loopback network device. It also sets up and
233       mounts various API file systems, such as /sys or /proc.
234
235       For more information about the concepts and ideas behind systemd,
236       please refer to the Original Design Document[2].
237
238       Note that some but not all interfaces provided by systemd are covered
239       by the Interface Stability Promise[3].
240
241       Units may be generated dynamically at boot and system manager reload
242       time, for example based on other configuration files or parameters
243       passed on the kernel command line. For details see
244       systemd.generator(7).
245
246       Systems which invoke systemd in a container or initrd environment
247       should implement the Container Interface[4] or initrd Interface[5]
248       specifications, respectively.
249

DIRECTORIES

251       System unit directories
252           The systemd system manager reads unit configuration from various
253           directories. Packages that want to install unit files shall place
254           them in the directory returned by pkg-config systemd
255           --variable=systemdsystemunitdir. Other directories checked are
256           /usr/local/lib/systemd/system and /usr/lib/systemd/system. User
257           configuration always takes precedence.  pkg-config systemd
258           --variable=systemdsystemconfdir returns the path of the system
259           configuration directory. Packages should alter the content of these
260           directories only with the enable and disable commands of the
261           systemctl(1) tool. Full list of directories is provided in
262           systemd.unit(5).
263
264       SysV init scripts directory
265           The location of the SysV init script directory varies between
266           distributions. If systemd cannot find a native unit file for a
267           requested service, it will look for a SysV init script of the same
268           name (with the .service suffix removed).
269
270       SysV runlevel link farm directory
271           The location of the SysV runlevel link farm directory varies
272           between distributions. systemd will take the link farm into account
273           when figuring out whether a service shall be enabled. Note that a
274           service unit with a native unit configuration file cannot be
275           started by activating it in the SysV runlevel link farm.
276

SIGNALS

278       SIGTERM
279           Upon receiving this signal the systemd system manager serializes
280           its state, reexecutes itself and deserializes the saved state
281           again. This is mostly equivalent to systemctl daemon-reexec.
282
283       SIGINT
284           Upon receiving this signal the systemd system manager will start
285           the ctrl-alt-del.target unit. This is mostly equivalent to
286           systemctl start ctl-alt-del.target. If this signal is received more
287           often than 7 times per 2s an immediate reboot is triggered. Note
288           that pressing Ctrl-Alt-Del on the console will trigger this signal.
289           Hence, if a reboot is hanging pressing Ctrl-Alt-Del more than 7
290           times in 2s is a relatively safe way to trigger an immediate
291           reboot.
292
293           systemd user managers treat this signal the same way as SIGTERM.
294
295       SIGWINCH
296           When this signal is received the systemd system manager will start
297           the kbrequest.target unit. This is mostly equivalent to systemctl
298           start kbrequest.target.
299
300           This signal is ignored by systemd user managers.
301
302       SIGPWR
303           When this signal is received the systemd manager will start the
304           sigpwr.target unit. This is mostly equivalent to systemctl start
305           sigpwr.target.
306
307       SIGUSR1
308           When this signal is received the systemd manager will try to
309           reconnect to the D-Bus bus.
310
311       SIGUSR2
312           When this signal is received the systemd manager will log its
313           complete state in human readable form. The data logged is the same
314           as printed by systemd-analyze dump.
315
316       SIGHUP
317           Reloads the complete daemon configuration. This is mostly
318           equivalent to systemctl daemon-reload.
319
320       SIGRTMIN+0
321           Enters default mode, starts the default.target unit. This is mostly
322           equivalent to systemctl start default.target.
323
324       SIGRTMIN+1
325           Enters rescue mode, starts the rescue.target unit. This is mostly
326           equivalent to systemctl isolate rescue.target.
327
328       SIGRTMIN+2
329           Enters emergency mode, starts the emergency.service unit. This is
330           mostly equivalent to systemctl isolate emergency.service.
331
332       SIGRTMIN+3
333           Halts the machine, starts the halt.target unit. This is mostly
334           equivalent to systemctl start halt.target.
335
336       SIGRTMIN+4
337           Powers off the machine, starts the poweroff.target unit. This is
338           mostly equivalent to systemctl start poweroff.target.
339
340       SIGRTMIN+5
341           Reboots the machine, starts the reboot.target unit. This is mostly
342           equivalent to systemctl start reboot.target.
343
344       SIGRTMIN+6
345           Reboots the machine via kexec, starts the kexec.target unit. This
346           is mostly equivalent to systemctl start kexec.target.
347
348       SIGRTMIN+13
349           Immediately halts the machine.
350
351       SIGRTMIN+14
352           Immediately powers off the machine.
353
354       SIGRTMIN+15
355           Immediately reboots the machine.
356
357       SIGRTMIN+16
358           Immediately reboots the machine with kexec.
359
360       SIGRTMIN+20
361           Enables display of status messages on the console, as controlled
362           via systemd.show_status=1 on the kernel command line.
363
364       SIGRTMIN+21
365           Disables display of status messages on the console, as controlled
366           via systemd.show_status=0 on the kernel command line.
367
368       SIGRTMIN+22, SIGRTMIN+23
369           Sets the log level to "debug" (or "info" on SIGRTMIN+23), as
370           controlled via systemd.log_level=debug (or systemd.log_level=info
371           on SIGRTMIN+23) on the kernel command line.
372
373       SIGRTMIN+26, SIGRTMIN+27, SIGRTMIN+28
374           Sets the log level to "journal-or-kmsg" (or "console" on
375           SIGRTMIN+27, "kmsg" on SIGRTMIN+28), as controlled via
376           systemd.log_target=journal-or-kmsg (or systemd.log_target=console
377           on SIGRTMIN+27 or systemd.log_target=kmsg on SIGRTMIN+28) on the
378           kernel command line.
379

ENVIRONMENT

381       $SYSTEMD_LOG_LEVEL
382           systemd reads the log level from this environment variable. This
383           can be overridden with --log-level=.
384
385       $SYSTEMD_LOG_TARGET
386           systemd reads the log target from this environment variable. This
387           can be overridden with --log-target=.
388
389       $SYSTEMD_LOG_COLOR
390           Controls whether systemd highlights important log messages. This
391           can be overridden with --log-color=.
392
393       $SYSTEMD_LOG_LOCATION
394           Controls whether systemd prints the code location along with log
395           messages. This can be overridden with --log-location=.
396
397       $XDG_CONFIG_HOME, $XDG_CONFIG_DIRS, $XDG_DATA_HOME, $XDG_DATA_DIRS
398           The systemd user manager uses these variables in accordance to the
399           XDG Base Directory specification[6] to find its configuration.
400
401       $SYSTEMD_UNIT_PATH
402           Controls where systemd looks for unit files.
403
404       $SYSTEMD_SYSVINIT_PATH
405           Controls where systemd looks for SysV init scripts.
406
407       $SYSTEMD_SYSVRCND_PATH
408           Controls where systemd looks for SysV init script runlevel link
409           farms.
410
411       $SYSTEMD_COLORS
412           Controls whether colorized output should be generated.
413
414       $LISTEN_PID, $LISTEN_FDS
415           Set by systemd for supervised processes during socket-based
416           activation. See sd_listen_fds(3) for more information.
417
418       $NOTIFY_SOCKET
419           Set by systemd for supervised processes for status and start-up
420           completion notification. See sd_notify(3) for more information.
421

KERNEL COMMAND LINE

423       When run as system instance systemd parses a number of kernel command
424       line arguments[7]:
425
426       systemd.unit=, rd.systemd.unit=
427           Overrides the unit to activate on boot. Defaults to default.target.
428           This may be used to temporarily boot into a different boot unit,
429           for example rescue.target or emergency.service. See
430           systemd.special(7) for details about these units. The option
431           prefixed with "rd."  is honored only in the initial RAM disk
432           (initrd), while the one that is not prefixed only in the main
433           system.
434
435       systemd.dump_core=
436           Takes a boolean argument. If true, systemd dumps core when it
437           crashes. Otherwise, no core dump is created. Defaults to true.
438
439       systemd.crash_shell=
440           Takes a boolean argument. If true, systemd spawns a shell when it
441           crashes. Otherwise, no shell is spawned. Defaults to false, for
442           security reasons, as the shell is not protected by any password
443           authentication.
444
445       systemd.crash_chvt=
446           Takes an integer argument. If positive systemd activates the
447           specified virtual terminal when it crashes. Defaults to -1.
448
449       systemd.confirm_spawn=
450           Takes a boolean argument. If true, asks for confirmation when
451           spawning processes. Defaults to false.
452
453       systemd.show_status=
454           Takes a boolean argument or the constant auto. If true, shows terse
455           service status updates on the console during bootup.  auto behaves
456           like false until a service fails or there is a significant delay in
457           boot. Defaults to true, unless quiet is passed as kernel command
458           line option in which case it defaults to auto.
459
460       systemd.log_target=, systemd.log_level=, systemd.log_color=,
461       systemd.log_location=
462           Controls log output, with the same effect as the
463           $SYSTEMD_LOG_TARGET, $SYSTEMD_LOG_LEVEL, $SYSTEMD_LOG_COLOR,
464           $SYSTEMD_LOG_LOCATION environment variables described above.
465
466       systemd.default_standard_output=, systemd.default_standard_error=
467           Controls default standard output and error output for services,
468           with the same effect as the --default-standard-output= and
469           --default-standard-error= command line arguments described above,
470           respectively.
471
472       systemd.setenv=
473           Takes a string argument in the form VARIABLE=VALUE. May be used to
474           set default environment variables to add to forked child processes.
475           May be used more than once to set multiple variables.
476
477       quiet
478           Turn off status output at boot, much like systemd.show_status=false
479           would. Note that this option is also read by the kernel itself and
480           disables kernel log output. Passing this option hence turns off the
481           usual output from both the system manager and the kernel.
482
483       debug
484           Turn on debugging output. This is equivalent to
485           systemd.log_level=debug. Note that this option is also read by the
486           kernel itself and enables kernel debug output. Passing this option
487           hence turns on the debug output from both the system manager and
488           the kernel.
489
490       emergency, -b
491           Boot into emergency mode. This is equivalent to
492           systemd.unit=emergency.target and provided for compatibility
493           reasons and to be easier to type.
494
495       rescue, single, s, S, 1
496           Boot into rescue mode. This is equivalent to
497           systemd.unit=rescue.target and provided for compatibility reasons
498           and to be easier to type.
499
500       2, 3, 4, 5
501           Boot into the specified legacy SysV runlevel. These are equivalent
502           to systemd.unit=runlevel2.target, systemd.unit=runlevel3.target,
503           systemd.unit=runlevel4.target, and systemd.unit=runlevel5.target,
504           respectively, and provided for compatibility reasons and to be
505           easier to type.
506
507       locale.LANG=, locale.LANGUAGE=, locale.LC_CTYPE=, locale.LC_NUMERIC=,
508       locale.LC_TIME=, locale.LC_COLLATE=, locale.LC_MONETARY=,
509       locale.LC_MESSAGES=, locale.LC_PAPER=, locale.LC_NAME=,
510       locale.LC_ADDRESS=, locale.LC_TELEPHONE=, locale.LC_MEASUREMENT=,
511       locale.LC_IDENTIFICATION=
512           Set the system locale to use. This overrides the settings in
513           /etc/locale.conf. For more information see locale.conf(5) and
514           locale(7).
515
516       For other kernel command line parameters understood by components of
517       the core OS, please refer to kernel-command-line(7).
518

SOCKETS AND FIFOS

520       /run/systemd/notify
521           Daemon status notification socket. This is an AF_UNIX datagram
522           socket and is used to implement the daemon notification logic as
523           implemented by sd_notify(3).
524
525       /run/systemd/shutdownd
526           Used internally by the shutdown(8) tool to implement delayed
527           shutdowns. This is an AF_UNIX datagram socket.
528
529       /run/systemd/private
530           Used internally as communication channel between systemctl(1) and
531           the systemd process. This is an AF_UNIX stream socket. This
532           interface is private to systemd and should not be used in external
533           projects.
534
535       /dev/initctl
536           Limited compatibility support for the SysV client interface, as
537           implemented by the systemd-initctl.service unit. This is a named
538           pipe in the file system. This interface is obsolete and should not
539           be used in new applications.
540

SEE ALSO

542       The systemd Homepage[8], systemd-system.conf(5), locale.conf(5),
543       systemctl(1), journalctl(1), systemd-notify(1), daemon(7), sd-
544       daemon(3), systemd.unit(5), systemd.special(5), pkg-config(1), kernel-
545       command-line(7), bootup(7), systemd.directives(7)
546

NOTES

548        1. cgroups.txt
549           https://www.kernel.org/doc/Documentation/cgroups/cgroups.txt
550
551        2. Original Design Document
552           http://0pointer.de/blog/projects/systemd.html
553
554        3. Interface Stability Promise
555           http://www.freedesktop.org/wiki/Software/systemd/InterfaceStabilityPromise
556
557        4. Container Interface
558           http://www.freedesktop.org/wiki/Software/systemd/ContainerInterface
559
560        5. initrd Interface
561           http://www.freedesktop.org/wiki/Software/systemd/InitrdInterface
562
563        6. XDG Base Directory specification
564           http://standards.freedesktop.org/basedir-spec/basedir-spec-latest.html
565
566        7. If run inside a Linux container these arguments may be passed as
567           command line arguments to systemd itself, next to any of the
568           command line options listed in the Options section above. If run
569           outside of Linux containers, these arguments are parsed from
570           /proc/cmdline instead.
571
572        8. systemd Homepage
573           http://www.freedesktop.org/wiki/Software/systemd/
574
575
576
577systemd 219                                                         SYSTEMD(1)
Impressum