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 the initial start-up transaction (i.e. the list of jobs
35 enqueued at start-up), dump it and exit — without actually
36 executing any of the determined jobs. This option is useful for
37 debugging only. Note that during regular service manager start-up
38 additional units not shown by this operation may be started,
39 because hardware, socket, bus or other kinds of activation might
40 add additional jobs as the transaction is executed. Use --system to
41 request the initial transaction of the system service manager (this
42 is also the implied default), combine with --user to request the
43 initial transaction of the per-user service manager instead.
44 --dump-configuration-items
46 Dump understood unit configuration items. This outputs a terse but
47 complete list of configuration items understood in unit definition
48 files.
49 --dump-bus-properties
51 Dump exposed bus properties. This outputs a terse but complete list
52 of properties exposed on D-Bus.
53 --unit=
55 Set default unit to activate on startup. If not specified, defaults
56 to default.target.
57 --system, --user
59 When used in conjunction with --test, selects whether to calculate
60 the initial transaction for the system instance or for a per-user
61 instance. These options have no effect when invoked without --test,
62 as during regular (i.e. non---test) invocations the service manager
63 will automatically detect whether it shall operate in system or
64 per-user mode, by checking whether the PID it is run as is 1 or
65 not. Note that it is not supported booting and maintaining a system
66 with the service manager running in --system mode but with a PID
67 other than 1.
68 --dump-core
70 Enable core dumping on crash. This switch has no effect when
71 running as user instance. This setting may also be enabled during
72 boot on the kernel command line via the systemd.dump_core= option,
73 see below.
74 --crash-vt=VT
76 Switch to a specific virtual console (VT) on crash. Takes a
77 positive integer in the range 1–63, or a boolean argument. If an
78 integer is passed, selects which VT to switch to. If yes, the VT
79 kernel messages are written to is selected. If no, no VT switch is
80 attempted. This switch has no effect when running as user instance.
81 This setting may also be enabled during boot, on the kernel command
82 line via the systemd.crash_vt= option, see below.
83 --crash-shell
85 Run a shell on crash. This switch has no effect when running as
86 user instance. This setting may also be enabled during boot, on the
87 kernel command line via the systemd.crash_shell= option, see below.
88 --crash-reboot
90 Automatically reboot the system on crash. This switch has no effect
91 when running as user instance. This setting may also be enabled
92 during boot, on the kernel command line via the
93 systemd.crash_reboot= option, see below.
94 --confirm-spawn
96 Ask for confirmation when spawning processes. This switch has no
97 effect when run as user instance.
98 --show-status=
100 Takes a boolean argument or the special value auto. If on, terse
101 unit status information is shown on the console during boot-up and
102 shutdown. If off, no such status information is shown. If set to
103 auto behavior is similar to off, except that it is automatically
104 switched to on, as soon as the first unit failure or significant
105 boot delay is encountered. This switch has no effect when invoked
106 as user instance. If specified, overrides both the kernel command
107 line setting systemd.show_status= (see below) and the configuration
108 file option ShowStatus=, see systemd-system.conf(5).
109 --log-target=
111 Set log target. Argument must be one of console, journal, kmsg,
112 journal-or-kmsg, null.
113 --log-level=
115 Set log level. As argument this accepts a numerical log level or
116 the well-known syslog(3) symbolic names (lowercase): emerg, alert,
117 crit, err, warning, notice, info, debug.
118 --log-color=
120 Highlight important log messages. Argument is a boolean value. If
121 the argument is omitted, it defaults to true.
122 --log-location=
124 Include code location in log messages. This is mostly relevant for
125 debugging purposes. Argument is a boolean value. If the argument is
126 omitted it defaults to true.
127 --default-standard-output=, --default-standard-error=
129 Sets the default output or error output for all services and
130 sockets, respectively. That is, controls the default for
131 StandardOutput= and StandardError= (see systemd.exec(5) for
132 details). Takes one of inherit, null, tty, journal,
133 journal+console, kmsg, kmsg+console. If the argument is omitted
134 --default-standard-output= defaults to journal and
135 --default-standard-error= to inherit.
136 --machine-id=
138 Override the machine-id set on the hard drive, useful for network
139 booting or for containers. May not be set to all zeros.
140 --service-watchdogs=
142 Globally enable/disable all service watchdog timeouts and emergency
143 actions. This setting may also be specified during boot, on the
144 kernel command line via the systemd.service_watchdogs= option, see
145 below. Defaults to enabled.
146 -h, --help
148 Print a short help text and exit.
149 --version
151 Print a short version string and exit.
152
154 systemd provides a dependency system between various entities called
155 "units" of 11 different types. Units encapsulate various objects that
156 are relevant for system boot-up and maintenance. The majority of units
157 are configured in unit configuration files, whose syntax and basic set
158 of options is described in systemd.unit(5), however some are created
159 automatically from other configuration, dynamically from system state
160 or programmatically at runtime. Units may be "active" (meaning started,
161 bound, plugged in, ..., depending on the unit type, see below), or
162 "inactive" (meaning stopped, unbound, unplugged, ...), as well as in
163 the process of being activated or deactivated, i.e. between the two
164 states (these states are called "activating", "deactivating"). A
165 special "failed" state is available as well, which is very similar to
166 "inactive" and is entered when the service failed in some way (process
167 returned error code on exit, or crashed, an operation timed out, or
168 after too many restarts). If this state is entered, the cause will be
169 logged, for later reference. Note that the various unit types may have
170 a number of additional substates, which are mapped to the five
171 generalized unit states described here.
172 The following unit types are available:
174 1. Service units, which start and control daemons and the processes
176 they consist of. For details, see systemd.service(5).
177 2. Socket units, which encapsulate local IPC or network sockets in the
179 system, useful for socket-based activation. For details about
180 socket units, see systemd.socket(5), for details on socket-based
181 activation and other forms of activation, see daemon(7).
182 3. Target units are useful to group units, or provide well-known
184 synchronization points during boot-up, see systemd.target(5).
185 4. Device units expose kernel devices in systemd and may be used to
187 implement device-based activation. For details, see
188 systemd.device(5).
189 5. Mount units control mount points in the file system, for details
191 see systemd.mount(5).
192 6. Automount units provide automount capabilities, for on-demand
194 mounting of file systems as well as parallelized boot-up. See
195 systemd.automount(5).
196 7. Timer units are useful for triggering activation of other units
198 based on timers. You may find details in systemd.timer(5).
199 8. Swap units are very similar to mount units and encapsulate memory
201 swap partitions or files of the operating system. They are
202 described in systemd.swap(5).
203 9. Path units may be used to activate other services when file system
205 objects change or are modified. See systemd.path(5).
206 10. Slice units may be used to group units which manage system
208 processes (such as service and scope units) in a hierarchical tree
209 for resource management purposes. See systemd.slice(5).
210 11. Scope units are similar to service units, but manage foreign
212 processes instead of starting them as well. See systemd.scope(5).
213 Units are named as their configuration files. Some units have special
215 semantics. A detailed list is available in systemd.special(7).
216 systemd knows various kinds of dependencies, including positive and
218 negative requirement dependencies (i.e. Requires= and Conflicts=) as
219 well as ordering dependencies (After= and Before=). NB: ordering and
220 requirement dependencies are orthogonal. If only a requirement
221 dependency exists between two units (e.g. foo.service requires
222 bar.service), but no ordering dependency (e.g. foo.service after
223 bar.service) and both are requested to start, they will be started in
224 parallel. It is a common pattern that both requirement and ordering
225 dependencies are placed between two units. Also note that the majority
226 of dependencies are implicitly created and maintained by systemd. In
227 most cases, it should be unnecessary to declare additional dependencies
228 manually, however it is possible to do this.
229 Application programs and units (via dependencies) may request state
231 changes of units. In systemd, these requests are encapsulated as 'jobs'
232 and maintained in a job queue. Jobs may succeed or can fail, their
233 execution is ordered based on the ordering dependencies of the units
234 they have been scheduled for.
235 On boot systemd activates the target unit default.target whose job is
237 to activate on-boot services and other on-boot units by pulling them in
238 via dependencies. Usually, the unit name is just an alias (symlink) for
239 either graphical.target (for fully-featured boots into the UI) or
240 multi-user.target (for limited console-only boots for use in embedded
241 or server environments, or similar; a subset of graphical.target).
242 However, it is at the discretion of the administrator to configure it
243 as an alias to any other target unit. See systemd.special(7) for
244 details about these target units.
245 systemd only keeps a minimal set of units loaded into memory.
247 Specifically, the only units that are kept loaded into memory are those
248 for which at least one of the following conditions is true:
249 1. It is in an active, activating, deactivating or failed state (i.e.
251 in any unit state except for "inactive")
252 2. It has a job queued for it
254 3. It is a dependency of some sort of at least one other unit that is
256 loaded into memory
257 4. It has some form of resource still allocated (e.g. a service unit
259 that is inactive but for which a process is still lingering that
260 ignored the request to be terminated)
261 5. It has been pinned into memory programmatically by a D-Bus call
263 systemd will automatically and implicitly load units from disk — if
265 they are not loaded yet — as soon as operations are requested for them.
266 Thus, in many respects, the fact whether a unit is loaded or not is
267 invisible to clients. Use systemctl list-units --all to comprehensively
268 list all units currently loaded. Any unit for which none of the
269 conditions above applies is promptly unloaded. Note that when a unit is
270 unloaded from memory its accounting data is flushed out too. However,
271 this data is generally not lost, as a journal log record is generated
272 declaring the consumed resources whenever a unit shuts down.
273 Processes systemd spawns are placed in individual Linux control groups
275 named after the unit which they belong to in the private systemd
276 hierarchy. (see cgroups.txt[1] for more information about control
277 groups, or short "cgroups"). systemd uses this to effectively keep
278 track of processes. Control group information is maintained in the
279 kernel, and is accessible via the file system hierarchy (beneath
280 /sys/fs/cgroup/systemd/), or in tools such as systemd-cgls(1) or ps(1)
281 (ps xawf -eo pid,user,cgroup,args is particularly useful to list all
282 processes and the systemd units they belong to.).
283 systemd is compatible with the SysV init system to a large degree: SysV
285 init scripts are supported and simply read as an alternative (though
286 limited) configuration file format. The SysV /dev/initctl interface is
287 provided, and compatibility implementations of the various SysV client
288 tools are available. In addition to that, various established Unix
289 functionality such as /etc/fstab or the utmp database are supported.
290 systemd has a minimal transaction system: if a unit is requested to
292 start up or shut down it will add it and all its dependencies to a
293 temporary transaction. Then, it will verify if the transaction is
294 consistent (i.e. whether the ordering of all units is cycle-free). If
295 it is not, systemd will try to fix it up, and removes non-essential
296 jobs from the transaction that might remove the loop. Also, systemd
297 tries to suppress non-essential jobs in the transaction that would stop
298 a running service. Finally it is checked whether the jobs of the
299 transaction contradict jobs that have already been queued, and
300 optionally the transaction is aborted then. If all worked out and the
301 transaction is consistent and minimized in its impact it is merged with
302 all already outstanding jobs and added to the run queue. Effectively
303 this means that before executing a requested operation, systemd will
304 verify that it makes sense, fixing it if possible, and only failing if
305 it really cannot work.
306 Note that transactions are generated independently of a unit's state at
308 runtime, hence, for example, if a start job is requested on an already
309 started unit, it will still generate a transaction and wake up any
310 inactive dependencies (and cause propagation of other jobs as per the
311 defined relationships). This is because the enqueued job is at the time
312 of execution compared to the target unit's state and is marked
313 successful and complete when both satisfy. However, this job also pulls
314 in other dependencies due to the defined relationships and thus leads
315 to, in our our example, start jobs for any of those inactive units
316 getting queued as well.
317 systemd contains native implementations of various tasks that need to
319 be executed as part of the boot process. For example, it sets the
320 hostname or configures the loopback network device. It also sets up and
321 mounts various API file systems, such as /sys or /proc.
322 For more information about the concepts and ideas behind systemd,
324 please refer to the Original Design Document[2].
325 Note that some but not all interfaces provided by systemd are covered
327 by the Interface Stability Promise[3].
328 Units may be generated dynamically at boot and system manager reload
330 time, for example based on other configuration files or parameters
331 passed on the kernel command line. For details, see
332 systemd.generator(7).
333 Systems which invoke systemd in a container or initrd environment
335 should implement the Container Interface[4] or initrd Interface[5]
336 specifications, respectively.
337
339 System unit directories
340 The systemd system manager reads unit configuration from various
341 directories. Packages that want to install unit files shall place
342 them in the directory returned by pkg-config systemd
343 --variable=systemdsystemunitdir. Other directories checked are
344 /usr/local/lib/systemd/system and /usr/lib/systemd/system. User
345 configuration always takes precedence. pkg-config systemd
346 --variable=systemdsystemconfdir returns the path of the system
347 configuration directory. Packages should alter the content of these
348 directories only with the enable and disable commands of the
349 systemctl(1) tool. Full list of directories is provided in
350 systemd.unit(5).
351 User unit directories
353 Similar rules apply for the user unit directories. However, here
354 the XDG Base Directory specification[6] is followed to find units.
355 Applications should place their unit files in the directory
356 returned by pkg-config systemd --variable=systemduserunitdir.
357 Global configuration is done in the directory reported by
358 pkg-config systemd --variable=systemduserconfdir. The enable and
359 disable commands of the systemctl(1) tool can handle both global
360 (i.e. for all users) and private (for one user) enabling/disabling
361 of units. Full list of directories is provided in systemd.unit(5).
362 SysV init scripts directory
364 The location of the SysV init script directory varies between
365 distributions. If systemd cannot find a native unit file for a
366 requested service, it will look for a SysV init script of the same
367 name (with the .service suffix removed).
368 SysV runlevel link farm directory
370 The location of the SysV runlevel link farm directory varies
371 between distributions. systemd will take the link farm into account
372 when figuring out whether a service shall be enabled. Note that a
373 service unit with a native unit configuration file cannot be
374 started by activating it in the SysV runlevel link farm.
375
377 SIGTERM
378 Upon receiving this signal the systemd system manager serializes
379 its state, reexecutes itself and deserializes the saved state
380 again. This is mostly equivalent to systemctl daemon-reexec.
381 systemd user managers will start the exit.target unit when this
383 signal is received. This is mostly equivalent to systemctl --user
384 start exit.target --job-mode=replace-irreversibly.
385 SIGINT
387 Upon receiving this signal the systemd system manager will start
388 the ctrl-alt-del.target unit. This is mostly equivalent to
389 systemctl start ctrl-alt-del.target
390 --job-mode=replace-irreversibly. If this signal is received more
391 than 7 times per 2s, an immediate reboot is triggered. Note that
392 pressing Ctrl+Alt+Del on the console will trigger this signal.
393 Hence, if a reboot is hanging, pressing Ctrl+Alt+Del more than 7
394 times in 2 seconds is a relatively safe way to trigger an immediate
395 reboot.
396 systemd user managers treat this signal the same way as SIGTERM.
398 SIGWINCH
400 When this signal is received the systemd system manager will start
401 the kbrequest.target unit. This is mostly equivalent to systemctl
402 start kbrequest.target.
403 This signal is ignored by systemd user managers.
405 SIGPWR
407 When this signal is received the systemd manager will start the
408 sigpwr.target unit. This is mostly equivalent to systemctl start
409 sigpwr.target.
410 SIGUSR1
412 When this signal is received the systemd manager will try to
413 reconnect to the D-Bus bus.
414 SIGUSR2
416 When this signal is received the systemd manager will log its
417 complete state in human-readable form. The data logged is the same
418 as printed by systemd-analyze dump.
419 SIGHUP
421 Reloads the complete daemon configuration. This is mostly
422 equivalent to systemctl daemon-reload.
423 SIGRTMIN+0
425 Enters default mode, starts the default.target unit. This is mostly
426 equivalent to systemctl isolate default.target.
427 SIGRTMIN+1
429 Enters rescue mode, starts the rescue.target unit. This is mostly
430 equivalent to systemctl isolate rescue.target.
431 SIGRTMIN+2
433 Enters emergency mode, starts the emergency.service unit. This is
434 mostly equivalent to systemctl isolate emergency.service.
435 SIGRTMIN+3
437 Halts the machine, starts the halt.target unit. This is mostly
438 equivalent to systemctl start halt.target
439 --job-mode=replace-irreversibly.
440 SIGRTMIN+4
442 Powers off the machine, starts the poweroff.target unit. This is
443 mostly equivalent to systemctl start poweroff.target
444 --job-mode=replace-irreversibly.
445 SIGRTMIN+5
447 Reboots the machine, starts the reboot.target unit. This is mostly
448 equivalent to systemctl start reboot.target
449 --job-mode=replace-irreversibly.
450 SIGRTMIN+6
452 Reboots the machine via kexec, starts the kexec.target unit. This
453 is mostly equivalent to systemctl start kexec.target
454 --job-mode=replace-irreversibly.
455 SIGRTMIN+13
457 Immediately halts the machine.
458 SIGRTMIN+14
460 Immediately powers off the machine.
461 SIGRTMIN+15
463 Immediately reboots the machine.
464 SIGRTMIN+16
466 Immediately reboots the machine with kexec.
467 SIGRTMIN+20
469 Enables display of status messages on the console, as controlled
470 via systemd.show_status=1 on the kernel command line.
471 SIGRTMIN+21
473 Disables display of status messages on the console, as controlled
474 via systemd.show_status=0 on the kernel command line.
475 SIGRTMIN+22
477 Sets the service manager's log level to "debug", in a fashion
478 equivalent to systemd.log_level=debug on the kernel command line.
479 SIGRTMIN+23
481 Restores the log level to its configured value. The configured
482 value is derived from – in order of priority – the value specified
483 with systemd.log-level= on the kernel command line, or the value
484 specified with LogLevel= in the configuration file, or the built-in
485 default of "info".
486 SIGRTMIN+24
488 Immediately exits the manager (only available for --user
489 instances).
490 SIGRTMIN+26
492 Restores the log target to its configured value. The configured
493 value is derived from – in order of priority – the value specified
494 with systemd.log-target= on the kernel command line, or the value
495 specified with LogTarget= in the configuration file, or the
496 built-in default.
497 SIGRTMIN+27, SIGRTMIN+28
499 Sets the log target to "console" on SIGRTMIN+27 (or "kmsg" on
500 SIGRTMIN+28), in a fashion equivalent to systemd.log_target=console
501 (or systemd.log_target=kmsg on SIGRTMIN+28) on the kernel command
502 line.
503
505 $SYSTEMD_LOG_LEVEL
506 systemd reads the log level from this environment variable. This
507 can be overridden with --log-level=.
508 $SYSTEMD_LOG_TARGET
510 systemd reads the log target from this environment variable. This
511 can be overridden with --log-target=.
512 $SYSTEMD_LOG_COLOR
514 Controls whether systemd highlights important log messages. This
515 can be overridden with --log-color=.
516 $SYSTEMD_LOG_LOCATION
518 Controls whether systemd prints the code location along with log
519 messages. This can be overridden with --log-location=.
520 $XDG_CONFIG_HOME, $XDG_CONFIG_DIRS, $XDG_DATA_HOME, $XDG_DATA_DIRS
522 The systemd user manager uses these variables in accordance to the
523 XDG Base Directory specification[6] to find its configuration.
524 $SYSTEMD_UNIT_PATH
526 Controls where systemd looks for unit files.
527 $SYSTEMD_SYSVINIT_PATH
529 Controls where systemd looks for SysV init scripts.
530 $SYSTEMD_SYSVRCND_PATH
532 Controls where systemd looks for SysV init script runlevel link
533 farms.
534 $SYSTEMD_PAGER
536 Pager to use when --no-pager is not given; overrides $PAGER. If
537 neither $SYSTEMD_PAGER nor $PAGER are set, a set of well-known
538 pager implementations are tried in turn, including less(1) and
539 more(1), until one is found. If no pager implementation is
540 discovered no pager is invoked. Setting this environment variable
541 to an empty string or the value "cat" is equivalent to passing
542 --no-pager.
543 $SYSTEMD_LESS
545 Override the options passed to less (by default "FRSXMK").
546 Users might want to change two options in particular:
548 K
550 This option instructs the pager to exit immediately when Ctrl+C
551 is pressed. To allow less to handle Ctrl+C itself to switch
552 back to the pager command prompt, unset this option.
553 If the value of $SYSTEMD_LESS does not include "K", and the
555 pager that is invoked is less, Ctrl+C will be ignored by the
556 executable, and needs to be handled by the pager.
557 X
559 This option instructs the pager to not send termcap
560 initialization and deinitialization strings to the terminal. It
561 is set by default to allow command output to remain visible in
562 the terminal even after the pager exits. Nevertheless, this
563 prevents some pager functionality from working, in particular
564 paged output cannot be scrolled with the mouse.
565 See less(1) for more discussion.
567 $SYSTEMD_LESSCHARSET
569 Override the charset passed to less (by default "utf-8", if the
570 invoking terminal is determined to be UTF-8 compatible).
571 $SYSTEMD_COLORS
573 The value must be a boolean. Controls whether colorized output
574 should be generated. This can be specified to override the decision
575 that systemd makes based on $TERM and what the console is connected
576 to.
577 $SYSTEMD_URLIFY
579 The value must be a boolean. Controls whether clickable links
580 should be generated in the output for terminal emulators supporting
581 this. This can be specified to override the decision that systemd
582 makes based on $TERM and other conditions.
583 $LISTEN_PID, $LISTEN_FDS, $LISTEN_FDNAMES
585 Set by systemd for supervised processes during socket-based
586 activation. See sd_listen_fds(3) for more information.
587 $NOTIFY_SOCKET
589 Set by systemd for supervised processes for status and start-up
590 completion notification. See sd_notify(3) for more information.
591 For further environment variables understood by systemd and its various
593 components, see Known Environment Variables[7].
594
596 When run as system instance systemd parses a number of kernel command
597 line arguments[8]:
598 systemd.unit=, rd.systemd.unit=
600 Overrides the unit to activate on boot. Defaults to default.target.
601 This may be used to temporarily boot into a different boot unit,
602 for example rescue.target or emergency.service. See
603 systemd.special(7) for details about these units. The option
604 prefixed with "rd." is honored only in the initial RAM disk
605 (initrd), while the one that is not prefixed only in the main
606 system.
607 systemd.dump_core
609 Takes a boolean argument or enables the option if specified without
610 an argument. If enabled, the systemd manager (PID 1) dumps core
611 when it crashes. Otherwise, no core dump is created. Defaults to
612 enabled.
613 systemd.crash_chvt
615 Takes a positive integer, or a boolean argument. Can be also
616 specified without an argument, with the same effect as a positive
617 boolean. If a positive integer (in the range 1–63) is specified,
618 the system manager (PID 1) will activate the specified virtual
619 terminal (VT) when it crashes. Defaults to disabled, meaning that
620 no such switch is attempted. If set to enabled, the VT the kernel
621 messages are written to is selected.
622 systemd.crash_shell
624 Takes a boolean argument or enables the option if specified without
625 an argument. If enabled, the system manager (PID 1) spawns a shell
626 when it crashes, after a 10s delay. Otherwise, no shell is spawned.
627 Defaults to disabled, for security reasons, as the shell is not
628 protected by password authentication.
629 systemd.crash_reboot
631 Takes a boolean argument or enables the option if specified without
632 an argument. If enabled, the system manager (PID 1) will reboot the
633 machine automatically when it crashes, after a 10s delay.
634 Otherwise, the system will hang indefinitely. Defaults to disabled,
635 in order to avoid a reboot loop. If combined with
636 systemd.crash_shell, the system is rebooted after the shell exits.
637 systemd.confirm_spawn
639 Takes a boolean argument or a path to the virtual console where the
640 confirmation messages should be emitted. Can be also specified
641 without an argument, with the same effect as a positive boolean. If
642 enabled, the system manager (PID 1) asks for confirmation when
643 spawning processes using /dev/console. If a path or a console name
644 (such as "ttyS0") is provided, the virtual console pointed to by
645 this path or described by the give name will be used instead.
646 Defaults to disabled.
647 systemd.service_watchdogs=
649 Takes a boolean argument. If disabled, all service runtime
650 watchdogs (WatchdogSec=) and emergency actions (e.g. OnFailure= or
651 StartLimitAction=) are ignored by the system manager (PID 1); see
652 systemd.service(5). Defaults to enabled, i.e. watchdogs and failure
653 actions are processed normally. The hardware watchdog is not
654 affected by this option.
655 systemd.show_status
657 Takes a boolean argument or the constant auto. Can be also
658 specified without an argument, with the same effect as a positive
659 boolean. If enabled, the systemd manager (PID 1) shows terse
660 service status updates on the console during bootup. auto behaves
661 like false until a unit fails or there is a significant delay in
662 boot. Defaults to enabled, unless quiet is passed as kernel command
663 line option, in which case it defaults to auto. If specified
664 overrides the system manager configuration file option ShowStatus=,
665 see systemd-system.conf(5). However, the process command line
666 option --show-status= takes precedence over both this kernel
667 command line option and the configuration file option.
668 systemd.status_unit_format=
670 Takes either name or description as the value. If name, the system
671 manager will use unit names in status messages. If specified,
672 overrides the system manager configuration file option
673 StatusUnitFormat=, see systemd-system.conf(5).
674 systemd.log_target=, systemd.log_level=, systemd.log_location=,
676 systemd.log_color
677 Controls log output, with the same effect as the
678 $SYSTEMD_LOG_TARGET, $SYSTEMD_LOG_LEVEL, $SYSTEMD_LOG_LOCATION,
679 $SYSTEMD_LOG_COLOR environment variables described above.
680 systemd.log_color can be specified without an argument, with the
681 same effect as a positive boolean.
682 systemd.default_standard_output=, systemd.default_standard_error=
684 Controls default standard output and error output for services,
685 with the same effect as the --default-standard-output= and
686 --default-standard-error= command line arguments described above,
687 respectively.
688 systemd.setenv=
690 Takes a string argument in the form VARIABLE=VALUE. May be used to
691 set default environment variables to add to forked child processes.
692 May be used more than once to set multiple variables.
693 systemd.machine_id=
695 Takes a 32 character hex value to be used for setting the
696 machine-id. Intended mostly for network booting where the same
697 machine-id is desired for every boot.
698 systemd.unified_cgroup_hierarchy
700 When specified without an argument or with a true argument, enables
701 the usage of unified cgroup hierarchy[9] (a.k.a. cgroups-v2). When
702 specified with a false argument, fall back to hybrid or full legacy
703 cgroup hierarchy.
704 If this option is not specified, the default behaviour is
706 determined during compilation (the -Ddefault-hierarchy= meson
707 option). If the kernel does not support unified cgroup hierarchy,
708 the legacy hierarchy will be used even if this option is specified.
709 systemd.legacy_systemd_cgroup_controller
711 Takes effect if the full unified cgroup hierarchy is not used (see
712 previous option). When specified without an argument or with a true
713 argument, disables the use of "hybrid" cgroup hierarchy (i.e. a
714 cgroups-v2 tree used for systemd, and legacy cgroup hierarchy[10],
715 a.k.a. cgroups-v1, for other controllers), and forces a full
716 "legacy" mode. When specified with a false argument, enables the
717 use of "hybrid" hierarchy.
718 If this option is not specified, the default behaviour is
720 determined during compilation (the -Ddefault-hierarchy= meson
721 option). If the kernel does not support unified cgroup hierarchy,
722 the legacy hierarchy will be used even if this option is specified.
723 quiet
725 Turn off status output at boot, much like systemd.show_status=no
726 would. Note that this option is also read by the kernel itself and
727 disables kernel log output. Passing this option hence turns off the
728 usual output from both the system manager and the kernel.
729 debug
731 Turn on debugging output. This is equivalent to
732 systemd.log_level=debug. Note that this option is also read by the
733 kernel itself and enables kernel debug output. Passing this option
734 hence turns on the debug output from both the system manager and
735 the kernel.
736 emergency, rd.emergency, -b
738 Boot into emergency mode. This is equivalent to
739 systemd.unit=emergency.target or rd.systemd.unit=emergency.target,
740 respectively, and provided for compatibility reasons and to be
741 easier to type.
742 rescue, rd.rescue, single, s, S, 1
744 Boot into rescue mode. This is equivalent to
745 systemd.unit=rescue.target or rd.systemd.unit=rescue.target,
746 respectively, and provided for compatibility reasons and to be
747 easier to type.
748 2, 3, 4, 5
750 Boot into the specified legacy SysV runlevel. These are equivalent
751 to systemd.unit=runlevel2.target, systemd.unit=runlevel3.target,
752 systemd.unit=runlevel4.target, and systemd.unit=runlevel5.target,
753 respectively, and provided for compatibility reasons and to be
754 easier to type.
755 locale.LANG=, locale.LANGUAGE=, locale.LC_CTYPE=, locale.LC_NUMERIC=,
757 locale.LC_TIME=, locale.LC_COLLATE=, locale.LC_MONETARY=,
758 locale.LC_MESSAGES=, locale.LC_PAPER=, locale.LC_NAME=,
759 locale.LC_ADDRESS=, locale.LC_TELEPHONE=, locale.LC_MEASUREMENT=,
760 locale.LC_IDENTIFICATION=
761 Set the system locale to use. This overrides the settings in
762 /etc/locale.conf. For more information, see locale.conf(5) and
763 locale(7).
764 For other kernel command line parameters understood by components of
766 the core OS, please refer to kernel-command-line(7).
767
769 /run/systemd/notify
770 Daemon status notification socket. This is an AF_UNIX datagram
771 socket and is used to implement the daemon notification logic as
772 implemented by sd_notify(3).
773 /run/systemd/private
775 Used internally as communication channel between systemctl(1) and
776 the systemd process. This is an AF_UNIX stream socket. This
777 interface is private to systemd and should not be used in external
778 projects.
779 /dev/initctl
781 Limited compatibility support for the SysV client interface, as
782 implemented by the systemd-initctl.service unit. This is a named
783 pipe in the file system. This interface is obsolete and should not
784 be used in new applications.
785
787 The systemd Homepage[11], systemd-system.conf(5), locale.conf(5),
788 systemctl(1), journalctl(1), systemd-notify(1), daemon(7), sd-
789 daemon(3), systemd.unit(5), systemd.special(5), pkg-config(1), kernel-
790 command-line(7), bootup(7), systemd.directives(7)
791
793 1. cgroups.txt
794 https://www.kernel.org/doc/Documentation/cgroup-v1/cgroups.txt
795 2. Original Design Document
797 http://0pointer.de/blog/projects/systemd.html
798 3. Interface Stability Promise
800 https://www.freedesktop.org/wiki/Software/systemd/InterfaceStabilityPromise
801 4. Container Interface
803 https://www.freedesktop.org/wiki/Software/systemd/ContainerInterface
804 5. initrd Interface
806 https://www.freedesktop.org/wiki/Software/systemd/InitrdInterface
807 6. XDG Base Directory specification
809 http://standards.freedesktop.org/basedir-spec/basedir-spec-latest.html
810 7. Known Environment Variables
812 https://systemd.io/ENVIRONMENT
813 8. If run inside a Linux container these arguments may be passed as
815 command line arguments to systemd itself, next to any of the
816 command line options listed in the Options section above. If run
817 outside of Linux containers, these arguments are parsed from
818 /proc/cmdline instead.
819 9. unified cgroup hierarchy
821 https://www.kernel.org/doc/Documentation/cgroup-v2.txt
822 10. legacy cgroup hierarchy
824 https://www.kernel.org/doc/Documentation/cgroup-v1/
825 11. systemd Homepage
827 https://www.freedesktop.org/wiki/Software/systemd/
828systemd 243 SYSTEMD(1)