1SYSTEMD(1) systemd SYSTEMD(1)
2
6 systemd, init - systemd system and service manager
7
9 /usr/lib/systemd/systemd [OPTIONS...]
10 init [OPTIONS...] {COMMAND}
12
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 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 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
31 The following options are understood:
32 --test
34 Determine startup sequence, dump it and exit. This is an option
35 useful for debugging only.
36 --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 --dump-bus-properties
43 Dump exposed bus properties. This outputs a terse but complete list
44 of properties exposed to dbus.
45 --unit=
47 Set default unit to activate on startup. If not specified, defaults
48 to default.target.
49 --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 --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 --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 --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 --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 --confirm-spawn
89 Ask for confirmation when spawning processes. This switch has no
90 effect when run as user instance.
91 --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 --log-target=
104 Set log target. Argument must be one of console, journal, kmsg,
105 journal-or-kmsg, null.
106 --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 --log-color=
113 Highlight important log messages. Argument is a boolean value. If
114 the argument is omitted, it defaults to true.
115 --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 --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 --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 --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 -h, --help
141 Print a short help text and exit.
142 --version
144 Print a short version string and exit.
145
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 The following unit types are available:
167 1. Service units, which start and control daemons and the processes
169 they consist of. For details, see systemd.service(5).
170 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 3. Target units are useful to group units, or provide well-known
177 synchronization points during boot-up, see systemd.target(5).
178 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 5. Mount units control mount points in the file system, for details
184 see systemd.mount(5).
185 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 7. Timer units are useful for triggering activation of other units
191 based on timers. You may find details in systemd.timer(5).
192 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 9. Path units may be used to activate other services when file system
198 objects change or are modified. See systemd.path(5).
199 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 11. Scope units are similar to service units, but manage foreign
205 processes instead of starting them as well. See systemd.scope(5).
206 Units are named as their configuration files. Some units have special
208 semantics. A detailed list is available in systemd.special(7).
209 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 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 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 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 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 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 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 For more information about the concepts and ideas behind systemd,
278 please refer to the Original Design Document[2].
279 Note that some but not all interfaces provided by systemd are covered
281 by the Interface Stability Promise[3].
282 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 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
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 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 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 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
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 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 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 systemd user managers treat this signal the same way as SIGTERM.
352 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 This signal is ignored by systemd user managers.
359 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 SIGUSR1
366 When this signal is received the systemd manager will try to
367 reconnect to the D-Bus bus.
368 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 SIGHUP
375 Reloads the complete daemon configuration. This is mostly
376 equivalent to systemctl daemon-reload.
377 SIGRTMIN+0
379 Enters default mode, starts the default.target unit. This is mostly
380 equivalent to systemctl isolate default.target.
381 SIGRTMIN+1
383 Enters rescue mode, starts the rescue.target unit. This is mostly
384 equivalent to systemctl isolate rescue.target.
385 SIGRTMIN+2
387 Enters emergency mode, starts the emergency.service unit. This is
388 mostly equivalent to systemctl isolate emergency.service.
389 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 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 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 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 SIGRTMIN+13
411 Immediately halts the machine.
412 SIGRTMIN+14
414 Immediately powers off the machine.
415 SIGRTMIN+15
417 Immediately reboots the machine.
418 SIGRTMIN+16
420 Immediately reboots the machine with kexec.
421 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 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 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 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 SIGRTMIN+24
442 Immediately exits the manager (only available for --user
443 instances).
444 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 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
459 $SYSTEMD_LOG_LEVEL
460 systemd reads the log level from this environment variable. This
461 can be overridden with --log-level=.
462 $SYSTEMD_LOG_TARGET
464 systemd reads the log target from this environment variable. This
465 can be overridden with --log-target=.
466 $SYSTEMD_LOG_COLOR
468 Controls whether systemd highlights important log messages. This
469 can be overridden with --log-color=.
470 $SYSTEMD_LOG_LOCATION
472 Controls whether systemd prints the code location along with log
473 messages. This can be overridden with --log-location=.
474 $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 $SYSTEMD_UNIT_PATH
480 Controls where systemd looks for unit files.
481 $SYSTEMD_SYSVINIT_PATH
483 Controls where systemd looks for SysV init scripts.
484 $SYSTEMD_SYSVRCND_PATH
486 Controls where systemd looks for SysV init script runlevel link
487 farms.
488 $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 $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 $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 $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
510 When run as system instance systemd parses a number of kernel command
511 line arguments[7]:
512 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 For other kernel command line parameters understood by components of
674 the core OS, please refer to kernel-command-line(7).
675
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 /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 /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
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
701 1. cgroups.txt
702 https://www.kernel.org/doc/Documentation/cgroup-v1/cgroups.txt
703 2. Original Design Document
705 http://0pointer.de/blog/projects/systemd.html
706 3. Interface Stability Promise
708 https://www.freedesktop.org/wiki/Software/systemd/InterfaceStabilityPromise
709 4. Container Interface
711 https://www.freedesktop.org/wiki/Software/systemd/ContainerInterface
712 5. initrd Interface
714 https://www.freedesktop.org/wiki/Software/systemd/InitrdInterface
715 6. XDG Base Directory specification
717 http://standards.freedesktop.org/basedir-spec/basedir-spec-latest.html
718 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 8. unified cgroup hierarchy
726 https://www.kernel.org/doc/Documentation/cgroup-v2.txt
727 9. legacy cgroup hierarchy
729 https://www.kernel.org/doc/Documentation/cgroup-v1/
730 10. systemd Homepage
732 https://www.freedesktop.org/wiki/Software/systemd/
733systemd 239 SYSTEMD(1)