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

NAME

6       systemd, init - systemd system and service manager
7

SYNOPSIS

9       /usr/lib/systemd/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. Separate instances are
17       started for logged-in users to start their services.
18
19       systemd is usually not invoked directly by the user, but is installed
20       as the /sbin/init symlink and started during early boot. The user
21       manager instances are started automatically through the
22       user@.service(5) service.
23
24       For compatibility with SysV, if the binary is called as init and is not
25       the first process on the machine (PID is not 1), it will execute
26       telinit and pass all command line arguments unmodified. That means init
27       and telinit are mostly equivalent when invoked from normal login
28       sessions. See telinit(8) for more information.
29
30       When run as a system instance, systemd interprets the configuration
31       file system.conf and the files in system.conf.d directories; when run
32       as a user instance, systemd interprets the configuration file user.conf
33       and the files in user.conf.d directories. See systemd-system.conf(5)
34       for more information.
35

CONCEPTS

37       systemd provides a dependency system between various entities called
38       "units" of 11 different types. Units encapsulate various objects that
39       are relevant for system boot-up and maintenance. The majority of units
40       are configured in unit configuration files, whose syntax and basic set
41       of options is described in systemd.unit(5), however some are created
42       automatically from other configuration, dynamically from system state
43       or programmatically at runtime. Units may be "active" (meaning started,
44       bound, plugged in, ..., depending on the unit type, see below), or
45       "inactive" (meaning stopped, unbound, unplugged, ...), as well as in
46       the process of being activated or deactivated, i.e. between the two
47       states (these states are called "activating", "deactivating"). A
48       special "failed" state is available as well, which is very similar to
49       "inactive" and is entered when the service failed in some way (process
50       returned error code on exit, or crashed, an operation timed out, or
51       after too many restarts). If this state is entered, the cause will be
52       logged, for later reference. Note that the various unit types may have
53       a number of additional substates, which are mapped to the five
54       generalized unit states described here.
55
56       The following unit types are available:
57
58        1. Service units, which start and control daemons and the processes
59           they consist of. For details, see systemd.service(5).
60
61        2. Socket units, which encapsulate local IPC or network sockets in the
62           system, useful for socket-based activation. For details about
63           socket units, see systemd.socket(5), for details on socket-based
64           activation and other forms of activation, see daemon(7).
65
66        3. Target units are useful to group units, or provide well-known
67           synchronization points during boot-up, see systemd.target(5).
68
69        4. Device units expose kernel devices in systemd and may be used to
70           implement device-based activation. For details, see
71           systemd.device(5).
72
73        5. Mount units control mount points in the file system, for details
74           see systemd.mount(5).
75
76        6. Automount units provide automount capabilities, for on-demand
77           mounting of file systems as well as parallelized boot-up. See
78           systemd.automount(5).
79
80        7. Timer units are useful for triggering activation of other units
81           based on timers. You may find details in systemd.timer(5).
82
83        8. Swap units are very similar to mount units and encapsulate memory
84           swap partitions or files of the operating system. They are
85           described in systemd.swap(5).
86
87        9. Path units may be used to activate other services when file system
88           objects change or are modified. See systemd.path(5).
89
90       10. Slice units may be used to group units which manage system
91           processes (such as service and scope units) in a hierarchical tree
92           for resource management purposes. See systemd.slice(5).
93
94       11. Scope units are similar to service units, but manage foreign
95           processes instead of starting them as well. See systemd.scope(5).
96
97       Units are named as their configuration files. Some units have special
98       semantics. A detailed list is available in systemd.special(7).
99
100       systemd knows various kinds of dependencies, including positive and
101       negative requirement dependencies (i.e.  Requires= and Conflicts=) as
102       well as ordering dependencies (After= and Before=). NB: ordering and
103       requirement dependencies are orthogonal. If only a requirement
104       dependency exists between two units (e.g.  foo.service requires
105       bar.service), but no ordering dependency (e.g.  foo.service after
106       bar.service) and both are requested to start, they will be started in
107       parallel. It is a common pattern that both requirement and ordering
108       dependencies are placed between two units. Also note that the majority
109       of dependencies are implicitly created and maintained by systemd. In
110       most cases, it should be unnecessary to declare additional dependencies
111       manually, however it is possible to do this.
112
113       Application programs and units (via dependencies) may request state
114       changes of units. In systemd, these requests are encapsulated as 'jobs'
115       and maintained in a job queue. Jobs may succeed or can fail, their
116       execution is ordered based on the ordering dependencies of the units
117       they have been scheduled for.
118
119       On boot systemd activates the target unit default.target whose job is
120       to activate on-boot services and other on-boot units by pulling them in
121       via dependencies. Usually, the unit name is just an alias (symlink) for
122       either graphical.target (for fully-featured boots into the UI) or
123       multi-user.target (for limited console-only boots for use in embedded
124       or server environments, or similar; a subset of graphical.target).
125       However, it is at the discretion of the administrator to configure it
126       as an alias to any other target unit. See systemd.special(7) for
127       details about these target units.
128
129       systemd only keeps a minimal set of units loaded into memory.
130       Specifically, the only units that are kept loaded into memory are those
131       for which at least one of the following conditions is true:
132
133        1. It is in an active, activating, deactivating or failed state (i.e.
134           in any unit state except for "inactive")
135
136        2. It has a job queued for it
137
138        3. It is a dependency of some sort of at least one other unit that is
139           loaded into memory
140
141        4. It has some form of resource still allocated (e.g. a service unit
142           that is inactive but for which a process is still lingering that
143           ignored the request to be terminated)
144
145        5. It has been pinned into memory programmatically by a D-Bus call
146
147       systemd will automatically and implicitly load units from disk — if
148       they are not loaded yet — as soon as operations are requested for them.
149       Thus, in many respects, the fact whether a unit is loaded or not is
150       invisible to clients. Use systemctl list-units --all to comprehensively
151       list all units currently loaded. Any unit for which none of the
152       conditions above applies is promptly unloaded. Note that when a unit is
153       unloaded from memory its accounting data is flushed out too. However,
154       this data is generally not lost, as a journal log record is generated
155       declaring the consumed resources whenever a unit shuts down.
156
157       Processes systemd spawns are placed in individual Linux control groups
158       named after the unit which they belong to in the private systemd
159       hierarchy. (see cgroups.txt[1] for more information about control
160       groups, or short "cgroups"). systemd uses this to effectively keep
161       track of processes. Control group information is maintained in the
162       kernel, and is accessible via the file system hierarchy (beneath
163       /sys/fs/cgroup/systemd/), or in tools such as systemd-cgls(1) or ps(1)
164       (ps xawf -eo pid,user,cgroup,args is particularly useful to list all
165       processes and the systemd units they belong to.).
166
167       systemd is compatible with the SysV init system to a large degree: SysV
168       init scripts are supported and simply read as an alternative (though
169       limited) configuration file format. The SysV /dev/initctl interface is
170       provided, and compatibility implementations of the various SysV client
171       tools are available. In addition to that, various established Unix
172       functionality such as /etc/fstab or the utmp database are supported.
173
174       systemd has a minimal transaction system: if a unit is requested to
175       start up or shut down it will add it and all its dependencies to a
176       temporary transaction. Then, it will verify if the transaction is
177       consistent (i.e. whether the ordering of all units is cycle-free). If
178       it is not, systemd will try to fix it up, and removes non-essential
179       jobs from the transaction that might remove the loop. Also, systemd
180       tries to suppress non-essential jobs in the transaction that would stop
181       a running service. Finally it is checked whether the jobs of the
182       transaction contradict jobs that have already been queued, and
183       optionally the transaction is aborted then. If all worked out and the
184       transaction is consistent and minimized in its impact it is merged with
185       all already outstanding jobs and added to the run queue. Effectively
186       this means that before executing a requested operation, systemd will
187       verify that it makes sense, fixing it if possible, and only failing if
188       it really cannot work.
189
190       Note that transactions are generated independently of a unit's state at
191       runtime, hence, for example, if a start job is requested on an already
192       started unit, it will still generate a transaction and wake up any
193       inactive dependencies (and cause propagation of other jobs as per the
194       defined relationships). This is because the enqueued job is at the time
195       of execution compared to the target unit's state and is marked
196       successful and complete when both satisfy. However, this job also pulls
197       in other dependencies due to the defined relationships and thus leads
198       to, in our our example, start jobs for any of those inactive units
199       getting queued as well.
200
201       systemd contains native implementations of various tasks that need to
202       be executed as part of the boot process. For example, it sets the
203       hostname or configures the loopback network device. It also sets up and
204       mounts various API file systems, such as /sys or /proc.
205
206       For more information about the concepts and ideas behind systemd,
207       please refer to the Original Design Document[2].
208
209       Note that some but not all interfaces provided by systemd are covered
210       by the Interface Stability Promise[3].
211
212       Units may be generated dynamically at boot and system manager reload
213       time, for example based on other configuration files or parameters
214       passed on the kernel command line. For details, see
215       systemd.generator(7).
216
217       Systems which invoke systemd in a container or initrd environment
218       should implement the Container Interface[4] or initrd Interface[5]
219       specifications, respectively.
220

DIRECTORIES

222       System unit directories
223           The systemd system manager reads unit configuration from various
224           directories. Packages that want to install unit files shall place
225           them in the directory returned by pkg-config systemd
226           --variable=systemdsystemunitdir. Other directories checked are
227           /usr/local/lib/systemd/system and /usr/lib/systemd/system. User
228           configuration always takes precedence.  pkg-config systemd
229           --variable=systemdsystemconfdir returns the path of the system
230           configuration directory. Packages should alter the content of these
231           directories only with the enable and disable commands of the
232           systemctl(1) tool. Full list of directories is provided in
233           systemd.unit(5).
234
235       User unit directories
236           Similar rules apply for the user unit directories. However, here
237           the XDG Base Directory specification[6] is followed to find units.
238           Applications should place their unit files in the directory
239           returned by pkg-config systemd --variable=systemduserunitdir.
240           Global configuration is done in the directory reported by
241           pkg-config systemd --variable=systemduserconfdir. The enable and
242           disable commands of the systemctl(1) tool can handle both global
243           (i.e. for all users) and private (for one user) enabling/disabling
244           of units. Full list of directories is provided in systemd.unit(5).
245
246       SysV init scripts directory
247           The location of the SysV init script directory varies between
248           distributions. If systemd cannot find a native unit file for a
249           requested service, it will look for a SysV init script of the same
250           name (with the .service suffix removed).
251
252       SysV runlevel link farm directory
253           The location of the SysV runlevel link farm directory varies
254           between distributions. systemd will take the link farm into account
255           when figuring out whether a service shall be enabled. Note that a
256           service unit with a native unit configuration file cannot be
257           started by activating it in the SysV runlevel link farm.
258

SIGNALS

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

ENVIRONMENT

388       $SYSTEMD_LOG_LEVEL
389           systemd reads the log level from this environment variable. This
390           can be overridden with --log-level=.
391
392       $SYSTEMD_LOG_TARGET
393           systemd reads the log target from this environment variable. This
394           can be overridden with --log-target=.
395
396       $SYSTEMD_LOG_COLOR
397           Controls whether systemd highlights important log messages. This
398           can be overridden with --log-color=.
399
400       $SYSTEMD_LOG_LOCATION
401           Controls whether systemd prints the code location along with log
402           messages. This can be overridden with --log-location=.
403
404       $XDG_CONFIG_HOME, $XDG_CONFIG_DIRS, $XDG_DATA_HOME, $XDG_DATA_DIRS
405           The systemd user manager uses these variables in accordance to the
406           XDG Base Directory specification[6] to find its configuration.
407
408       $SYSTEMD_UNIT_PATH
409           Controls where systemd looks for unit files.
410
411       $SYSTEMD_SYSVINIT_PATH
412           Controls where systemd looks for SysV init scripts.
413
414       $SYSTEMD_SYSVRCND_PATH
415           Controls where systemd looks for SysV init script runlevel link
416           farms.
417
418       $SYSTEMD_PAGER
419           Pager to use when --no-pager is not given; overrides $PAGER. If
420           neither $SYSTEMD_PAGER nor $PAGER are set, a set of well-known
421           pager implementations are tried in turn, including less(1) and
422           more(1), until one is found. If no pager implementation is
423           discovered no pager is invoked. Setting this environment variable
424           to an empty string or the value "cat" is equivalent to passing
425           --no-pager.
426
427       $SYSTEMD_LESS
428           Override the options passed to less (by default "FRSXMK").
429
430           Users might want to change two options in particular:
431
432           K
433               This option instructs the pager to exit immediately when Ctrl+C
434               is pressed. To allow less to handle Ctrl+C itself to switch
435               back to the pager command prompt, unset this option.
436
437               If the value of $SYSTEMD_LESS does not include "K", and the
438               pager that is invoked is less, Ctrl+C will be ignored by the
439               executable, and needs to be handled by the pager.
440
441           X
442               This option instructs the pager to not send termcap
443               initialization and deinitialization strings to the terminal. It
444               is set by default to allow command output to remain visible in
445               the terminal even after the pager exits. Nevertheless, this
446               prevents some pager functionality from working, in particular
447               paged output cannot be scrolled with the mouse.
448
449           See less(1) for more discussion.
450
451       $SYSTEMD_LESSCHARSET
452           Override the charset passed to less (by default "utf-8", if the
453           invoking terminal is determined to be UTF-8 compatible).
454
455       $SYSTEMD_COLORS
456           The value must be a boolean. Controls whether colorized output
457           should be generated. This can be specified to override the decision
458           that systemd makes based on $TERM and what the console is connected
459           to.
460
461       $SYSTEMD_URLIFY
462           The value must be a boolean. Controls whether clickable links
463           should be generated in the output for terminal emulators supporting
464           this. This can be specified to override the decision that systemd
465           makes based on $TERM and other conditions.
466
467       $LISTEN_PID, $LISTEN_FDS, $LISTEN_FDNAMES
468           Set by systemd for supervised processes during socket-based
469           activation. See sd_listen_fds(3) for more information.
470
471       $NOTIFY_SOCKET
472           Set by systemd for supervised processes for status and start-up
473           completion notification. See sd_notify(3) for more information.
474
475       For further environment variables understood by systemd and its various
476       components, see Known Environment Variables[7].
477

KERNEL COMMAND LINE

479       When run as the system instance systemd parses a number of options
480       listed below. They can be specified as kernel command line
481       arguments[8], or through the "SystemdOptions" EFI variable (on EFI
482       systems). The kernel command line has higher priority. Following
483       variables are understood:
484
485       systemd.unit=, rd.systemd.unit=
486           Overrides the unit to activate on boot. Defaults to default.target.
487           This may be used to temporarily boot into a different boot unit,
488           for example rescue.target or emergency.service. See
489           systemd.special(7) for details about these units. The option
490           prefixed with "rd."  is honored only in the initial RAM disk
491           (initrd), while the one that is not prefixed only in the main
492           system.
493
494       systemd.dump_core
495           Takes a boolean argument or enables the option if specified without
496           an argument. If enabled, the systemd manager (PID 1) dumps core
497           when it crashes. Otherwise, no core dump is created. Defaults to
498           enabled.
499
500       systemd.crash_chvt
501           Takes a positive integer, or a boolean argument. Can be also
502           specified without an argument, with the same effect as a positive
503           boolean. If a positive integer (in the range 1–63) is specified,
504           the system manager (PID 1) will activate the specified virtual
505           terminal (VT) when it crashes. Defaults to disabled, meaning that
506           no such switch is attempted. If set to enabled, the VT the kernel
507           messages are written to is selected.
508
509       systemd.crash_shell
510           Takes a boolean argument or enables the option if specified without
511           an argument. If enabled, the system manager (PID 1) spawns a shell
512           when it crashes, after a 10s delay. Otherwise, no shell is spawned.
513           Defaults to disabled, for security reasons, as the shell is not
514           protected by password authentication.
515
516       systemd.crash_reboot
517           Takes a boolean argument or enables the option if specified without
518           an argument. If enabled, the system manager (PID 1) will reboot the
519           machine automatically when it crashes, after a 10s delay.
520           Otherwise, the system will hang indefinitely. Defaults to disabled,
521           in order to avoid a reboot loop. If combined with
522           systemd.crash_shell, the system is rebooted after the shell exits.
523
524       systemd.confirm_spawn
525           Takes a boolean argument or a path to the virtual console where the
526           confirmation messages should be emitted. Can be also specified
527           without an argument, with the same effect as a positive boolean. If
528           enabled, the system manager (PID 1) asks for confirmation when
529           spawning processes using /dev/console. If a path or a console name
530           (such as "ttyS0") is provided, the virtual console pointed to by
531           this path or described by the give name will be used instead.
532           Defaults to disabled.
533
534       systemd.service_watchdogs=
535           Takes a boolean argument. If disabled, all service runtime
536           watchdogs (WatchdogSec=) and emergency actions (e.g.  OnFailure= or
537           StartLimitAction=) are ignored by the system manager (PID 1); see
538           systemd.service(5). Defaults to enabled, i.e. watchdogs and failure
539           actions are processed normally. The hardware watchdog is not
540           affected by this option.
541
542       systemd.show_status
543           Takes a boolean argument or the constants error and auto. Can be
544           also specified without an argument, with the same effect as a
545           positive boolean. If enabled, the systemd manager (PID 1) shows
546           terse service status updates on the console during bootup. With
547           error, only messages about failures are shown, but boot is
548           otherwise quiet.  auto behaves like false until there is a
549           significant delay in boot. Defaults to enabled, unless quiet is
550           passed as kernel command line option, in which case it defaults to
551           error. If specified overrides the system manager configuration file
552           option ShowStatus=, see systemd-system.conf(5).
553
554       systemd.status_unit_format=
555           Takes either name or description as the value. If name, the system
556           manager will use unit names in status messages. If specified,
557           overrides the system manager configuration file option
558           StatusUnitFormat=, see systemd-system.conf(5).
559
560       systemd.log_target=, systemd.log_level=, systemd.log_location=,
561       systemd.log_color
562           Controls log output, with the same effect as the
563           $SYSTEMD_LOG_TARGET, $SYSTEMD_LOG_LEVEL, $SYSTEMD_LOG_LOCATION,
564           $SYSTEMD_LOG_COLOR environment variables described above.
565           systemd.log_color can be specified without an argument, with the
566           same effect as a positive boolean.
567
568       systemd.default_standard_output=, systemd.default_standard_error=
569           Controls default standard output and error output for services and
570           sockets. That is, controls the default for StandardOutput= and
571           StandardError= (see systemd.exec(5) for details). Takes one of
572           inherit, null, tty, journal, journal+console, kmsg, kmsg+console.
573           If the argument is omitted systemd.default-standard-output=
574           defaults to journal and systemd.default-standard-error= to inherit.
575
576       systemd.setenv=
577           Takes a string argument in the form VARIABLE=VALUE. May be used to
578           set default environment variables to add to forked child processes.
579           May be used more than once to set multiple variables.
580
581       systemd.machine_id=
582           Takes a 32 character hex value to be used for setting the
583           machine-id. Intended mostly for network booting where the same
584           machine-id is desired for every boot.
585
586       systemd.unified_cgroup_hierarchy
587           When specified without an argument or with a true argument, enables
588           the usage of unified cgroup hierarchy[9] (a.k.a. cgroups-v2). When
589           specified with a false argument, fall back to hybrid or full legacy
590           cgroup hierarchy.
591
592           If this option is not specified, the default behaviour is
593           determined during compilation (the -Ddefault-hierarchy= meson
594           option). If the kernel does not support unified cgroup hierarchy,
595           the legacy hierarchy will be used even if this option is specified.
596
597       systemd.legacy_systemd_cgroup_controller
598           Takes effect if the full unified cgroup hierarchy is not used (see
599           previous option). When specified without an argument or with a true
600           argument, disables the use of "hybrid" cgroup hierarchy (i.e. a
601           cgroups-v2 tree used for systemd, and legacy cgroup hierarchy[10],
602           a.k.a. cgroups-v1, for other controllers), and forces a full
603           "legacy" mode. When specified with a false argument, enables the
604           use of "hybrid" hierarchy.
605
606           If this option is not specified, the default behaviour is
607           determined during compilation (the -Ddefault-hierarchy= meson
608           option). If the kernel does not support unified cgroup hierarchy,
609           the legacy hierarchy will be used even if this option is specified.
610
611       quiet
612           Turn off status output at boot, much like systemd.show_status=no
613           would. Note that this option is also read by the kernel itself and
614           disables kernel log output. Passing this option hence turns off the
615           usual output from both the system manager and the kernel.
616
617       debug
618           Turn on debugging output. This is equivalent to
619           systemd.log_level=debug. Note that this option is also read by the
620           kernel itself and enables kernel debug output. Passing this option
621           hence turns on the debug output from both the system manager and
622           the kernel.
623
624       emergency, rd.emergency, -b
625           Boot into emergency mode. This is equivalent to
626           systemd.unit=emergency.target or rd.systemd.unit=emergency.target,
627           respectively, and provided for compatibility reasons and to be
628           easier to type.
629
630       rescue, rd.rescue, single, s, S, 1
631           Boot into rescue mode. This is equivalent to
632           systemd.unit=rescue.target or rd.systemd.unit=rescue.target,
633           respectively, and provided for compatibility reasons and to be
634           easier to type.
635
636       2, 3, 4, 5
637           Boot into the specified legacy SysV runlevel. These are equivalent
638           to systemd.unit=runlevel2.target, systemd.unit=runlevel3.target,
639           systemd.unit=runlevel4.target, and systemd.unit=runlevel5.target,
640           respectively, and provided for compatibility reasons and to be
641           easier to type.
642
643       locale.LANG=, locale.LANGUAGE=, locale.LC_CTYPE=, locale.LC_NUMERIC=,
644       locale.LC_TIME=, locale.LC_COLLATE=, locale.LC_MONETARY=,
645       locale.LC_MESSAGES=, locale.LC_PAPER=, locale.LC_NAME=,
646       locale.LC_ADDRESS=, locale.LC_TELEPHONE=, locale.LC_MEASUREMENT=,
647       locale.LC_IDENTIFICATION=
648           Set the system locale to use. This overrides the settings in
649           /etc/locale.conf. For more information, see locale.conf(5) and
650           locale(7).
651
652       For other kernel command line parameters understood by components of
653       the core OS, please refer to kernel-command-line(7).
654

OPTIONS

656       systemd is only very rarely invoked directly, since it is started early
657       and is already running by the time users may interact with it.
658       Normally, tools like systemctl(1) are used to give commands to the
659       manager. Since systemd is usually not invoked directly, the options
660       listed below are mostly useful for debugging and special purposes.
661
662   Introspection and debugging options
663       Those options are used for testing and introspection, and systemd may
664       be invoked with them at any time:
665
666       --dump-configuration-items
667           Dump understood unit configuration items. This outputs a terse but
668           complete list of configuration items understood in unit definition
669           files.
670
671       --dump-bus-properties
672           Dump exposed bus properties. This outputs a terse but complete list
673           of properties exposed on D-Bus.
674
675       --test
676           Determine the initial start-up transaction (i.e. the list of jobs
677           enqueued at start-up), dump it and exit — without actually
678           executing any of the determined jobs. This option is useful for
679           debugging only. Note that during regular service manager start-up
680           additional units not shown by this operation may be started,
681           because hardware, socket, bus or other kinds of activation might
682           add additional jobs as the transaction is executed. Use --system to
683           request the initial transaction of the system service manager (this
684           is also the implied default), combine with --user to request the
685           initial transaction of the per-user service manager instead.
686
687       --system, --user
688           When used in conjunction with --test, selects whether to calculate
689           the initial transaction for the system instance or for a per-user
690           instance. These options have no effect when invoked without --test,
691           as during regular (i.e. non---test) invocations the service manager
692           will automatically detect whether it shall operate in system or
693           per-user mode, by checking whether the PID it is run as is 1 or
694           not. Note that it is not supported booting and maintaining a system
695           with the service manager running in --system mode but with a PID
696           other than 1.
697
698       -h, --help
699           Print a short help text and exit.
700
701       --version
702           Print a short version string and exit.
703
704   Options that duplicate kernel command line settings
705       Those options correspond directly to options listed above in "Kernel
706       Command Line". Both forms may be used equivalently for the system
707       manager, but it is recommended to use the forms listed above in this
708       context, because they are properly namespaced. When an option is
709       specified both on the kernel command line, and as a normal command line
710       argument, the latter has higher precedence.
711
712       When systemd is used a user manager, the kernel command line is ignored
713       and the options described are understood. Nevertheless, systemd is
714       usually started in this mode through the user@.service(5) service,
715       which is shared between all users, and it may be more convenient to use
716       configuration files to modify settings, see systemd-user.conf(5), or a
717       drop-in that specifies one of the environment variables listed above in
718       "Environment, see systemd.unit(5).
719
720       --unit=
721           Set default unit to activate on startup. If not specified, defaults
722           to default.target. See systemd.unit= above.
723
724       --dump-core
725           Enable core dumping on crash. This switch has no effect when
726           running as user instance. Same as systemd.dump_core= above.
727
728       --crash-vt=VT
729           Switch to a specific virtual console (VT) on crash. This switch has
730           no effect when running as user instance. Same as
731           systemd.crash_chvt= above (but not the different spelling!).
732
733       --crash-shell
734           Run a shell on crash. This switch has no effect when running as
735           user instance. See systemd.crash_shell= above.
736
737       --crash-reboot
738           Automatically reboot the system on crash. This switch has no effect
739           when running as user instance. See systemd.crash_reboot above.
740
741       --confirm-spawn
742           Ask for confirmation when spawning processes. This switch has no
743           effect when run as user instance. See systemd.confirm_spawn above.
744
745       --show-status
746           Show terse unit status information is shown on the console during
747           boot-up and shutdown. See systemd.show_status above.
748
749       --log-target=
750           Set log target. See systemd.log_target above.
751
752       --log-level=
753           Set log level. See systemd.log_level above.
754
755       --log-color
756           Highlight important log messages. See systemd.log_color above.
757
758       --log-location
759           Include code location in log messages. See systemd.log_location
760           above.
761
762       --machine-id=
763           Override the machine-id set on the hard drive. See
764           systemd.machine_id= above.
765
766       --service-watchdogs
767           Globally enable/disable all service watchdog timeouts and emergency
768           actions. See systemd.service_watchdogs above.
769
770       --default-standard-output=, --default-standard-error=
771           Sets the default output or error output for all services and
772           sockets, respectively. See systemd.default_standard_output= and
773           systemd.default_standard_error= above.
774

SOCKETS AND FIFOS

776       /run/systemd/notify
777           Daemon status notification socket. This is an AF_UNIX datagram
778           socket and is used to implement the daemon notification logic as
779           implemented by sd_notify(3).
780
781       /run/systemd/private
782           Used internally as communication channel between systemctl(1) and
783           the systemd process. This is an AF_UNIX stream socket. This
784           interface is private to systemd and should not be used in external
785           projects.
786
787       /dev/initctl
788           Limited compatibility support for the SysV client interface, as
789           implemented by the systemd-initctl.service unit. This is a named
790           pipe in the file system. This interface is obsolete and should not
791           be used in new applications.
792

SEE ALSO

794       The systemd Homepage[11], systemd-system.conf(5), locale.conf(5),
795       systemctl(1), journalctl(1), systemd-notify(1), daemon(7), sd-
796       daemon(3), systemd.unit(5), systemd.special(5), pkg-config(1), kernel-
797       command-line(7), bootup(7), systemd.directives(7)
798

NOTES

800        1. cgroups.txt
801           https://www.kernel.org/doc/Documentation/cgroup-v1/cgroups.txt
802
803        2. Original Design Document
804           http://0pointer.de/blog/projects/systemd.html
805
806        3. Interface Stability Promise
807           https://www.freedesktop.org/wiki/Software/systemd/InterfaceStabilityPromise
808
809        4. Container Interface
810           https://systemd.io/CONTAINER_INTERFACE
811
812        5. initrd Interface
813           https://www.freedesktop.org/wiki/Software/systemd/InitrdInterface
814
815        6. XDG Base Directory specification
816           http://standards.freedesktop.org/basedir-spec/basedir-spec-latest.html
817
818        7. Known Environment Variables
819           https://systemd.io/ENVIRONMENT
820
821        8. If run inside a Linux container these arguments may be passed as
822           command line arguments to systemd itself, next to any of the
823           command line options listed in the Options section above. If run
824           outside of Linux containers, these arguments are parsed from
825           /proc/cmdline instead.
826
827        9. unified cgroup hierarchy
828           https://www.kernel.org/doc/html/latest/admin-guide/cgroup-v2.html
829
830       10. legacy cgroup hierarchy
831           https://www.kernel.org/doc/Documentation/cgroup-v1/
832
833       11. systemd Homepage
834           https://www.freedesktop.org/wiki/Software/systemd/
835
836
837
838systemd 245                                                         SYSTEMD(1)
Impressum