1<?xml version='1.0'?> 2<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN" 3 "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd"> 4<!-- SPDX-License-Identifier: LGPL-2.1-or-later --> 5 6<refentry id="systemd" 7 xmlns:xi="http://www.w3.org/2001/XInclude"> 8 9 <refentryinfo> 10 <title>systemd</title> 11 <productname>systemd</productname> 12 </refentryinfo> 13 14 <refmeta> 15 <refentrytitle>systemd</refentrytitle> 16 <manvolnum>1</manvolnum> 17 </refmeta> 18 19 <refnamediv> 20 <refname>systemd</refname> 21 <refname>init</refname> 22 <refpurpose>systemd system and service manager</refpurpose> 23 </refnamediv> 24 25 <refsynopsisdiv> 26 <cmdsynopsis> 27 <command>/usr/lib/systemd/systemd</command> 28 <arg choice="opt" rep="repeat">OPTIONS</arg> 29 </cmdsynopsis> 30 <cmdsynopsis> 31 <command>init</command> 32 <arg choice="opt" rep="repeat">OPTIONS</arg> 33 <arg choice="req">COMMAND</arg> 34 </cmdsynopsis> 35 </refsynopsisdiv> 36 37 <refsect1> 38 <title>Description</title> 39 40 <para>systemd is a system and service manager for Linux operating systems. When run as first process on 41 boot (as PID 1), it acts as init system that brings up and maintains userspace services. Separate 42 instances are started for logged-in users to start their services.</para> 43 44 <para><command>systemd</command> is usually not invoked directly by the user, but is installed as the 45 <filename>/sbin/init</filename> symlink and started during early boot. The user manager instances are 46 started automatically through the 47 <citerefentry><refentrytitle>user@.service</refentrytitle><manvolnum>5</manvolnum></citerefentry> 48 service.</para> 49 50 <para>For compatibility with SysV, if the binary is called as <command>init</command> and is not the 51 first process on the machine (PID is not 1), it will execute <command>telinit</command> and pass all 52 command line arguments unmodified. That means <command>init</command> and <command>telinit</command> are 53 mostly equivalent when invoked from normal login sessions. See 54 <citerefentry><refentrytitle>telinit</refentrytitle><manvolnum>8</manvolnum></citerefentry> for more 55 information.</para> 56 57 <para>When run as a system instance, systemd interprets the 58 configuration file <filename>system.conf</filename> and the files 59 in <filename>system.conf.d</filename> directories; when run as a 60 user instance, systemd interprets the configuration file 61 <filename>user.conf</filename> and the files in 62 <filename>user.conf.d</filename> directories. See 63 <citerefentry><refentrytitle>systemd-system.conf</refentrytitle><manvolnum>5</manvolnum></citerefentry> 64 for more information.</para> 65 </refsect1> 66 67 <refsect1> 68 <title>Concepts</title> 69 70 <para>systemd provides a dependency system between various 71 entities called "units" of 11 different types. Units encapsulate 72 various objects that are relevant for system boot-up and 73 maintenance. The majority of units are configured in unit 74 configuration files, whose syntax and basic set of options is 75 described in 76 <citerefentry><refentrytitle>systemd.unit</refentrytitle><manvolnum>5</manvolnum></citerefentry>, 77 however some are created automatically from other configuration 78 files, dynamically from system state or programmatically at runtime. 79 Units may be "active" (meaning started, bound, plugged in, …, 80 depending on the unit type, see below), or "inactive" (meaning 81 stopped, unbound, unplugged, …), as well as in the process of 82 being activated or deactivated, i.e. between the two states (these 83 states are called "activating", "deactivating"). A special 84 "failed" state is available as well, which is very similar to 85 "inactive" and is entered when the service failed in some way 86 (process returned error code on exit, or crashed, an operation 87 timed out, or after too many restarts). If this state is entered, 88 the cause will be logged, for later reference. Note that the 89 various unit types may have a number of additional substates, 90 which are mapped to the five generalized unit states described 91 here.</para> 92 93 <para>The following unit types are available:</para> 94 95 <orderedlist> 96 <listitem><para>Service units, which start and control daemons 97 and the processes they consist of. For details, see 98 <citerefentry><refentrytitle>systemd.service</refentrytitle><manvolnum>5</manvolnum></citerefentry>.</para></listitem> 99 100 <listitem><para>Socket units, which encapsulate local IPC or 101 network sockets in the system, useful for socket-based 102 activation. For details about socket units, see 103 <citerefentry><refentrytitle>systemd.socket</refentrytitle><manvolnum>5</manvolnum></citerefentry>, 104 for details on socket-based activation and other forms of 105 activation, see 106 <citerefentry><refentrytitle>daemon</refentrytitle><manvolnum>7</manvolnum></citerefentry>.</para></listitem> 107 108 <listitem><para>Target units are useful to group units, or 109 provide well-known synchronization points during boot-up, see 110 <citerefentry><refentrytitle>systemd.target</refentrytitle><manvolnum>5</manvolnum></citerefentry>.</para></listitem> 111 112 <listitem><para>Device units expose kernel devices in systemd 113 and may be used to implement device-based activation. For 114 details, see 115 <citerefentry><refentrytitle>systemd.device</refentrytitle><manvolnum>5</manvolnum></citerefentry>.</para></listitem> 116 117 <listitem><para>Mount units control mount points in the file 118 system, for details see 119 <citerefentry><refentrytitle>systemd.mount</refentrytitle><manvolnum>5</manvolnum></citerefentry>.</para></listitem> 120 121 <listitem><para>Automount units provide automount capabilities, 122 for on-demand mounting of file systems as well as parallelized 123 boot-up. See 124 <citerefentry><refentrytitle>systemd.automount</refentrytitle><manvolnum>5</manvolnum></citerefentry>.</para></listitem> 125 126 <listitem><para>Timer units are useful for triggering activation 127 of other units based on timers. You may find details in 128 <citerefentry><refentrytitle>systemd.timer</refentrytitle><manvolnum>5</manvolnum></citerefentry>.</para></listitem> 129 130 <listitem><para>Swap units are very similar to mount units and 131 encapsulate memory swap partitions or files of the operating 132 system. They are described in 133 <citerefentry><refentrytitle>systemd.swap</refentrytitle><manvolnum>5</manvolnum></citerefentry>.</para></listitem> 134 135 <listitem><para>Path units may be used to activate other 136 services when file system objects change or are modified. See 137 <citerefentry><refentrytitle>systemd.path</refentrytitle><manvolnum>5</manvolnum></citerefentry>.</para></listitem> 138 139 <listitem><para>Slice units may be used to group units which 140 manage system processes (such as service and scope units) in a 141 hierarchical tree for resource management purposes. See 142 <citerefentry><refentrytitle>systemd.slice</refentrytitle><manvolnum>5</manvolnum></citerefentry>.</para></listitem> 143 144 <listitem><para>Scope units are similar to service units, but 145 manage foreign processes instead of starting them as well. See 146 <citerefentry><refentrytitle>systemd.scope</refentrytitle><manvolnum>5</manvolnum></citerefentry>.</para></listitem> 147 148 </orderedlist> 149 150 <para>Units are named as their configuration files. Some units 151 have special semantics. A detailed list is available in 152 <citerefentry><refentrytitle>systemd.special</refentrytitle><manvolnum>7</manvolnum></citerefentry>.</para> 153 154 <para>systemd knows various kinds of dependencies, including 155 positive and negative requirement dependencies (i.e. 156 <varname>Requires=</varname> and <varname>Conflicts=</varname>) as 157 well as ordering dependencies (<varname>After=</varname> and 158 <varname>Before=</varname>). NB: ordering and requirement 159 dependencies are orthogonal. If only a requirement dependency 160 exists between two units (e.g. <filename>foo.service</filename> 161 requires <filename>bar.service</filename>), but no ordering 162 dependency (e.g. <filename>foo.service</filename> after 163 <filename>bar.service</filename>) and both are requested to start, 164 they will be started in parallel. It is a common pattern that both 165 requirement and ordering dependencies are placed between two 166 units. Also note that the majority of dependencies are implicitly 167 created and maintained by systemd. In most cases, it should be 168 unnecessary to declare additional dependencies manually, however 169 it is possible to do this.</para> 170 171 <para>Application programs and units (via dependencies) may 172 request state changes of units. In systemd, these requests are 173 encapsulated as 'jobs' and maintained in a job queue. Jobs may 174 succeed or can fail, their execution is ordered based on the 175 ordering dependencies of the units they have been scheduled 176 for.</para> 177 178 <para>On boot systemd activates the target unit 179 <filename>default.target</filename> whose job is to activate 180 on-boot services and other on-boot units by pulling them in via 181 dependencies. Usually, the unit name is just an alias (symlink) for 182 either <filename>graphical.target</filename> (for fully-featured 183 boots into the UI) or <filename>multi-user.target</filename> (for 184 limited console-only boots for use in embedded or server 185 environments, or similar; a subset of graphical.target). However, 186 it is at the discretion of the administrator to configure it as an 187 alias to any other target unit. See 188 <citerefentry><refentrytitle>systemd.special</refentrytitle><manvolnum>7</manvolnum></citerefentry> 189 for details about these target units.</para> 190 191 <para>systemd only keeps a minimal set of units loaded into memory. Specifically, the only units that are kept 192 loaded into memory are those for which at least one of the following conditions is true:</para> 193 194 <orderedlist> 195 <listitem><para>It is in an active, activating, deactivating or failed state (i.e. in any unit state except for <literal>inactive</literal>)</para></listitem> 196 <listitem><para>It has a job queued for it</para></listitem> 197 <listitem><para>It is a dependency of at least one other unit that is loaded into memory</para></listitem> 198 <listitem><para>It has some form of resource still allocated (e.g. a service unit that is inactive but for which 199 a process is still lingering that ignored the request to be terminated)</para></listitem> 200 <listitem><para>It has been pinned into memory programmatically by a D-Bus call</para></listitem> 201 </orderedlist> 202 203 <para>systemd will automatically and implicitly load units from disk — if they are not loaded yet — as soon as 204 operations are requested for them. Thus, in many respects, the fact whether a unit is loaded or not is invisible to 205 clients. Use <command>systemctl list-units --all</command> to comprehensively list all units currently loaded. Any 206 unit for which none of the conditions above applies is promptly unloaded. Note that when a unit is unloaded from 207 memory its accounting data is flushed out too. However, this data is generally not lost, as a journal log record 208 is generated declaring the consumed resources whenever a unit shuts down.</para> 209 210 <para>Processes systemd spawns are placed in individual Linux 211 control groups named after the unit which they belong to in the 212 private systemd hierarchy. (see <ulink 213 url="https://www.kernel.org/doc/Documentation/cgroup-v1/cgroups.txt">cgroups.txt</ulink> 214 for more information about control groups, or short "cgroups"). 215 systemd uses this to effectively keep track of processes. Control 216 group information is maintained in the kernel, and is accessible 217 via the file system hierarchy (beneath 218 <filename>/sys/fs/cgroup/systemd/</filename>), or in tools such as 219 <citerefentry project='man-pages'><refentrytitle>systemd-cgls</refentrytitle><manvolnum>1</manvolnum></citerefentry> 220 or 221 <citerefentry project='man-pages'><refentrytitle>ps</refentrytitle><manvolnum>1</manvolnum></citerefentry> 222 (<command>ps xawf -eo pid,user,cgroup,args</command> is 223 particularly useful to list all processes and the systemd units 224 they belong to.).</para> 225 226 <para>systemd is compatible with the SysV init system to a large 227 degree: SysV init scripts are supported and simply read as an 228 alternative (though limited) configuration file format. The SysV 229 <filename>/dev/initctl</filename> interface is provided, and 230 compatibility implementations of the various SysV client tools are 231 available. In addition to that, various established Unix 232 functionality such as <filename>/etc/fstab</filename> or the 233 <filename>utmp</filename> database are supported.</para> 234 235 <para>systemd has a minimal transaction system: if a unit is 236 requested to start up or shut down it will add it and all its 237 dependencies to a temporary transaction. Then, it will verify if 238 the transaction is consistent (i.e. whether the ordering of all 239 units is cycle-free). If it is not, systemd will try to fix it up, 240 and removes non-essential jobs from the transaction that might 241 remove the loop. Also, systemd tries to suppress non-essential 242 jobs in the transaction that would stop a running service. Finally 243 it is checked whether the jobs of the transaction contradict jobs 244 that have already been queued, and optionally the transaction is 245 aborted then. If all worked out and the transaction is consistent 246 and minimized in its impact it is merged with all already 247 outstanding jobs and added to the run queue. Effectively this 248 means that before executing a requested operation, systemd will 249 verify that it makes sense, fixing it if possible, and only 250 failing if it really cannot work.</para> 251 252 <para>Note that transactions are generated independently of a unit's 253 state at runtime, hence, for example, if a start job is requested on an 254 already started unit, it will still generate a transaction and wake up any 255 inactive dependencies (and cause propagation of other jobs as per the 256 defined relationships). This is because the enqueued job is at the time of 257 execution compared to the target unit's state and is marked successful and 258 complete when both satisfy. However, this job also pulls in other 259 dependencies due to the defined relationships and thus leads to, in our 260 example, start jobs for any of those inactive units getting queued as 261 well.</para> 262 263 <para>systemd contains native implementations of various tasks 264 that need to be executed as part of the boot process. For example, 265 it sets the hostname or configures the loopback network device. It 266 also sets up and mounts various API file systems, such as 267 <filename>/sys/</filename> or <filename>/proc/</filename>.</para> 268 269 <para>For more information about the concepts and 270 ideas behind systemd, please refer to the 271 <ulink url="http://0pointer.de/blog/projects/systemd.html">Original Design Document</ulink>.</para> 272 273 <para>Note that some but not all interfaces provided by systemd are covered by the 274 <ulink url="https://systemd.io/PORTABILITY_AND_STABILITY/">Interface Portability and Stability Promise</ulink>.</para> 275 276 <para>Units may be generated dynamically at boot and system 277 manager reload time, for example based on other configuration 278 files or parameters passed on the kernel command line. For details, see 279 <citerefentry><refentrytitle>systemd.generator</refentrytitle><manvolnum>7</manvolnum></citerefentry>.</para> 280 281 <para>The D-Bus API of <command>systemd</command> is described in 282 <citerefentry><refentrytitle>org.freedesktop.systemd1</refentrytitle><manvolnum>5</manvolnum></citerefentry> 283 and 284 <citerefentry><refentrytitle>org.freedesktop.LogControl1</refentrytitle><manvolnum>5</manvolnum></citerefentry>. 285 </para> 286 287 <para>Systems which invoke systemd in a container or initrd environment should implement the <ulink 288 url="https://systemd.io/CONTAINER_INTERFACE">Container Interface</ulink> or 289 <ulink url="https://systemd.io/INITRD_INTERFACE/">initrd Interface</ulink> 290 specifications, respectively.</para> 291 </refsect1> 292 293 <refsect1> 294 <title>Directories</title> 295 296 <variablelist> 297 <varlistentry> 298 <term>System unit directories</term> 299 300 <listitem><para>The systemd system manager reads unit 301 configuration from various directories. Packages that want to 302 install unit files shall place them in the directory returned 303 by <command>pkg-config systemd 304 --variable=systemdsystemunitdir</command>. Other directories 305 checked are <filename>/usr/local/lib/systemd/system</filename> 306 and <filename>/usr/lib/systemd/system</filename>. User 307 configuration always takes precedence. <command>pkg-config 308 systemd --variable=systemdsystemconfdir</command> returns the 309 path of the system configuration directory. Packages should 310 alter the content of these directories only with the 311 <command>enable</command> and <command>disable</command> 312 commands of the 313 <citerefentry><refentrytitle>systemctl</refentrytitle><manvolnum>1</manvolnum></citerefentry> 314 tool. Full list of directories is provided in 315 <citerefentry><refentrytitle>systemd.unit</refentrytitle><manvolnum>5</manvolnum></citerefentry>. 316 </para></listitem> 317 </varlistentry> 318 </variablelist> 319 320 <variablelist> 321 <varlistentry> 322 <term>User unit directories</term> 323 324 <listitem><para>Similar rules apply for the user unit 325 directories. However, here the 326 <ulink url="http://standards.freedesktop.org/basedir-spec/basedir-spec-latest.html">XDG 327 Base Directory specification</ulink> is followed to find 328 units. Applications should place their unit files in the 329 directory returned by <command>pkg-config systemd 330 --variable=systemduserunitdir</command>. Global configuration 331 is done in the directory reported by <command>pkg-config 332 systemd --variable=systemduserconfdir</command>. The 333 <command>enable</command> and <command>disable</command> 334 commands of the 335 <citerefentry><refentrytitle>systemctl</refentrytitle><manvolnum>1</manvolnum></citerefentry> 336 tool can handle both global (i.e. for all users) and private 337 (for one user) enabling/disabling of units. Full list of 338 directories is provided in 339 <citerefentry><refentrytitle>systemd.unit</refentrytitle><manvolnum>5</manvolnum></citerefentry>. 340 </para></listitem> 341 </varlistentry> 342 </variablelist> 343 344 <variablelist> 345 <varlistentry> 346 <term>SysV init scripts directory</term> 347 348 <listitem><para>The location of the SysV init script directory 349 varies between distributions. If systemd cannot find a native 350 unit file for a requested service, it will look for a SysV 351 init script of the same name (with the 352 <filename>.service</filename> suffix 353 removed).</para></listitem> 354 </varlistentry> 355 </variablelist> 356 357 <variablelist> 358 <varlistentry> 359 <term>SysV runlevel link farm directory</term> 360 361 <listitem><para>The location of the SysV runlevel link farm 362 directory varies between distributions. systemd will take the 363 link farm into account when figuring out whether a service 364 shall be enabled. Note that a service unit with a native unit 365 configuration file cannot be started by activating it in the 366 SysV runlevel link farm.</para></listitem> 367 </varlistentry> 368 </variablelist> 369 </refsect1> 370 371 <refsect1> 372 <title>Signals</title> 373 374 <variablelist> 375 <varlistentry> 376 <term><constant>SIGTERM</constant></term> 377 378 <listitem><para>Upon receiving this signal the systemd system 379 manager serializes its state, reexecutes itself and 380 deserializes the saved state again. This is mostly equivalent 381 to <command>systemctl daemon-reexec</command>.</para> 382 383 <para>systemd user managers will start the 384 <filename>exit.target</filename> unit when this signal is 385 received. This is mostly equivalent to <command>systemctl 386 --user start exit.target 387 --job-mode=replace-irreversibly</command>.</para></listitem> 388 </varlistentry> 389 390 <varlistentry> 391 <term><constant>SIGINT</constant></term> 392 393 <listitem><para>Upon receiving this signal the systemd system manager will start the 394 <filename>ctrl-alt-del.target</filename> unit. This is mostly equivalent to 395 <command>systemctl start ctrl-alt-del.target --job-mode=replace-irreversibly</command>. If 396 this signal is received more than 7 times per 2s, an immediate reboot is triggered. Note 397 that pressing 398 <keycombo><keycap>Ctrl</keycap><keycap>Alt</keycap><keycap>Del</keycap></keycombo> on the 399 console will trigger this signal. Hence, if a reboot is hanging, pressing 400 <keycombo><keycap>Ctrl</keycap><keycap>Alt</keycap><keycap>Del</keycap></keycombo> more than 401 7 times in 2 seconds is a relatively safe way to trigger an immediate reboot.</para> 402 403 <para>systemd user managers treat this signal the same way as 404 <constant>SIGTERM</constant>.</para></listitem> 405 </varlistentry> 406 407 <varlistentry> 408 <term><constant>SIGWINCH</constant></term> 409 410 <listitem><para>When this signal is received the systemd 411 system manager will start the 412 <filename>kbrequest.target</filename> unit. This is mostly 413 equivalent to <command>systemctl start 414 kbrequest.target</command>.</para> 415 416 <para>This signal is ignored by systemd user 417 managers.</para></listitem> 418 </varlistentry> 419 420 <varlistentry> 421 <term><constant>SIGPWR</constant></term> 422 423 <listitem><para>When this signal is received the systemd 424 manager will start the <filename>sigpwr.target</filename> 425 unit. This is mostly equivalent to <command>systemctl start 426 sigpwr.target</command>.</para></listitem> 427 </varlistentry> 428 429 <varlistentry> 430 <term><constant>SIGUSR1</constant></term> 431 432 <listitem><para>When this signal is received the systemd 433 manager will try to reconnect to the D-Bus 434 bus.</para></listitem> 435 </varlistentry> 436 437 <varlistentry> 438 <term><constant>SIGUSR2</constant></term> 439 440 <listitem><para>When this signal is received the systemd 441 manager will log its complete state in human-readable form. 442 The data logged is the same as printed by 443 <command>systemd-analyze dump</command>.</para></listitem> 444 </varlistentry> 445 446 <varlistentry> 447 <term><constant>SIGHUP</constant></term> 448 449 <listitem><para>Reloads the complete daemon configuration. 450 This is mostly equivalent to <command>systemctl 451 daemon-reload</command>.</para></listitem> 452 </varlistentry> 453 454 <varlistentry> 455 <term><constant>SIGRTMIN+0</constant></term> 456 457 <listitem><para>Enters default mode, starts the 458 <filename>default.target</filename> unit. This is mostly 459 equivalent to <command>systemctl isolate 460 default.target</command>.</para></listitem> 461 </varlistentry> 462 463 <varlistentry> 464 <term><constant>SIGRTMIN+1</constant></term> 465 466 <listitem><para>Enters rescue mode, starts the 467 <filename>rescue.target</filename> unit. This is mostly 468 equivalent to <command>systemctl isolate 469 rescue.target</command>.</para></listitem> 470 </varlistentry> 471 472 <varlistentry> 473 <term><constant>SIGRTMIN+2</constant></term> 474 475 <listitem><para>Enters emergency mode, starts the 476 <filename>emergency.service</filename> unit. This is mostly 477 equivalent to <command>systemctl isolate 478 emergency.service</command>.</para></listitem> 479 </varlistentry> 480 481 <varlistentry> 482 <term><constant>SIGRTMIN+3</constant></term> 483 484 <listitem><para>Halts the machine, starts the 485 <filename>halt.target</filename> unit. This is mostly 486 equivalent to <command>systemctl start halt.target 487 --job-mode=replace-irreversibly</command>.</para> 488 </listitem> 489 </varlistentry> 490 491 <varlistentry> 492 <term><constant>SIGRTMIN+4</constant></term> 493 494 <listitem><para>Powers off the machine, starts the 495 <filename>poweroff.target</filename> unit. This is mostly 496 equivalent to <command>systemctl start poweroff.target 497 --job-mode=replace-irreversibly</command>.</para> 498 </listitem> 499 </varlistentry> 500 501 <varlistentry> 502 <term><constant>SIGRTMIN+5</constant></term> 503 504 <listitem><para>Reboots the machine, starts the 505 <filename>reboot.target</filename> unit. This is mostly 506 equivalent to <command>systemctl start reboot.target 507 --job-mode=replace-irreversibly</command>.</para> 508 </listitem> 509 </varlistentry> 510 511 <varlistentry> 512 <term><constant>SIGRTMIN+6</constant></term> 513 514 <listitem><para>Reboots the machine via kexec, starts the 515 <filename>kexec.target</filename> unit. This is mostly 516 equivalent to <command>systemctl start kexec.target 517 --job-mode=replace-irreversibly</command>.</para> 518 </listitem> 519 </varlistentry> 520 521 <varlistentry> 522 <term><constant>SIGRTMIN+13</constant></term> 523 524 <listitem><para>Immediately halts the machine.</para></listitem> 525 </varlistentry> 526 527 <varlistentry> 528 <term><constant>SIGRTMIN+14</constant></term> 529 530 <listitem><para>Immediately powers off the machine.</para></listitem> 531 </varlistentry> 532 533 <varlistentry> 534 <term><constant>SIGRTMIN+15</constant></term> 535 536 <listitem><para>Immediately reboots the machine.</para></listitem> 537 </varlistentry> 538 539 <varlistentry> 540 <term><constant>SIGRTMIN+16</constant></term> 541 542 <listitem><para>Immediately reboots the machine with kexec.</para></listitem> 543 </varlistentry> 544 545 <varlistentry> 546 <term><constant>SIGRTMIN+20</constant></term> 547 548 <listitem><para>Enables display of status messages on the 549 console, as controlled via 550 <varname>systemd.show_status=1</varname> on the kernel command 551 line.</para></listitem> 552 </varlistentry> 553 554 <varlistentry> 555 <term><constant>SIGRTMIN+21</constant></term> 556 557 <listitem><para>Disables display of 558 status messages on the console, as 559 controlled via 560 <varname>systemd.show_status=0</varname> 561 on the kernel command 562 line.</para></listitem> 563 </varlistentry> 564 565 <varlistentry> 566 <term><constant>SIGRTMIN+22</constant></term> 567 568 <listitem><para>Sets the service manager's log level to <literal>debug</literal>, in a fashion equivalent to 569 <varname>systemd.log_level=debug</varname> on the kernel command line.</para></listitem> 570 </varlistentry> 571 572 <varlistentry> 573 <term><constant>SIGRTMIN+23</constant></term> 574 575 <listitem><para>Restores the log level to its configured value. The configured value is derived from – in order 576 of priority – the value specified with <varname>systemd.log-level=</varname> on the kernel command line, or the 577 value specified with <option>LogLevel=</option> in the configuration file, or the built-in default of 578 <literal>info</literal>.</para></listitem> 579 </varlistentry> 580 581 <varlistentry> 582 <term><constant>SIGRTMIN+24</constant></term> 583 584 <listitem><para>Immediately exits the manager (only available 585 for --user instances).</para></listitem> 586 </varlistentry> 587 588 <varlistentry> 589 <term><constant>SIGRTMIN+25</constant></term> 590 591 <listitem><para>Upon receiving this signal the systemd manager will reexecute itself. This 592 is mostly equivalent to <command>systemctl daemon-reexec</command> except that it will be 593 done asynchronously.</para> 594 595 <para>The systemd system manager treats this signal the same way as 596 <constant>SIGTERM</constant>.</para></listitem> 597 </varlistentry> 598 599 <varlistentry> 600 <term><constant>SIGRTMIN+26</constant></term> 601 602 <listitem><para>Restores the log target to its configured value. The configured value is derived from – in 603 order of priority – the value specified with <varname>systemd.log-target=</varname> on the kernel command line, 604 or the value specified with <option>LogTarget=</option> in the configuration file, or the built-in 605 default.</para></listitem> 606 </varlistentry> 607 608 <varlistentry> 609 <term><constant>SIGRTMIN+27</constant></term> 610 <term><constant>SIGRTMIN+28</constant></term> 611 612 <listitem><para>Sets the log target to <literal>console</literal> on <constant>SIGRTMIN+27</constant> (or 613 <literal>kmsg</literal> on <constant>SIGRTMIN+28</constant>), in a fashion equivalent to 614 <varname>systemd.log_target=console</varname> (or <varname>systemd.log_target=kmsg</varname> on 615 <constant>SIGRTMIN+28</constant>) on the kernel command line.</para></listitem> 616 </varlistentry> 617 </variablelist> 618 </refsect1> 619 620 <refsect1> 621 <title>Environment</title> 622 623 <para>The environment block for the system manager is initially set by the kernel. (In particular, 624 <literal>key=value</literal> assignments on the kernel command line are turned into environment 625 variables for PID 1). For the user manager, the system manager sets the environment as described in the 626 "Environment Variables in Spawned Processes" section of 627 <citerefentry><refentrytitle>systemd.exec</refentrytitle><manvolnum>5</manvolnum></citerefentry>. The 628 <varname>DefaultEnvironment=</varname> setting in the system manager applies to all services including 629 <filename>user@.service</filename>. Additional entries may be configured (as for any other service) 630 through the <varname>Environment=</varname> and <varname>EnvironmentFile=</varname> settings for 631 <filename>user@.service</filename> (see 632 <citerefentry><refentrytitle>systemd.exec</refentrytitle><manvolnum>5</manvolnum></citerefentry>). Also, 633 additional environment variables may be set through the <varname>ManagerEnvironment=</varname> setting in 634 <citerefentry><refentrytitle>systemd-system.conf</refentrytitle><manvolnum>5</manvolnum></citerefentry> 635 and 636 <citerefentry><refentrytitle>systemd-user.conf</refentrytitle><manvolnum>5</manvolnum></citerefentry>. 637 </para> 638 639 <para>Some of the variables understood by <command>systemd</command>:</para> 640 641 <variablelist class='environment-variables'> 642 <varlistentry> 643 <term><varname>$SYSTEMD_LOG_LEVEL</varname></term> 644 <listitem><xi:include href="common-variables.xml" xpointer="log-level-body" /> 645 646 <para>This can be overridden with <option>--log-level=</option>.</para></listitem> 647 </varlistentry> 648 649 <varlistentry> 650 <term><varname>$SYSTEMD_LOG_COLOR</varname></term> 651 <listitem><xi:include href="common-variables.xml" xpointer="log-color-body" /> 652 653 <para>This can be overridden with <option>--log-color=</option>.</para></listitem> 654 </varlistentry> 655 656 <varlistentry> 657 <term><varname>$SYSTEMD_LOG_TIME</varname></term> 658 <listitem><xi:include href="common-variables.xml" xpointer="log-time-body" /> 659 660 <para>This can be overridden with <option>--log-time=</option>.</para></listitem> 661 </varlistentry> 662 663 <varlistentry> 664 <term><varname>$SYSTEMD_LOG_LOCATION</varname></term> 665 <listitem><xi:include href="common-variables.xml" xpointer="log-location-body" /> 666 667 <para>This can be overridden with <option>--log-location=</option>.</para></listitem> 668 </varlistentry> 669 670 <varlistentry> 671 <term><varname>$SYSTEMD_LOG_TID</varname></term> 672 <listitem><xi:include href="common-variables.xml" xpointer="log-tid-body" /></listitem> 673 </varlistentry> 674 675 <varlistentry> 676 <term><varname>$SYSTEMD_LOG_TARGET</varname></term> 677 <listitem><xi:include href="common-variables.xml" xpointer="log-target-body" /> 678 679 <para>This can be overridden with <option>--log-target=</option>.</para></listitem> 680 </varlistentry> 681 682 <varlistentry> 683 <term><varname>$XDG_CONFIG_HOME</varname></term> 684 <term><varname>$XDG_CONFIG_DIRS</varname></term> 685 <term><varname>$XDG_DATA_HOME</varname></term> 686 <term><varname>$XDG_DATA_DIRS</varname></term> 687 688 <listitem><para>The systemd user manager uses these variables 689 in accordance to the <ulink 690 url="http://standards.freedesktop.org/basedir-spec/basedir-spec-latest.html">XDG 691 Base Directory specification</ulink> to find its 692 configuration.</para></listitem> 693 </varlistentry> 694 695 <varlistentry> 696 <term><varname>$SYSTEMD_UNIT_PATH</varname></term> 697 <term><varname>$SYSTEMD_GENERATOR_PATH</varname></term> 698 <term><varname>$SYSTEMD_ENVIRONMENT_GENERATOR_PATH</varname></term> 699 700 <listitem><para>Controls where systemd looks for unit files and 701 generators.</para> 702 <para>These variables may contain a list of paths, separated by colons 703 (<literal>:</literal>). When set, if the list ends with an empty 704 component (<literal>...:</literal>), this list is prepended to the 705 usual set of paths. Otherwise, the specified list replaces the usual 706 set of paths. 707 </para></listitem> 708 </varlistentry> 709 710 <xi:include href="common-variables.xml" xpointer="pager"/> 711 <xi:include href="common-variables.xml" xpointer="less"/> 712 <xi:include href="common-variables.xml" xpointer="lesscharset"/> 713 <xi:include href="common-variables.xml" xpointer="lesssecure"/> 714 <xi:include href="common-variables.xml" xpointer="colors"/> 715 <xi:include href="common-variables.xml" xpointer="urlify"/> 716 717 <varlistentry> 718 <term><varname>$LISTEN_PID</varname></term> 719 <term><varname>$LISTEN_FDS</varname></term> 720 <term><varname>$LISTEN_FDNAMES</varname></term> 721 722 <listitem><para>Set by systemd for supervised processes during 723 socket-based activation. See 724 <citerefentry><refentrytitle>sd_listen_fds</refentrytitle><manvolnum>3</manvolnum></citerefentry> 725 for more information.</para></listitem> 726 </varlistentry> 727 728 <varlistentry> 729 <term><varname>$NOTIFY_SOCKET</varname></term> 730 731 <listitem><para>Set by systemd for supervised processes for 732 status and start-up completion notification. See 733 <citerefentry><refentrytitle>sd_notify</refentrytitle><manvolnum>3</manvolnum></citerefentry> 734 for more information.</para></listitem> 735 </varlistentry> 736 </variablelist> 737 738 <para>For further environment variables understood by systemd and its various components, see <ulink 739 url="https://systemd.io/ENVIRONMENT">Known Environment Variables</ulink>.</para> 740 </refsect1> 741 742 <refsect1> 743 <title>Kernel Command Line</title> 744 745 <para>When run as the system instance, systemd parses a number of options listed below. They can be 746 specified as kernel command line arguments which are parsed from a number of sources depending on the 747 environment in which systemd is executed. If run inside a Linux container, these options are parsed from 748 the command line arguments passed to systemd itself, next to any of the command line options listed in 749 the Options section above. If run outside of Linux containers, these arguments are parsed from 750 <filename>/proc/cmdline</filename> and from the <literal>SystemdOptions</literal> EFI variable 751 (on EFI systems) instead. Options from <filename>/proc/cmdline</filename> have higher priority. The 752 following variables are understood:</para> 753 754 <variablelist class='kernel-commandline-options'> 755 <varlistentry> 756 <term><varname>systemd.unit=</varname></term> 757 <term><varname>rd.systemd.unit=</varname></term> 758 759 <listitem><para>Overrides the unit to activate on boot. 760 Defaults to <filename>default.target</filename>. This may be 761 used to temporarily boot into a different boot unit, for 762 example <filename>rescue.target</filename> or 763 <filename>emergency.service</filename>. See 764 <citerefentry><refentrytitle>systemd.special</refentrytitle><manvolnum>7</manvolnum></citerefentry> 765 for details about these units. The option prefixed with 766 <literal>rd.</literal> is honored only in the initial RAM disk 767 (initrd), while the one that is not prefixed only in the main 768 system.</para></listitem> 769 </varlistentry> 770 771 <varlistentry> 772 <term><varname>systemd.dump_core</varname></term> 773 774 <listitem><para>Takes a boolean argument or enables the option if specified 775 without an argument. If enabled, the systemd manager (PID 1) dumps core when 776 it crashes. Otherwise, no core dump is created. Defaults to enabled.</para> 777 </listitem> 778 </varlistentry> 779 780 <varlistentry> 781 <term><varname>systemd.crash_chvt</varname></term> 782 783 <listitem><para>Takes a positive integer, or a boolean argument. Can be also specified without an 784 argument, with the same effect as a positive boolean. If a positive integer (in the range 1–63) is 785 specified, the system manager (PID 1) will activate the specified virtual terminal when it crashes. 786 Defaults to disabled, meaning that no such switch is attempted. If set to enabled, the virtual 787 terminal the kernel messages are written to is used instead.</para></listitem> 788 </varlistentry> 789 790 <varlistentry> 791 <term><varname>systemd.crash_shell</varname></term> 792 793 <listitem><para>Takes a boolean argument or enables the option if specified 794 without an argument. If enabled, the system manager (PID 1) spawns a shell 795 when it crashes, after a 10s delay. Otherwise, no shell is spawned. Defaults 796 to disabled, for security reasons, as the shell is not protected by password 797 authentication.</para></listitem> 798 </varlistentry> 799 800 <varlistentry> 801 <term><varname>systemd.crash_reboot</varname></term> 802 803 <listitem><para>Takes a boolean argument or enables the option if specified 804 without an argument. If enabled, the system manager (PID 1) will reboot the 805 machine automatically when it crashes, after a 10s delay. Otherwise, the 806 system will hang indefinitely. Defaults to disabled, in order to avoid a 807 reboot loop. If combined with <varname>systemd.crash_shell</varname>, the 808 system is rebooted after the shell exits.</para></listitem> 809 </varlistentry> 810 811 <varlistentry> 812 <term><varname>systemd.confirm_spawn</varname></term> 813 814 <listitem><para>Takes a boolean argument or a path to the virtual console 815 where the confirmation messages should be emitted. Can be also specified 816 without an argument, with the same effect as a positive boolean. If enabled, 817 the system manager (PID 1) asks for confirmation when spawning processes 818 using <option>/dev/console</option>. If a path or a console name (such as 819 <literal>ttyS0</literal>) is provided, the virtual console pointed to by this 820 path or described by the give name will be used instead. Defaults to disabled. 821 </para></listitem> 822 </varlistentry> 823 824 <varlistentry> 825 <term><varname>systemd.service_watchdogs=</varname></term> 826 827 <listitem><para>Takes a boolean argument. If disabled, all service runtime 828 watchdogs (<option>WatchdogSec=</option>) and emergency actions (e.g. 829 <option>OnFailure=</option> or <option>StartLimitAction=</option>) are 830 ignored by the system manager (PID 1); see 831 <citerefentry><refentrytitle>systemd.service</refentrytitle><manvolnum>5</manvolnum></citerefentry>. 832 Defaults to enabled, i.e. watchdogs and failure actions are processed 833 normally. The hardware watchdog is not affected by this 834 option.</para></listitem> 835 </varlistentry> 836 837 <varlistentry> 838 <term><varname>systemd.show_status</varname></term> 839 840 <listitem><para>Takes a boolean argument or the constants <constant>error</constant> and 841 <constant>auto</constant>. Can be also specified without an argument, with the same effect as a 842 positive boolean. If enabled, the systemd manager (PID 1) shows terse service status updates on the 843 console during bootup. With <constant>error</constant>, only messages about failures are shown, but 844 boot is otherwise quiet. <constant>auto</constant> behaves like <option>false</option> until there is 845 a significant delay in boot. Defaults to enabled, unless <option>quiet</option> is passed as kernel 846 command line option, in which case it defaults to <constant>error</constant>. If specified overrides 847 the system manager configuration file option <option>ShowStatus=</option>, see 848 <citerefentry><refentrytitle>systemd-system.conf</refentrytitle><manvolnum>5</manvolnum></citerefentry>. 849 </para></listitem> 850 </varlistentry> 851 852 <varlistentry> 853 <term><varname>systemd.status_unit_format=</varname></term> 854 855 <listitem><para>Takes <option>name</option>, <option>description</option> or 856 <option>combined</option> as the value. If <option>name</option>, the system manager will use unit 857 names in status messages. If <option>combined</option>, the system manager will use unit names and 858 description in status messages. When specified, overrides the system manager configuration file 859 option <option>StatusUnitFormat=</option>, see 860 <citerefentry><refentrytitle>systemd-system.conf</refentrytitle><manvolnum>5</manvolnum></citerefentry>. 861 </para></listitem> 862 </varlistentry> 863 864 <varlistentry> 865 <term><varname>systemd.log_color</varname></term> 866 <term><varname>systemd.log_level=</varname></term> 867 <term><varname>systemd.log_location</varname></term> 868 <term><varname>systemd.log_target=</varname></term> 869 <term><varname>systemd.log_time</varname></term> 870 <term><varname>systemd.log_tid</varname></term> 871 872 <listitem><para>Controls log output, with the same effect as the 873 <varname>$SYSTEMD_LOG_COLOR</varname>, <varname>$SYSTEMD_LOG_LEVEL</varname>, 874 <varname>$SYSTEMD_LOG_LOCATION</varname>, <varname>$SYSTEMD_LOG_TARGET</varname>, 875 <varname>$SYSTEMD_LOG_TIME</varname>, and <varname>$SYSTEMD_LOG_TID</varname> environment variables 876 described above. <varname>systemd.log_color</varname>, <varname>systemd.log_location</varname>, 877 <varname>systemd.log_time</varname>, and <varname>systemd.log_tid=</varname> can be specified without 878 an argument, with the same effect as a positive boolean.</para></listitem> 879 </varlistentry> 880 881 <varlistentry> 882 <term><varname>systemd.default_standard_output=</varname></term> 883 <term><varname>systemd.default_standard_error=</varname></term> 884 885 <listitem><para>Controls default standard output and error output for services and sockets. That is, 886 controls the default for <option>StandardOutput=</option> and <option>StandardError=</option> (see 887 <citerefentry><refentrytitle>systemd.exec</refentrytitle><manvolnum>5</manvolnum></citerefentry> for 888 details). Takes one of <option>inherit</option>, <option>null</option>, <option>tty</option>, 889 <option>journal</option>, <option>journal+console</option>, <option>kmsg</option>, 890 <option>kmsg+console</option>. If the argument is omitted 891 <varname>systemd.default-standard-output=</varname> defaults to <option>journal</option> and 892 <varname>systemd.default-standard-error=</varname> to <option>inherit</option>.</para></listitem> 893 </varlistentry> 894 895 <varlistentry> 896 <term><varname>systemd.setenv=</varname></term> 897 898 <listitem><para>Takes a string argument in the form 899 VARIABLE=VALUE. May be used to set default environment 900 variables to add to forked child processes. May be used more 901 than once to set multiple variables.</para></listitem> 902 </varlistentry> 903 904 <varlistentry> 905 <term><varname>systemd.machine_id=</varname></term> 906 907 <listitem><para>Takes a 32 character hex value to be 908 used for setting the machine-id. Intended mostly for 909 network booting where the same machine-id is desired 910 for every boot.</para></listitem> 911 </varlistentry> 912 913 <varlistentry> 914 <term><varname>systemd.unified_cgroup_hierarchy</varname></term> 915 916 <listitem><para>When specified without an argument or with a true argument, 917 enables the usage of 918 <ulink url="https://www.kernel.org/doc/html/latest/admin-guide/cgroup-v2.html">unified cgroup hierarchy</ulink> 919 (a.k.a. cgroups-v2). When specified with a false argument, fall back to 920 hybrid or full legacy cgroup hierarchy.</para> 921 922 <para>If this option is not specified, the default behaviour is determined 923 during compilation (the <option>-Ddefault-hierarchy=</option> meson 924 option). If the kernel does not support unified cgroup hierarchy, the legacy 925 hierarchy will be used even if this option is specified.</para> 926 </listitem> 927 </varlistentry> 928 929 <varlistentry> 930 <term><varname>systemd.legacy_systemd_cgroup_controller</varname></term> 931 932 <listitem><para>Takes effect if the full unified cgroup hierarchy is not used 933 (see previous option). When specified without an argument or with a true 934 argument, disables the use of "hybrid" cgroup hierarchy (i.e. a cgroups-v2 935 tree used for systemd, and 936 <ulink url="https://www.kernel.org/doc/Documentation/cgroup-v1/">legacy 937 cgroup hierarchy</ulink>, a.k.a. cgroups-v1, for other controllers), and 938 forces a full "legacy" mode. When specified with a false argument, enables 939 the use of "hybrid" hierarchy.</para> 940 941 <para>If this option is not specified, the default behaviour is determined 942 during compilation (the <option>-Ddefault-hierarchy=</option> meson 943 option). If the kernel does not support unified cgroup hierarchy, the legacy 944 hierarchy will be used even if this option is specified.</para> 945 </listitem> 946 </varlistentry> 947 948 <varlistentry> 949 <term><varname>systemd.set_credential=</varname></term> 950 951 <listitem><para>Sets a system credential, which can then be propagated to system services using the 952 <varname>LoadCredential=</varname> setting, see 953 <citerefentry><refentrytitle>systemd.exec</refentrytitle><manvolnum>5</manvolnum></citerefentry> for 954 details. Takes a pair of credential name and value, separated by a colon. Note that the kernel 955 command line is typically accessible by unprivileged programs in 956 <filename>/proc/cmdline</filename>. Thus, this mechanism is not suitable for transferring sensitive 957 data. Use it only for data that is not sensitive (e.g. public keys/certificates, rather than private 958 keys), or in testing/debugging environments.</para> 959 960 <para>For further information see <ulink url="https://systemd.io/CREDENTIALS">System and Service 961 Credentials</ulink> documentation.</para></listitem> 962 </varlistentry> 963 964 <varlistentry> 965 <term><varname>systemd.import_credentials=</varname></term> 966 967 <listitem><para>Takes a boolean argument. If false disables importing credentials from the kernel 968 command line, qemu_fw_cfg subsystem or the kernel command line.</para></listitem> 969 </varlistentry> 970 971 <varlistentry> 972 <term><varname>quiet</varname></term> 973 974 <listitem><para>Turn off status output at boot, much like 975 <varname>systemd.show_status=no</varname> would. Note that 976 this option is also read by the kernel itself and disables 977 kernel log output. Passing this option hence turns off the 978 usual output from both the system manager and the kernel. 979 </para></listitem> 980 </varlistentry> 981 982 <varlistentry> 983 <term><varname>debug</varname></term> 984 985 <listitem><para>Turn on debugging output. This is equivalent 986 to <varname>systemd.log_level=debug</varname>. Note that this 987 option is also read by the kernel itself and enables kernel 988 debug output. Passing this option hence turns on the debug 989 output from both the system manager and the 990 kernel.</para></listitem> 991 </varlistentry> 992 993 <varlistentry> 994 <term><varname>emergency</varname></term> 995 <term><varname>rd.emergency</varname></term> 996 <term><varname>-b</varname></term> 997 998 <listitem><para>Boot into emergency mode. This is equivalent 999 to <varname>systemd.unit=emergency.target</varname> or 1000 <varname>rd.systemd.unit=emergency.target</varname>, respectively, and 1001 provided for compatibility reasons and to be easier to type.</para></listitem> 1002 </varlistentry> 1003 1004 <varlistentry> 1005 <term><varname>rescue</varname></term> 1006 <term><varname>rd.rescue</varname></term> 1007 <term><varname>single</varname></term> 1008 <term><varname>s</varname></term> 1009 <term><varname>S</varname></term> 1010 <term><varname>1</varname></term> 1011 1012 <listitem><para>Boot into rescue mode. This is equivalent to 1013 <varname>systemd.unit=rescue.target</varname> or 1014 <varname>rd.systemd.unit=rescue.target</varname>, respectively, and 1015 provided for compatibility reasons and to be easier to type.</para></listitem> 1016 </varlistentry> 1017 1018 <varlistentry> 1019 <term><varname>2</varname></term> 1020 <term><varname>3</varname></term> 1021 <term><varname>4</varname></term> 1022 <term><varname>5</varname></term> 1023 1024 <listitem><para>Boot into the specified legacy SysV runlevel. 1025 These are equivalent to 1026 <varname>systemd.unit=runlevel2.target</varname>, 1027 <varname>systemd.unit=runlevel3.target</varname>, 1028 <varname>systemd.unit=runlevel4.target</varname>, and 1029 <varname>systemd.unit=runlevel5.target</varname>, 1030 respectively, and provided for compatibility reasons and to be 1031 easier to type.</para></listitem> 1032 </varlistentry> 1033 1034 <varlistentry> 1035 <term><varname>locale.LANG=</varname></term> 1036 <term><varname>locale.LANGUAGE=</varname></term> 1037 <term><varname>locale.LC_CTYPE=</varname></term> 1038 <term><varname>locale.LC_NUMERIC=</varname></term> 1039 <term><varname>locale.LC_TIME=</varname></term> 1040 <term><varname>locale.LC_COLLATE=</varname></term> 1041 <term><varname>locale.LC_MONETARY=</varname></term> 1042 <term><varname>locale.LC_MESSAGES=</varname></term> 1043 <term><varname>locale.LC_PAPER=</varname></term> 1044 <term><varname>locale.LC_NAME=</varname></term> 1045 <term><varname>locale.LC_ADDRESS=</varname></term> 1046 <term><varname>locale.LC_TELEPHONE=</varname></term> 1047 <term><varname>locale.LC_MEASUREMENT=</varname></term> 1048 <term><varname>locale.LC_IDENTIFICATION=</varname></term> 1049 1050 <listitem><para>Set the system locale to use. This overrides 1051 the settings in <filename>/etc/locale.conf</filename>. For 1052 more information, see 1053 <citerefentry project='man-pages'><refentrytitle>locale.conf</refentrytitle><manvolnum>5</manvolnum></citerefentry> 1054 and 1055 <citerefentry project='man-pages'><refentrytitle>locale</refentrytitle><manvolnum>7</manvolnum></citerefentry>. 1056 </para></listitem> 1057 </varlistentry> 1058 </variablelist> 1059 1060 <para>For other kernel command line parameters understood by 1061 components of the core OS, please refer to 1062 <citerefentry><refentrytitle>kernel-command-line</refentrytitle><manvolnum>7</manvolnum></citerefentry>.</para> 1063 </refsect1> 1064 1065 <refsect1> 1066 <title>Options</title> 1067 1068 <para><command>systemd</command> is only very rarely invoked directly, since it is started early and is 1069 already running by the time users may interact with it. Normally, tools like 1070 <citerefentry><refentrytitle>systemctl</refentrytitle><manvolnum>1</manvolnum></citerefentry> are used to 1071 give commands to the manager. Since <command>systemd</command> is usually not invoked directly, the 1072 options listed below are mostly useful for debugging and special purposes.</para> 1073 1074 <refsect2> 1075 <title>Introspection and debugging options</title> 1076 1077 <para>Those options are used for testing and introspection, and <command>systemd</command> may 1078 be invoked with them at any time:</para> 1079 1080 <variablelist> 1081 <varlistentry> 1082 <term><option>--dump-configuration-items</option></term> 1083 1084 <listitem><para>Dump understood unit configuration items. This outputs a terse but complete list of 1085 configuration items understood in unit definition files.</para></listitem> 1086 </varlistentry> 1087 1088 <varlistentry> 1089 <term><option>--dump-bus-properties</option></term> 1090 1091 <listitem><para>Dump exposed bus properties. This outputs a terse but complete list of properties 1092 exposed on D-Bus.</para></listitem> 1093 </varlistentry> 1094 1095 <varlistentry> 1096 <term><option>--test</option></term> 1097 1098 <listitem><para>Determine the initial start-up transaction (i.e. the list of jobs enqueued at 1099 start-up), dump it and exit — without actually executing any of the determined jobs. This option is 1100 useful for debugging only. Note that during regular service manager start-up additional units not 1101 shown by this operation may be started, because hardware, socket, bus or other kinds of activation 1102 might add additional jobs as the transaction is executed. Use <option>--system</option> to request 1103 the initial transaction of the system service manager (this is also the implied default), combine 1104 with <option>--user</option> to request the initial transaction of the per-user service manager 1105 instead.</para></listitem> 1106 </varlistentry> 1107 1108 <varlistentry> 1109 <term><option>--system</option></term> 1110 <term><option>--user</option></term> 1111 1112 <listitem><para>When used in conjunction with <option>--test</option>, selects whether to calculate 1113 the initial transaction for the system instance or for a per-user instance. These options have no 1114 effect when invoked without <option>--test</option>, as during regular 1115 (i.e. non-<option>--test</option>) invocations the service manager will automatically detect 1116 whether it shall operate in system or per-user mode, by checking whether the PID it is run as is 1 1117 or not. Note that it is not supported booting and maintaining a system with the service manager 1118 running in <option>--system</option> mode but with a PID other than 1.</para></listitem> 1119 </varlistentry> 1120 1121 <xi:include href="standard-options.xml" xpointer="help" /> 1122 <xi:include href="standard-options.xml" xpointer="version" /> 1123 </variablelist> 1124 </refsect2> 1125 1126 <refsect2> 1127 <title>Options that duplicate kernel command line settings</title> 1128 1129 <para>Those options correspond directly to options listed above in "Kernel Command Line". Both forms 1130 may be used equivalently for the system manager, but it is recommended to use the forms listed above in 1131 this context, because they are properly namespaced. When an option is specified both on the kernel 1132 command line and as a normal command line argument, the latter has higher precedence.</para> 1133 1134 <para>When <command>systemd</command> is used as a user manager, the kernel command line is ignored and 1135 only the options described below are understood. Nevertheless, <command>systemd</command> is usually 1136 started in this mode through the 1137 <citerefentry><refentrytitle>user@.service</refentrytitle><manvolnum>5</manvolnum></citerefentry> 1138 service, which is shared between all users. It may be more convenient to use configuration files to 1139 modify settings (see 1140 <citerefentry><refentrytitle>systemd-user.conf</refentrytitle><manvolnum>5</manvolnum></citerefentry>), 1141 or environment variables. See the "Environment" section above for a discussion of how the environment 1142 block is set.</para> 1143 1144 <variablelist> 1145 <varlistentry> 1146 <term><option>--unit=</option></term> 1147 1148 <listitem><para>Set default unit to activate on startup. If not specified, defaults to 1149 <filename>default.target</filename>. See <varname>systemd.unit=</varname> above.</para></listitem> 1150 </varlistentry> 1151 1152 <varlistentry> 1153 <term><option>--dump-core</option></term> 1154 1155 <listitem><para>Enable core dumping on crash. This switch has no effect when running as user 1156 instance. Same as <varname>systemd.dump_core=</varname> above.</para></listitem> 1157 </varlistentry> 1158 1159 <varlistentry> 1160 <term><option>--crash-vt=</option><replaceable>VT</replaceable></term> 1161 1162 <listitem><para>Switch to a specific virtual console (VT) on crash. This switch has no effect when 1163 running as user instance. Same as <varname>systemd.crash_chvt=</varname> above (but not the 1164 different spelling!).</para></listitem> 1165 </varlistentry> 1166 1167 <varlistentry> 1168 <term><option>--crash-shell</option></term> 1169 1170 <listitem><para>Run a shell on crash. This switch has no effect when running as user instance. See 1171 <varname>systemd.crash_shell=</varname> above.</para></listitem> 1172 </varlistentry> 1173 1174 <varlistentry> 1175 <term><option>--crash-reboot</option></term> 1176 1177 <listitem><para>Automatically reboot the system on crash. This switch has no effect when running as 1178 user instance. See <varname>systemd.crash_reboot</varname> above.</para></listitem> 1179 </varlistentry> 1180 1181 <varlistentry> 1182 <term><option>--confirm-spawn</option></term> 1183 1184 <listitem><para>Ask for confirmation when spawning processes. This switch has no effect when run as 1185 user instance. See <varname>systemd.confirm_spawn</varname> above.</para></listitem> 1186 </varlistentry> 1187 1188 <varlistentry> 1189 <term><option>--show-status</option></term> 1190 1191 <listitem><para>Show terse unit status information on the console during boot-up and shutdown. See 1192 <varname>systemd.show_status</varname> above.</para></listitem> 1193 </varlistentry> 1194 1195 <varlistentry> 1196 <term><option>--log-color</option></term> 1197 1198 <listitem><para>Highlight important log messages. See <varname>systemd.log_color</varname> above. 1199 </para></listitem> 1200 </varlistentry> 1201 1202 <varlistentry> 1203 <term><option>--log-level=</option></term> 1204 1205 <listitem><para>Set log level. See <varname>systemd.log_level</varname> above.</para></listitem> 1206 </varlistentry> 1207 1208 <varlistentry> 1209 <term><option>--log-location</option></term> 1210 1211 <listitem><para>Include code location in log messages. See <varname>systemd.log_location</varname> 1212 above.</para></listitem> 1213 </varlistentry> 1214 1215 <varlistentry> 1216 <term><option>--log-target=</option></term> 1217 1218 <listitem><para>Set log target. See <varname>systemd.log_target</varname> above.</para></listitem> 1219 </varlistentry> 1220 1221 <varlistentry> 1222 <term><option>--log-time=</option></term> 1223 1224 <listitem><para>Prefix console messages with timestamp. See <varname>systemd.log_time</varname> above. 1225 </para></listitem> 1226 </varlistentry> 1227 1228 <varlistentry> 1229 <term><option>--machine-id=</option></term> 1230 1231 <listitem><para>Override the machine-id set on the hard drive. See 1232 <varname>systemd.machine_id=</varname> above.</para></listitem> 1233 </varlistentry> 1234 1235 <varlistentry> 1236 <term><option>--service-watchdogs</option></term> 1237 1238 <listitem><para>Globally enable/disable all service watchdog timeouts and emergency actions. See 1239 <varname>systemd.service_watchdogs</varname> above.</para></listitem> 1240 </varlistentry> 1241 1242 <varlistentry> 1243 <term><option>--default-standard-output=</option></term> 1244 <term><option>--default-standard-error=</option></term> 1245 1246 <listitem><para>Sets the default output or error output for all services and sockets, 1247 respectively. See <varname>systemd.default_standard_output=</varname> and 1248 <varname>systemd.default_standard_error=</varname> above.</para></listitem> 1249 </varlistentry> 1250 </variablelist> 1251 </refsect2> 1252 </refsect1> 1253 1254 <refsect1> 1255 <title>Sockets and FIFOs</title> 1256 1257 <variablelist> 1258 <varlistentry> 1259 <term><filename>/run/systemd/notify</filename></term> 1260 1261 <listitem><para>Daemon status notification socket. This is an 1262 <constant>AF_UNIX</constant> datagram socket and is used to 1263 implement the daemon notification logic as implemented by 1264 <citerefentry><refentrytitle>sd_notify</refentrytitle><manvolnum>3</manvolnum></citerefentry>.</para></listitem> 1265 1266 </varlistentry> 1267 1268 <varlistentry> 1269 <term><filename>/run/systemd/private</filename></term> 1270 1271 <listitem><para>Used internally as communication channel 1272 between 1273 <citerefentry><refentrytitle>systemctl</refentrytitle><manvolnum>1</manvolnum></citerefentry> 1274 and the systemd process. This is an 1275 <constant>AF_UNIX</constant> stream socket. This interface is 1276 private to systemd and should not be used in external 1277 projects.</para></listitem> 1278 </varlistentry> 1279 1280 <varlistentry> 1281 <term><filename>/dev/initctl</filename></term> 1282 1283 <listitem><para>Limited compatibility support for the SysV 1284 client interface, as implemented by the 1285 <filename>systemd-initctl.service</filename> unit. This is a 1286 named pipe in the file system. This interface is obsolete and 1287 should not be used in new applications.</para></listitem> 1288 </varlistentry> 1289 </variablelist> 1290 </refsect1> 1291 1292 <refsect1> 1293 <title>See Also</title> 1294 <para> 1295 The <ulink url="https://www.freedesktop.org/wiki/Software/systemd/">systemd Homepage</ulink>, 1296 <citerefentry><refentrytitle>systemd-system.conf</refentrytitle><manvolnum>5</manvolnum></citerefentry>, 1297 <citerefentry project='man-pages'><refentrytitle>locale.conf</refentrytitle><manvolnum>5</manvolnum></citerefentry>, 1298 <citerefentry><refentrytitle>systemctl</refentrytitle><manvolnum>1</manvolnum></citerefentry>, 1299 <citerefentry><refentrytitle>journalctl</refentrytitle><manvolnum>1</manvolnum></citerefentry>, 1300 <citerefentry><refentrytitle>systemd-notify</refentrytitle><manvolnum>1</manvolnum></citerefentry>, 1301 <citerefentry><refentrytitle>daemon</refentrytitle><manvolnum>7</manvolnum></citerefentry>, 1302 <citerefentry><refentrytitle>sd-daemon</refentrytitle><manvolnum>3</manvolnum></citerefentry>, 1303 <citerefentry><refentrytitle>org.freedesktop.systemd1</refentrytitle><manvolnum>5</manvolnum></citerefentry>, 1304 <citerefentry><refentrytitle>systemd.unit</refentrytitle><manvolnum>5</manvolnum></citerefentry>, 1305 <citerefentry><refentrytitle>systemd.special</refentrytitle><manvolnum>7</manvolnum></citerefentry>, 1306 <citerefentry project='die-net'><refentrytitle>pkg-config</refentrytitle><manvolnum>1</manvolnum></citerefentry>, 1307 <citerefentry><refentrytitle>kernel-command-line</refentrytitle><manvolnum>7</manvolnum></citerefentry>, 1308 <citerefentry project='man-pages'><refentrytitle>bootup</refentrytitle><manvolnum>7</manvolnum></citerefentry>, 1309 <citerefentry><refentrytitle>systemd.directives</refentrytitle><manvolnum>7</manvolnum></citerefentry> 1310 </para> 1311 </refsect1> 1312 1313</refentry> 1314