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 systemd only keeps a minimal set of units loaded into memory.
240 Specifically, the only units that are kept loaded into memory are those
241 for which at least one of the following conditions is true:
242 1. It is in an active, activating, deactivating or failed state (i.e.
244 in any unit state except for "inactive")
245 2. It has a job queued for it
247 3. It is a dependency of some sort of at least one other unit that is
249 loaded into memory
250 4. It has some form of resource still allocated (e.g. a service unit
252 that is inactive but for which a process is still lingering that
253 ignored the request to be terminated)
254 5. It has been pinned into memory programmatically by a D-Bus call
256 systemd will automatically and implicitly load units from disk — if
258 they are not loaded yet — as soon as operations are requested for them.
259 Thus, in many respects, the fact whether a unit is loaded or not is
260 invisible to clients. Use systemctl list-units --all to comprehensively
261 list all units currently loaded. Any unit for which none of the
262 conditions above applies is promptly unloaded. Note that when a unit is
263 unloaded from memory its accounting data is flushed out too. However,
264 this data is generally not lost, as a journal log record is generated
265 declaring the consumed resources whenever a unit shuts down.
266 Processes systemd spawns are placed in individual Linux control groups
268 named after the unit which they belong to in the private systemd
269 hierarchy. (see cgroups.txt[1] for more information about control
270 groups, or short "cgroups"). systemd uses this to effectively keep
271 track of processes. Control group information is maintained in the
272 kernel, and is accessible via the file system hierarchy (beneath
273 /sys/fs/cgroup/systemd/), or in tools such as systemd-cgls(1) or ps(1)
274 (ps xawf -eo pid,user,cgroup,args is particularly useful to list all
275 processes and the systemd units they belong to.).
276 systemd is compatible with the SysV init system to a large degree: SysV
278 init scripts are supported and simply read as an alternative (though
279 limited) configuration file format. The SysV /dev/initctl interface is
280 provided, and compatibility implementations of the various SysV client
281 tools are available. In addition to that, various established Unix
282 functionality such as /etc/fstab or the utmp database are supported.
283 systemd has a minimal transaction system: if a unit is requested to
285 start up or shut down it will add it and all its dependencies to a
286 temporary transaction. Then, it will verify if the transaction is
287 consistent (i.e. whether the ordering of all units is cycle-free). If
288 it is not, systemd will try to fix it up, and removes non-essential
289 jobs from the transaction that might remove the loop. Also, systemd
290 tries to suppress non-essential jobs in the transaction that would stop
291 a running service. Finally it is checked whether the jobs of the
292 transaction contradict jobs that have already been queued, and
293 optionally the transaction is aborted then. If all worked out and the
294 transaction is consistent and minimized in its impact it is merged with
295 all already outstanding jobs and added to the run queue. Effectively
296 this means that before executing a requested operation, systemd will
297 verify that it makes sense, fixing it if possible, and only failing if
298 it really cannot work.
299 Note that transactions are generated independently of a unit's state at
301 runtime, hence, for example, if a start job is requested on an already
302 started unit, it will still generate a transaction and wake up any
303 inactive dependencies (and cause propagation of other jobs as per the
304 defined relationships). This is because the enqueued job is at the time
305 of execution compared to the target unit's state and is marked
306 successful and complete when both satisfy. However, this job also pulls
307 in other dependencies due to the defined relationships and thus leads
308 to, in our our example, start jobs for any of those inactive units
309 getting queued as well.
310 systemd contains native implementations of various tasks that need to
312 be executed as part of the boot process. For example, it sets the
313 hostname or configures the loopback network device. It also sets up and
314 mounts various API file systems, such as /sys or /proc.
315 For more information about the concepts and ideas behind systemd,
317 please refer to the Original Design Document[2].
318 Note that some but not all interfaces provided by systemd are covered
320 by the Interface Stability Promise[3].
321 Units may be generated dynamically at boot and system manager reload
323 time, for example based on other configuration files or parameters
324 passed on the kernel command line. For details, see
325 systemd.generator(7).
326 Systems which invoke systemd in a container or initrd environment
328 should implement the Container Interface[4] or initrd Interface[5]
329 specifications, respectively.
330
332 System unit directories
333 The systemd system manager reads unit configuration from various
334 directories. Packages that want to install unit files shall place
335 them in the directory returned by pkg-config systemd
336 --variable=systemdsystemunitdir. Other directories checked are
337 /usr/local/lib/systemd/system and /usr/lib/systemd/system. User
338 configuration always takes precedence. pkg-config systemd
339 --variable=systemdsystemconfdir returns the path of the system
340 configuration directory. Packages should alter the content of these
341 directories only with the enable and disable commands of the
342 systemctl(1) tool. Full list of directories is provided in
343 systemd.unit(5).
344 User unit directories
346 Similar rules apply for the user unit directories. However, here
347 the XDG Base Directory specification[6] is followed to find units.
348 Applications should place their unit files in the directory
349 returned by pkg-config systemd --variable=systemduserunitdir.
350 Global configuration is done in the directory reported by
351 pkg-config systemd --variable=systemduserconfdir. The enable and
352 disable commands of the systemctl(1) tool can handle both global
353 (i.e. for all users) and private (for one user) enabling/disabling
354 of units. Full list of directories is provided in systemd.unit(5).
355 SysV init scripts directory
357 The location of the SysV init script directory varies between
358 distributions. If systemd cannot find a native unit file for a
359 requested service, it will look for a SysV init script of the same
360 name (with the .service suffix removed).
361 SysV runlevel link farm directory
363 The location of the SysV runlevel link farm directory varies
364 between distributions. systemd will take the link farm into account
365 when figuring out whether a service shall be enabled. Note that a
366 service unit with a native unit configuration file cannot be
367 started by activating it in the SysV runlevel link farm.
368
370 SIGTERM
371 Upon receiving this signal the systemd system manager serializes
372 its state, reexecutes itself and deserializes the saved state
373 again. This is mostly equivalent to systemctl daemon-reexec.
374 systemd user managers will start the exit.target unit when this
376 signal is received. This is mostly equivalent to systemctl --user
377 start exit.target --job-mode=replace-irreversible.
378 SIGINT
380 Upon receiving this signal the systemd system manager will start
381 the ctrl-alt-del.target unit. This is mostly equivalent to
382 systemctl start ctrl-alt-del.target
383 --job-mode=replace-irreversible. If this signal is received more
384 than 7 times per 2s, an immediate reboot is triggered. Note that
385 pressing Ctrl+Alt+Del on the console will trigger this signal.
386 Hence, if a reboot is hanging, pressing Ctrl+Alt+Del more than 7
387 times in 2 seconds is a relatively safe way to trigger an immediate
388 reboot.
389 systemd user managers treat this signal the same way as SIGTERM.
391 SIGWINCH
393 When this signal is received the systemd system manager will start
394 the kbrequest.target unit. This is mostly equivalent to systemctl
395 start kbrequest.target.
396 This signal is ignored by systemd user managers.
398 SIGPWR
400 When this signal is received the systemd manager will start the
401 sigpwr.target unit. This is mostly equivalent to systemctl start
402 sigpwr.target.
403 SIGUSR1
405 When this signal is received the systemd manager will try to
406 reconnect to the D-Bus bus.
407 SIGUSR2
409 When this signal is received the systemd manager will log its
410 complete state in human-readable form. The data logged is the same
411 as printed by systemd-analyze dump.
412 SIGHUP
414 Reloads the complete daemon configuration. This is mostly
415 equivalent to systemctl daemon-reload.
416 SIGRTMIN+0
418 Enters default mode, starts the default.target unit. This is mostly
419 equivalent to systemctl isolate default.target.
420 SIGRTMIN+1
422 Enters rescue mode, starts the rescue.target unit. This is mostly
423 equivalent to systemctl isolate rescue.target.
424 SIGRTMIN+2
426 Enters emergency mode, starts the emergency.service unit. This is
427 mostly equivalent to systemctl isolate emergency.service.
428 SIGRTMIN+3
430 Halts the machine, starts the halt.target unit. This is mostly
431 equivalent to systemctl start halt.target
432 --job-mode=replace-irreversible.
433 SIGRTMIN+4
435 Powers off the machine, starts the poweroff.target unit. This is
436 mostly equivalent to systemctl start poweroff.target
437 --job-mode=replace-irreversible.
438 SIGRTMIN+5
440 Reboots the machine, starts the reboot.target unit. This is mostly
441 equivalent to systemctl start reboot.target
442 --job-mode=replace-irreversible.
443 SIGRTMIN+6
445 Reboots the machine via kexec, starts the kexec.target unit. This
446 is mostly equivalent to systemctl start kexec.target
447 --job-mode=replace-irreversible.
448 SIGRTMIN+13
450 Immediately halts the machine.
451 SIGRTMIN+14
453 Immediately powers off the machine.
454 SIGRTMIN+15
456 Immediately reboots the machine.
457 SIGRTMIN+16
459 Immediately reboots the machine with kexec.
460 SIGRTMIN+20
462 Enables display of status messages on the console, as controlled
463 via systemd.show_status=1 on the kernel command line.
464 SIGRTMIN+21
466 Disables display of status messages on the console, as controlled
467 via systemd.show_status=0 on the kernel command line.
468 SIGRTMIN+22
470 Sets the service manager's log level to "debug", in a fashion
471 equivalent to systemd.log_level=debug on the kernel command line.
472 SIGRTMIN+23
474 Restores the log level to its configured value. The configured
475 value is derived from – in order of priority – the value specified
476 with systemd.log-level= on the kernel command line, or the value
477 specified with LogLevel= in the configuration file, or the built-in
478 default of "info".
479 SIGRTMIN+24
481 Immediately exits the manager (only available for --user
482 instances).
483 SIGRTMIN+26
485 Restores the log target to its configured value. The configured
486 value is derived from – in order of priority – the value specified
487 with systemd.log-target= on the kernel command line, or the value
488 specified with LogTarget= in the configuration file, or the
489 built-in default.
490 SIGRTMIN+27, SIGRTMIN+28
492 Sets the log target to "console" on SIGRTMIN+27 (or "kmsg" on
493 SIGRTMIN+28), in a fashion equivalent to systemd.log_target=console
494 (or systemd.log_target=kmsg on SIGRTMIN+28) on the kernel command
495 line.
496
498 $SYSTEMD_LOG_LEVEL
499 systemd reads the log level from this environment variable. This
500 can be overridden with --log-level=.
501 $SYSTEMD_LOG_TARGET
503 systemd reads the log target from this environment variable. This
504 can be overridden with --log-target=.
505 $SYSTEMD_LOG_COLOR
507 Controls whether systemd highlights important log messages. This
508 can be overridden with --log-color=.
509 $SYSTEMD_LOG_LOCATION
511 Controls whether systemd prints the code location along with log
512 messages. This can be overridden with --log-location=.
513 $XDG_CONFIG_HOME, $XDG_CONFIG_DIRS, $XDG_DATA_HOME, $XDG_DATA_DIRS
515 The systemd user manager uses these variables in accordance to the
516 XDG Base Directory specification[6] to find its configuration.
517 $SYSTEMD_UNIT_PATH
519 Controls where systemd looks for unit files.
520 $SYSTEMD_SYSVINIT_PATH
522 Controls where systemd looks for SysV init scripts.
523 $SYSTEMD_SYSVRCND_PATH
525 Controls where systemd looks for SysV init script runlevel link
526 farms.
527 $SYSTEMD_COLORS
529 The value must be a boolean. Controls whether colorized output
530 should be generated. This can be specified to override the decision
531 that systemd makes based on $TERM and what the console is connected
532 to.
533 $SYSTEMD_URLIFY
535 The value must be a boolean. Controls whether clickable links
536 should be generated in the output for terminal emulators supporting
537 this. This can be specified to override the decision that systemd
538 makes based on $TERM and other conditions.
539 $LISTEN_PID, $LISTEN_FDS, $LISTEN_FDNAMES
541 Set by systemd for supervised processes during socket-based
542 activation. See sd_listen_fds(3) for more information.
543 $NOTIFY_SOCKET
545 Set by systemd for supervised processes for status and start-up
546 completion notification. See sd_notify(3) for more information.
547 For further environment variables understood by systemd and its various
549 components, see Known Environment Variables[7].
550
552 When run as system instance systemd parses a number of kernel command
553 line arguments[8]:
554 systemd.unit=, rd.systemd.unit=
556 Overrides the unit to activate on boot. Defaults to default.target.
557 This may be used to temporarily boot into a different boot unit,
558 for example rescue.target or emergency.service. See
559 systemd.special(7) for details about these units. The option
560 prefixed with "rd." is honored only in the initial RAM disk
561 (initrd), while the one that is not prefixed only in the main
562 system.
563 systemd.dump_core
565 Takes a boolean argument or enables the option if specified without
566 an argument. If enabled, the systemd manager (PID 1) dumps core
567 when it crashes. Otherwise, no core dump is created. Defaults to
568 enabled.
569 systemd.crash_chvt
571 Takes a positive integer, or a boolean argument. Can be also
572 specified without an argument, with the same effect as a positive
573 boolean. If a positive integer (in the range 1–63) is specified,
574 the system manager (PID 1) will activate the specified virtual
575 terminal (VT) when it crashes. Defaults to disabled, meaning that
576 no such switch is attempted. If set to enabled, the VT the kernel
577 messages are written to is selected.
578 systemd.crash_shell
580 Takes a boolean argument or enables the option if specified without
581 an argument. If enabled, the system manager (PID 1) spawns a shell
582 when it crashes, after a 10s delay. Otherwise, no shell is spawned.
583 Defaults to disabled, for security reasons, as the shell is not
584 protected by password authentication.
585 systemd.crash_reboot
587 Takes a boolean argument or enables the option if specified without
588 an argument. If enabled, the system manager (PID 1) will reboot the
589 machine automatically when it crashes, after a 10s delay.
590 Otherwise, the system will hang indefinitely. Defaults to disabled,
591 in order to avoid a reboot loop. If combined with
592 systemd.crash_shell, the system is rebooted after the shell exits.
593 systemd.confirm_spawn
595 Takes a boolean argument or a path to the virtual console where the
596 confirmation messages should be emitted. Can be also specified
597 without an argument, with the same effect as a positive boolean. If
598 enabled, the system manager (PID 1) asks for confirmation when
599 spawning processes using /dev/console. If a path or a console name
600 (such as "ttyS0") is provided, the virtual console pointed to by
601 this path or described by the give name will be used instead.
602 Defaults to disabled.
603 systemd.service_watchdogs=
605 Takes a boolean argument. If disabled, all service runtime
606 watchdogs (WatchdogSec=) and emergency actions (e.g. OnFailure= or
607 StartLimitAction=) are ignored by the system manager (PID 1); see
608 systemd.service(5). Defaults to enabled, i.e. watchdogs and failure
609 actions are processed normally. The hardware watchdog is not
610 affected by this option.
611 systemd.show_status
613 Takes a boolean argument or the constant auto. Can be also
614 specified without an argument, with the same effect as a positive
615 boolean. If enabled, the systemd manager (PID 1) shows terse
616 service status updates on the console during bootup. auto behaves
617 like false until a unit fails or there is a significant delay in
618 boot. Defaults to enabled, unless quiet is passed as kernel command
619 line option, in which case it defaults to auto. If specified
620 overrides the system manager configuration file option ShowStatus=,
621 see systemd-system.conf(5). However, the process command line
622 option --show-status= takes precedence over both this kernel
623 command line option and the configuration file option.
624 systemd.log_target=, systemd.log_level=, systemd.log_location=,
626 systemd.log_color
627 Controls log output, with the same effect as the
628 $SYSTEMD_LOG_TARGET, $SYSTEMD_LOG_LEVEL, $SYSTEMD_LOG_LOCATION,
629 $SYSTEMD_LOG_COLOR environment variables described above.
630 systemd.log_color can be specified without an argument, with the
631 same effect as a positive boolean.
632 systemd.default_standard_output=, systemd.default_standard_error=
634 Controls default standard output and error output for services,
635 with the same effect as the --default-standard-output= and
636 --default-standard-error= command line arguments described above,
637 respectively.
638 systemd.setenv=
640 Takes a string argument in the form VARIABLE=VALUE. May be used to
641 set default environment variables to add to forked child processes.
642 May be used more than once to set multiple variables.
643 systemd.machine_id=
645 Takes a 32 character hex value to be used for setting the
646 machine-id. Intended mostly for network booting where the same
647 machine-id is desired for every boot.
648 systemd.unified_cgroup_hierarchy
650 When specified without an argument or with a true argument, enables
651 the usage of unified cgroup hierarchy[9] (a.k.a. cgroups-v2). When
652 specified with a false argument, fall back to hybrid or full legacy
653 cgroup hierarchy.
654 If this option is not specified, the default behaviour is
656 determined during compilation (the -Ddefault-hierarchy= meson
657 option). If the kernel does not support unified cgroup hierarchy,
658 the legacy hierarchy will be used even if this option is specified.
659 systemd.legacy_systemd_cgroup_controller
661 Takes effect if the full unified cgroup hierarchy is not used (see
662 previous option). When specified without an argument or with a true
663 argument, disables the use of "hybrid" cgroup hierarchy (i.e. a
664 cgroups-v2 tree used for systemd, and legacy cgroup hierarchy[10],
665 a.k.a. cgroups-v1, for other controllers), and forces a full
666 "legacy" mode. When specified with a false argument, enables the
667 use of "hybrid" hierarchy.
668 If this option is not specified, the default behaviour is
670 determined during compilation (the -Ddefault-hierarchy= meson
671 option). If the kernel does not support unified cgroup hierarchy,
672 the legacy hierarchy will be used even if this option is specified.
673 quiet
675 Turn off status output at boot, much like systemd.show_status=no
676 would. Note that this option is also read by the kernel itself and
677 disables kernel log output. Passing this option hence turns off the
678 usual output from both the system manager and the kernel.
679 debug
681 Turn on debugging output. This is equivalent to
682 systemd.log_level=debug. Note that this option is also read by the
683 kernel itself and enables kernel debug output. Passing this option
684 hence turns on the debug output from both the system manager and
685 the kernel.
686 emergency, rd.emergency, -b
688 Boot into emergency mode. This is equivalent to
689 systemd.unit=emergency.target or rd.systemd.unit=emergency.target,
690 respectively, and provided for compatibility reasons and to be
691 easier to type.
692 rescue, rd.rescue, single, s, S, 1
694 Boot into rescue mode. This is equivalent to
695 systemd.unit=rescue.target or rd.systemd.unit=rescue.target,
696 respectively, and provided for compatibility reasons and to be
697 easier to type.
698 2, 3, 4, 5
700 Boot into the specified legacy SysV runlevel. These are equivalent
701 to systemd.unit=runlevel2.target, systemd.unit=runlevel3.target,
702 systemd.unit=runlevel4.target, and systemd.unit=runlevel5.target,
703 respectively, and provided for compatibility reasons and to be
704 easier to type.
705 locale.LANG=, locale.LANGUAGE=, locale.LC_CTYPE=, locale.LC_NUMERIC=,
707 locale.LC_TIME=, locale.LC_COLLATE=, locale.LC_MONETARY=,
708 locale.LC_MESSAGES=, locale.LC_PAPER=, locale.LC_NAME=,
709 locale.LC_ADDRESS=, locale.LC_TELEPHONE=, locale.LC_MEASUREMENT=,
710 locale.LC_IDENTIFICATION=
711 Set the system locale to use. This overrides the settings in
712 /etc/locale.conf. For more information, see locale.conf(5) and
713 locale(7).
714 For other kernel command line parameters understood by components of
716 the core OS, please refer to kernel-command-line(7).
717
719 /run/systemd/notify
720 Daemon status notification socket. This is an AF_UNIX datagram
721 socket and is used to implement the daemon notification logic as
722 implemented by sd_notify(3).
723 /run/systemd/private
725 Used internally as communication channel between systemctl(1) and
726 the systemd process. This is an AF_UNIX stream socket. This
727 interface is private to systemd and should not be used in external
728 projects.
729 /dev/initctl
731 Limited compatibility support for the SysV client interface, as
732 implemented by the systemd-initctl.service unit. This is a named
733 pipe in the file system. This interface is obsolete and should not
734 be used in new applications.
735
737 The systemd Homepage[11], systemd-system.conf(5), locale.conf(5),
738 systemctl(1), journalctl(1), systemd-notify(1), daemon(7), sd-
739 daemon(3), systemd.unit(5), systemd.special(5), pkg-config(1), kernel-
740 command-line(7), bootup(7), systemd.directives(7)
741
743 1. cgroups.txt
744 https://www.kernel.org/doc/Documentation/cgroup-v1/cgroups.txt
745 2. Original Design Document
747 http://0pointer.de/blog/projects/systemd.html
748 3. Interface Stability Promise
750 https://www.freedesktop.org/wiki/Software/systemd/InterfaceStabilityPromise
751 4. Container Interface
753 https://www.freedesktop.org/wiki/Software/systemd/ContainerInterface
754 5. initrd Interface
756 https://www.freedesktop.org/wiki/Software/systemd/InitrdInterface
757 6. XDG Base Directory specification
759 http://standards.freedesktop.org/basedir-spec/basedir-spec-latest.html
760 7. Known Environment Variables
762 https://systemd.io/ENVIRONMENT
763 8. If run inside a Linux container these arguments may be passed as
765 command line arguments to systemd itself, next to any of the
766 command line options listed in the Options section above. If run
767 outside of Linux containers, these arguments are parsed from
768 /proc/cmdline instead.
769 9. unified cgroup hierarchy
771 https://www.kernel.org/doc/Documentation/cgroup-v2.txt
772 10. legacy cgroup hierarchy
774 https://www.kernel.org/doc/Documentation/cgroup-v1/
775 11. systemd Homepage
777 https://www.freedesktop.org/wiki/Software/systemd/
778systemd 241 SYSTEMD(1)