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.
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; when run
26       as a user instance, systemd interprets the configuration file user.conf
27       and the files in user.conf.d directories. See systemd-system.conf(5)
28       for more information.
29

OPTIONS

31       The following options are understood:
32
33       --test
34           Determine startup sequence, dump it and exit. This is an option
35           useful for debugging only.
36
37       --dump-configuration-items
38           Dump understood unit configuration items. This outputs a terse but
39           complete list of configuration items understood in unit definition
40           files.
41
42       --dump-bus-properties
43           Dump exposed bus properties. This outputs a terse but complete list
44           of properties exposed to dbus.
45
46       --unit=
47           Set default unit to activate on startup. If not specified, defaults
48           to default.target.
49
50       --system, --user
51           For --system, tell systemd to run a system instance, even if the
52           process ID is not 1, i.e. systemd is not run as init process.
53           --user does the opposite, running a user instance even if the
54           process ID is 1. Normally, it should not be necessary to pass these
55           options, as systemd automatically detects the mode it is started
56           in. These options are hence of little use except for debugging.
57           Note that it is not supported booting and maintaining a full system
58           with systemd running in --system mode, but PID not 1. In practice,
59           passing --system explicitly is only useful in conjunction with
60           --test.
61
62       --dump-core
63           Enable core dumping on crash. This switch has no effect when
64           running as user instance. This setting may also be enabled during
65           boot on the kernel command line via the systemd.dump_core= option,
66           see below.
67
68       --crash-vt=VT
69           Switch to a specific virtual console (VT) on crash. Takes a
70           positive integer in the range 1–63, or a boolean argument. If an
71           integer is passed, selects which VT to switch to. If yes, the VT
72           kernel messages are written to is selected. If no, no VT switch is
73           attempted. This switch has no effect when running as user instance.
74           This setting may also be enabled during boot, on the kernel command
75           line via the systemd.crash_vt= option, see below.
76
77       --crash-shell
78           Run a shell on crash. This switch has no effect when running as
79           user instance. This setting may also be enabled during boot, on the
80           kernel command line via the systemd.crash_shell= option, see below.
81
82       --crash-reboot
83           Automatically reboot the system on crash. This switch has no effect
84           when running as user instance. This setting may also be enabled
85           during boot, on the kernel command line via the
86           systemd.crash_reboot= option, see below.
87
88       --confirm-spawn
89           Ask for confirmation when spawning processes. This switch has no
90           effect when run as user instance.
91
92       --show-status=
93           Takes a boolean argument or the special value auto. If on, terse
94           unit status information is shown on the console during boot-up and
95           shutdown. If off, no such status information is shown. If set to
96           auto behavior is similar to off, except that it is automatically
97           switched to on, as soon as the first unit failure or significant
98           boot delay is encountered. This switch has no effect when invoked
99           as user instance. If specified, overrides both the kernel command
100           line setting systemd.show_status= (see below) and the configuration
101           file option ShowStatus=, see systemd-system.conf(5).
102
103       --log-target=
104           Set log target. Argument must be one of console, journal, kmsg,
105           journal-or-kmsg, null.
106
107       --log-level=
108           Set log level. As argument this accepts a numerical log level or
109           the well-known syslog(3) symbolic names (lowercase): emerg, alert,
110           crit, err, warning, notice, info, debug.
111
112       --log-color=
113           Highlight important log messages. Argument is a boolean value. If
114           the argument is omitted, it defaults to true.
115
116       --log-location=
117           Include code location in log messages. This is mostly relevant for
118           debugging purposes. Argument is a boolean value. If the argument is
119           omitted it defaults to true.
120
121       --default-standard-output=, --default-standard-error=
122           Sets the default output or error output for all services and
123           sockets, respectively. That is, controls the default for
124           StandardOutput= and StandardError= (see systemd.exec(5) for
125           details). Takes one of inherit, null, tty, journal,
126           journal+console, syslog, syslog+console, kmsg, kmsg+console. If the
127           argument is omitted --default-standard-output= defaults to journal
128           and --default-standard-error= to inherit.
129
130       --machine-id=
131           Override the machine-id set on the hard drive, useful for network
132           booting or for containers. May not be set to all zeros.
133
134       --service-watchdogs=
135           Globally enable/disable all service watchdog timeouts and emergency
136           actions. This setting may also be specified during boot, on the
137           kernel command line via the systemd.service_watchdogs= option, see
138           below. Defaults to enabled.
139
140       -h, --help
141           Print a short help text and exit.
142
143       --version
144           Print a short version string and exit.
145

CONCEPTS

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

DIRECTORIES

293       System unit directories
294           The systemd system manager reads unit configuration from various
295           directories. Packages that want to install unit files shall place
296           them in the directory returned by pkg-config systemd
297           --variable=systemdsystemunitdir. Other directories checked are
298           /usr/local/lib/systemd/system and /usr/lib/systemd/system. User
299           configuration always takes precedence.  pkg-config systemd
300           --variable=systemdsystemconfdir returns the path of the system
301           configuration directory. Packages should alter the content of these
302           directories only with the enable and disable commands of the
303           systemctl(1) tool. Full list of directories is provided in
304           systemd.unit(5).
305
306       User unit directories
307           Similar rules apply for the user unit directories. However, here
308           the XDG Base Directory specification[6] is followed to find units.
309           Applications should place their unit files in the directory
310           returned by pkg-config systemd --variable=systemduserunitdir.
311           Global configuration is done in the directory reported by
312           pkg-config systemd --variable=systemduserconfdir. The enable and
313           disable commands of the systemctl(1) tool can handle both global
314           (i.e. for all users) and private (for one user) enabling/disabling
315           of units. Full list of directories is provided in systemd.unit(5).
316
317       SysV init scripts directory
318           The location of the SysV init script directory varies between
319           distributions. If systemd cannot find a native unit file for a
320           requested service, it will look for a SysV init script of the same
321           name (with the .service suffix removed).
322
323       SysV runlevel link farm directory
324           The location of the SysV runlevel link farm directory varies
325           between distributions. systemd will take the link farm into account
326           when figuring out whether a service shall be enabled. Note that a
327           service unit with a native unit configuration file cannot be
328           started by activating it in the SysV runlevel link farm.
329

SIGNALS

331       SIGTERM
332           Upon receiving this signal the systemd system manager serializes
333           its state, reexecutes itself and deserializes the saved state
334           again. This is mostly equivalent to systemctl daemon-reexec.
335
336           systemd user managers will start the exit.target unit when this
337           signal is received. This is mostly equivalent to systemctl --user
338           start exit.target --job-mode=replace-irreversible.
339
340       SIGINT
341           Upon receiving this signal the systemd system manager will start
342           the ctrl-alt-del.target unit. This is mostly equivalent to
343           systemctl start ctrl-alt-del.target
344           --job-mode=replace-irreversible. If this signal is received more
345           than 7 times per 2s, an immediate reboot is triggered. Note that
346           pressing Ctrl-Alt-Del on the console will trigger this signal.
347           Hence, if a reboot is hanging, pressing Ctrl-Alt-Del more than 7
348           times in 2s is a relatively safe way to trigger an immediate
349           reboot.
350
351           systemd user managers treat this signal the same way as SIGTERM.
352
353       SIGWINCH
354           When this signal is received the systemd system manager will start
355           the kbrequest.target unit. This is mostly equivalent to systemctl
356           start kbrequest.target.
357
358           This signal is ignored by systemd user managers.
359
360       SIGPWR
361           When this signal is received the systemd manager will start the
362           sigpwr.target unit. This is mostly equivalent to systemctl start
363           sigpwr.target.
364
365       SIGUSR1
366           When this signal is received the systemd manager will try to
367           reconnect to the D-Bus bus.
368
369       SIGUSR2
370           When this signal is received the systemd manager will log its
371           complete state in human-readable form. The data logged is the same
372           as printed by systemd-analyze dump.
373
374       SIGHUP
375           Reloads the complete daemon configuration. This is mostly
376           equivalent to systemctl daemon-reload.
377
378       SIGRTMIN+0
379           Enters default mode, starts the default.target unit. This is mostly
380           equivalent to systemctl isolate default.target.
381
382       SIGRTMIN+1
383           Enters rescue mode, starts the rescue.target unit. This is mostly
384           equivalent to systemctl isolate rescue.target.
385
386       SIGRTMIN+2
387           Enters emergency mode, starts the emergency.service unit. This is
388           mostly equivalent to systemctl isolate emergency.service.
389
390       SIGRTMIN+3
391           Halts the machine, starts the halt.target unit. This is mostly
392           equivalent to systemctl start halt.target
393           --job-mode=replace-irreversible.
394
395       SIGRTMIN+4
396           Powers off the machine, starts the poweroff.target unit. This is
397           mostly equivalent to systemctl start poweroff.target
398           --job-mode=replace-irreversible.
399
400       SIGRTMIN+5
401           Reboots the machine, starts the reboot.target unit. This is mostly
402           equivalent to systemctl start reboot.target
403           --job-mode=replace-irreversible.
404
405       SIGRTMIN+6
406           Reboots the machine via kexec, starts the kexec.target unit. This
407           is mostly equivalent to systemctl start kexec.target
408           --job-mode=replace-irreversible.
409
410       SIGRTMIN+13
411           Immediately halts the machine.
412
413       SIGRTMIN+14
414           Immediately powers off the machine.
415
416       SIGRTMIN+15
417           Immediately reboots the machine.
418
419       SIGRTMIN+16
420           Immediately reboots the machine with kexec.
421
422       SIGRTMIN+20
423           Enables display of status messages on the console, as controlled
424           via systemd.show_status=1 on the kernel command line.
425
426       SIGRTMIN+21
427           Disables display of status messages on the console, as controlled
428           via systemd.show_status=0 on the kernel command line.
429
430       SIGRTMIN+22
431           Sets the service manager's log level to "debug", in a fashion
432           equivalent to systemd.log_level=debug on the kernel command line.
433
434       SIGRTMIN+23
435           Restores the log level to its configured value. The configured
436           value is derived from – in order of priority – the value specified
437           with systemd.log-level= on the kernel command line, or the value
438           specified with LogLevel= in the configuration file, or the built-in
439           default of "info".
440
441       SIGRTMIN+24
442           Immediately exits the manager (only available for --user
443           instances).
444
445       SIGRTMIN+26
446           Restores the log target to its configured value. The configured
447           value is derived from – in order of priority – the value specified
448           with systemd.log-target= on the kernel command line, or the value
449           specified with LogTarget= in the configuration file, or the
450           built-in default.
451
452       SIGRTMIN+27, SIGRTMIN+28
453           Sets the log target to "console" on SIGRTMIN+27 (or "kmsg" on
454           SIGRTMIN+28), in a fashion equivalent to systemd.log_target=console
455           (or systemd.log_target=kmsg on SIGRTMIN+28) on the kernel command
456           line.
457

ENVIRONMENT

459       $SYSTEMD_LOG_LEVEL
460           systemd reads the log level from this environment variable. This
461           can be overridden with --log-level=.
462
463       $SYSTEMD_LOG_TARGET
464           systemd reads the log target from this environment variable. This
465           can be overridden with --log-target=.
466
467       $SYSTEMD_LOG_COLOR
468           Controls whether systemd highlights important log messages. This
469           can be overridden with --log-color=.
470
471       $SYSTEMD_LOG_LOCATION
472           Controls whether systemd prints the code location along with log
473           messages. This can be overridden with --log-location=.
474
475       $XDG_CONFIG_HOME, $XDG_CONFIG_DIRS, $XDG_DATA_HOME, $XDG_DATA_DIRS
476           The systemd user manager uses these variables in accordance to the
477           XDG Base Directory specification[6] to find its configuration.
478
479       $SYSTEMD_UNIT_PATH
480           Controls where systemd looks for unit files.
481
482       $SYSTEMD_SYSVINIT_PATH
483           Controls where systemd looks for SysV init scripts.
484
485       $SYSTEMD_SYSVRCND_PATH
486           Controls where systemd looks for SysV init script runlevel link
487           farms.
488
489       $SYSTEMD_COLORS
490           The value must be a boolean. Controls whether colorized output
491           should be generated. This can be specified to override the decision
492           that systemd makes based on $TERM and what the console is connected
493           to.
494
495       $SYSTEMD_URLIFY
496           The value must be a boolean. Controls whether clickable links
497           should be generated in the output for terminal emulators supporting
498           this. This can be specified to override the decision that systemd
499           makes based on $TERM and other conditions.
500
501       $LISTEN_PID, $LISTEN_FDS, $LISTEN_FDNAMES
502           Set by systemd for supervised processes during socket-based
503           activation. See sd_listen_fds(3) for more information.
504
505       $NOTIFY_SOCKET
506           Set by systemd for supervised processes for status and start-up
507           completion notification. See sd_notify(3) for more information.
508

KERNEL COMMAND LINE

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

SOCKETS AND FIFOS

677       /run/systemd/notify
678           Daemon status notification socket. This is an AF_UNIX datagram
679           socket and is used to implement the daemon notification logic as
680           implemented by sd_notify(3).
681
682       /run/systemd/private
683           Used internally as communication channel between systemctl(1) and
684           the systemd process. This is an AF_UNIX stream socket. This
685           interface is private to systemd and should not be used in external
686           projects.
687
688       /dev/initctl
689           Limited compatibility support for the SysV client interface, as
690           implemented by the systemd-initctl.service unit. This is a named
691           pipe in the file system. This interface is obsolete and should not
692           be used in new applications.
693

SEE ALSO

695       The systemd Homepage[10], systemd-system.conf(5), locale.conf(5),
696       systemctl(1), journalctl(1), systemd-notify(1), daemon(7), sd-
697       daemon(3), systemd.unit(5), systemd.special(5), pkg-config(1), kernel-
698       command-line(7), bootup(7), systemd.directives(7)
699

NOTES

701        1. cgroups.txt
702           https://www.kernel.org/doc/Documentation/cgroup-v1/cgroups.txt
703
704        2. Original Design Document
705           http://0pointer.de/blog/projects/systemd.html
706
707        3. Interface Stability Promise
708           https://www.freedesktop.org/wiki/Software/systemd/InterfaceStabilityPromise
709
710        4. Container Interface
711           https://www.freedesktop.org/wiki/Software/systemd/ContainerInterface
712
713        5. initrd Interface
714           https://www.freedesktop.org/wiki/Software/systemd/InitrdInterface
715
716        6. XDG Base Directory specification
717           http://standards.freedesktop.org/basedir-spec/basedir-spec-latest.html
718
719        7. If run inside a Linux container these arguments may be passed as
720           command line arguments to systemd itself, next to any of the
721           command line options listed in the Options section above. If run
722           outside of Linux containers, these arguments are parsed from
723           /proc/cmdline instead.
724
725        8. unified cgroup hierarchy
726           https://www.kernel.org/doc/Documentation/cgroup-v2.txt
727
728        9. legacy cgroup hierarchy
729           https://www.kernel.org/doc/Documentation/cgroup-v1/
730
731       10. systemd Homepage
732           https://www.freedesktop.org/wiki/Software/systemd/
733
734
735
736systemd 239                                                         SYSTEMD(1)
Impressum