From 798d3a524ea57aaf40cb53858aaa45ec702f012d Mon Sep 17 00:00:00 2001 From: =?utf8?q?Zbigniew=20J=C4=99drzejewski-Szmek?= Date: Tue, 3 Feb 2015 21:14:13 -0500 Subject: [PATCH] Reindent man pages to 2ch --- CODING_STYLE | 3 +- man/binfmt.d.xml | 153 +- man/bootchart.conf.xml | 289 +- man/bootctl.xml | 180 +- man/bootup.xml | 562 ++-- man/coredumpctl.xml | 435 ++- man/crypttab.xml | 743 +++-- man/daemon.xml | 1596 ++++----- man/file-hierarchy.xml | 1742 +++++----- man/halt.xml | 290 +- man/hostname.xml | 156 +- man/hostnamectl.xml | 507 ++- man/journald.conf.xml | 814 ++--- man/kernel-command-line.xml | 716 ++--- man/locale.conf.xml | 257 +- man/localectl.xml | 419 ++- man/localtime.xml | 157 +- man/loginctl.xml | 871 +++-- man/logind.conf.xml | 608 ++-- man/machine-id.xml | 230 +- man/machine-info.xml | 338 +- man/machinectl.xml | 1668 +++++----- man/modules-load.d.xml | 153 +- man/nss-myhostname.xml | 233 +- man/nss-mymachines.xml | 162 +- man/os-release.xml | 659 ++-- man/pam_systemd.xml | 568 ++-- man/resolved.conf.xml | 227 +- man/runlevel.xml | 253 +- man/sd-daemon.xml | 225 +- man/sd-id128.xml | 271 +- man/sd-journal.xml | 202 +- man/sd-login.xml | 223 +- man/sd_booted.xml | 142 +- man/sd_bus_message_get_cookie.xml | 246 +- man/sd_bus_message_get_monotonic_usec.xml | 319 +- man/sd_bus_request_name.xml | 386 ++- man/sd_get_seats.xml | 230 +- man/sd_id128_get_machine.xml | 214 +- man/sd_id128_randomize.xml | 178 +- man/sd_id128_to_string.xml | 216 +- man/sd_is_fifo.xml | 358 +-- man/sd_journal_add_match.xml | 366 +-- man/sd_journal_get_catalog.xml | 226 +- man/sd_journal_get_cursor.xml | 242 +- man/sd_journal_get_cutoff_realtime_usec.xml | 247 +- man/sd_journal_get_data.xml | 425 ++- man/sd_journal_get_fd.xml | 595 ++-- man/sd_journal_get_realtime_usec.xml | 235 +- man/sd_journal_get_usage.xml | 151 +- man/sd_journal_next.xml | 352 +- man/sd_journal_open.xml | 440 ++- man/sd_journal_print.xml | 474 ++- man/sd_journal_query_unique.xml | 353 +- man/sd_journal_seek_head.xml | 299 +- man/sd_journal_stream_fd.xml | 263 +- man/sd_listen_fds.xml | 311 +- man/sd_login_monitor_new.xml | 414 ++- man/sd_machine_get_class.xml | 197 +- man/sd_notify.xml | 754 ++--- man/sd_pid_get_session.xml | 481 ++- man/sd_seat_get_active.xml | 306 +- man/sd_session_is_active.xml | 611 ++-- man/sd_uid_get_state.xml | 367 +-- man/sd_watchdog_enabled.xml | 314 +- man/shutdown.xml | 306 +- man/sysctl.d.xml | 275 +- man/systemd-analyze.xml | 642 ++-- man/systemd-ask-password-console.service.xml | 121 +- man/systemd-ask-password.xml | 314 +- man/systemd-backlight@.service.xml | 143 +- man/systemd-binfmt.service.xml | 85 +- man/systemd-bootchart.xml | 601 ++-- man/systemd-cat.xml | 322 +- man/systemd-cgls.xml | 234 +- man/systemd-cgtop.xml | 473 ++- man/systemd-cryptsetup-generator.xml | 364 +-- man/systemd-cryptsetup@.service.xml | 104 +- man/systemd-debug-generator.xml | 145 +- man/systemd-delta.xml | 365 +-- man/systemd-detect-virt.xml | 404 ++- man/systemd-efi-boot-generator.xml | 110 +- man/systemd-escape.xml | 307 +- man/systemd-firstboot.xml | 495 ++- man/systemd-fsck@.service.xml | 248 +- man/systemd-fstab-generator.xml | 333 +- man/systemd-getty-generator.xml | 130 +- man/systemd-gpt-auto-generator.xml | 316 +- man/systemd-halt.service.xml | 191 +- man/systemd-hibernate-resume-generator.xml | 136 +- man/systemd-hibernate-resume@.service.xml | 95 +- man/systemd-hostnamed.service.xml | 120 +- man/systemd-inhibit.xml | 321 +- man/systemd-initctl.service.xml | 86 +- man/systemd-journald.service.xml | 473 ++- man/systemd-localed.service.xml | 124 +- man/systemd-logind.service.xml | 200 +- man/systemd-machine-id-commit.service.xml | 151 +- man/systemd-machine-id-commit.xml | 198 +- man/systemd-machine-id-setup.xml | 216 +- man/systemd-machined.service.xml | 130 +- man/systemd-modules-load.service.xml | 146 +- man/systemd-networkd-wait-online.service.xml | 168 +- man/systemd-networkd.service.xml | 153 +- man/systemd-notify.xml | 310 +- man/systemd-nspawn.xml | 1592 ++++----- man/systemd-path.xml | 168 +- man/systemd-quotacheck.service.xml | 146 +- man/systemd-random-seed.service.xml | 86 +- man/systemd-remount-fs.service.xml | 115 +- man/systemd-resolved.service.xml | 129 +- man/systemd-rfkill@.service.xml | 130 +- man/systemd-shutdownd.service.xml | 88 +- man/systemd-socket-proxyd.xml | 262 +- man/systemd-suspend.service.xml | 250 +- man/systemd-sysctl.service.xml | 87 +- man/systemd-system-update-generator.xml | 91 +- man/systemd-system.conf.xml | 747 ++--- man/systemd-sysusers.xml | 186 +- man/systemd-timedated.service.xml | 121 +- man/systemd-timesyncd.service.xml | 159 +- man/systemd-tmpfiles.xml | 365 +-- man/systemd-tty-ask-password-agent.xml | 253 +- man/systemd-update-done.service.xml | 148 +- man/systemd-update-utmp.service.xml | 88 +- man/systemd-user-sessions.service.xml | 89 +- man/systemd-vconsole-setup.service.xml | 182 +- man/systemd.automount.xml | 271 +- man/systemd.device.xml | 315 +- man/systemd.exec.xml | 2900 ++++++++--------- man/systemd.journal-fields.xml | 1065 +++--- man/systemd.kill.xml | 348 +- man/systemd.link.xml | 723 +++-- man/systemd.mount.xml | 646 ++-- man/systemd.netdev.xml | 1316 ++++---- man/systemd.network.xml | 1257 ++++---- man/systemd.path.xml | 379 +-- man/systemd.preset.xml | 322 +- man/systemd.service.xml | 2821 +++++++--------- man/systemd.snapshot.xml | 104 +- man/systemd.socket.xml | 1639 +++++----- man/systemd.special.xml | 1988 +++++------- man/systemd.swap.xml | 446 ++- man/systemd.target.xml | 160 +- man/systemd.time.xml | 525 ++- man/systemd.timer.xml | 513 ++- man/systemd.unit.xml | 3038 ++++++++---------- man/systemd.xml | 2336 ++++++-------- man/sysusers.d.xml | 427 ++- man/telinit.xml | 324 +- man/timedatectl.xml | 399 ++- man/timesyncd.conf.xml | 180 +- man/vconsole.conf.xml | 233 +- 153 files changed, 31258 insertions(+), 35576 deletions(-) diff --git a/CODING_STYLE b/CODING_STYLE index 0b1f809e797..30d24e56a6e 100644 --- a/CODING_STYLE +++ b/CODING_STYLE @@ -1,4 +1,5 @@ -- 8ch indent, no tabs +- 8ch indent, no tabs, except for files in man/ which are 2ch indent, + and still no tabs - Don't break code lines too eagerly. We do *not* force line breaks at 80ch, all of today's screens should be much larger than that. But diff --git a/man/binfmt.d.xml b/man/binfmt.d.xml index 55a3df0b73a..5b63cfb4c3d 100644 --- a/man/binfmt.d.xml +++ b/man/binfmt.d.xml @@ -20,83 +20,82 @@ along with systemd; If not, see . --> - - - binfmt.d - systemd - - - - Developer - Lennart - Poettering - lennart@poettering.net - - - - - - binfmt.d - 5 - - - - binfmt.d - Configure additional binary formats for - executables at boot - - - - /etc/binfmt.d/*.conf - /run/binfmt.d/*.conf - /usr/lib/binfmt.d/*.conf - - - - Description - - At boot, - systemd-binfmt.service8 - reads configuration files from the above directories - to register in the kernel additional binary - formats for executables. - - - - Configuration Format - - Each file contains a list of binfmt_misc kernel - binary format rules. Consult binfmt_misc.txt - for more information on registration of additional - binary formats and how to write rules. - - Empty lines and lines beginning with ; and # are - ignored. Note that this means you may not use ; and # - as delimiter in binary format rules. - - - - - - Example - - /etc/binfmt.d/wine.conf example: - - # Start WINE on Windows executables + xmlns:xi="http://www.w3.org/2001/XInclude"> + + + binfmt.d + systemd + + + + Developer + Lennart + Poettering + lennart@poettering.net + + + + + + binfmt.d + 5 + + + + binfmt.d + Configure additional binary formats for + executables at boot + + + + /etc/binfmt.d/*.conf + /run/binfmt.d/*.conf + /usr/lib/binfmt.d/*.conf + + + + Description + + At boot, + systemd-binfmt.service8 + reads configuration files from the above directories to register + in the kernel additional binary formats for executables. + + + + Configuration Format + + Each file contains a list of binfmt_misc kernel binary + format rules. Consult binfmt_misc.txt + for more information on registration of additional binary formats + and how to write rules. + + Empty lines and lines beginning with ; and # are ignored. + Note that this means you may not use ; and # as delimiter in + binary format rules. + + + + + + Example + + /etc/binfmt.d/wine.conf example: + + # Start WINE on Windows executables :DOSWin:M::MZ::/usr/bin/wine: - - - - - See Also - - systemd1, - systemd-binfmt.service8, - systemd-delta1, - wine8 - - + + + + + See Also + + systemd1, + systemd-binfmt.service8, + systemd-delta1, + wine8 + + diff --git a/man/bootchart.conf.xml b/man/bootchart.conf.xml index e11ccb52f66..8bafcbedcc7 100644 --- a/man/bootchart.conf.xml +++ b/man/bootchart.conf.xml @@ -1,7 +1,7 @@ + "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd"> - - bootchart.conf - systemd - - - - Developer - Auke - Kok - auke-jan.h.kok@intel.com - - - - - - bootchart.conf - 5 - - - - bootchart.conf - bootchart.conf.d - Boot performance analysis graphing tool configuration files - - - - /etc/systemd/bootchart.conf - /etc/systemd/bootchart.conf.d/*.conf - /run/systemd/bootchart.conf.d/*.conf - /usr/lib/systemd/bootchart.conf.d/*.conf - - - - Description - - When starting, systemd-bootchart will read the - configuration file - /etc/systemd/bootchart.conf, followed by - the files in the bootchart.conf.d - directories. These configuration files determine logging - parameters and graph output. - - - - - - - Options - - - - - Samples=500 - Configure the amount of samples to - record in total before bootchart exits. Each sample will - record at intervals defined by Frequency=. - - - - Frequency=25 - Configure the sample log frequency. - This can be a fractional number, but must be larger than - 0.0. Most systems can cope with values under 25-50 without - impacting boot time severely. - - - - Relative=no - Configures whether the left axis of the - output graph equals time=0.0 (CLOCK_MONOTONIC start). This - is useful for using bootchart at post-boot time to profile - an already booted system, otherwise the graph would become - extremely large. If set to yes, the horizontal axis starts - at the first recorded sample instead of time=0.0. - - - - - Filter=no - Configures whether the resulting graph - should omit tasks that did not contribute significantly - to the boot. Processes that are too short-lived (only - seen in one sample) or that do not consume any significant - CPU time (less than 0.001sec) will not be displayed in - the output graph. - - - - Output=[path] - Configures the output directory for writing - the graphs. By default, bootchart writes the graphs to - /run/log. - - - - Init=[path] - Configures bootchart to run a non-standard - binary instead of /usr/lib/systemd/systemd. This - option is only relevant if bootchart was invoked from the - kernel command line with - init=/usr/lib/systemd/systemd-bootchart. - - - - PlotMemoryUsage=no - If set to yes, enables logging and graphing - of processes' PSS memory consumption. - - - - PlotEntropyGraph=no - If set to yes, enables logging and graphing - of the kernel random entropy pool size. - - - - ScaleX=100 - Horizontal scaling factor for all variable - graph components. - - - - ScaleY=20 - Vertical scaling factor for all variable - graph components. - - - - ControlGroup=no - Display process control group. - - - - - - - See Also - - systemd-bootchart1, - systemd.directives7 - - + xmlns:xi="http://www.w3.org/2001/XInclude"> + + bootchart.conf + systemd + + + + Developer + Auke + Kok + auke-jan.h.kok@intel.com + + + + + + bootchart.conf + 5 + + + + bootchart.conf + bootchart.conf.d + Boot performance analysis graphing tool configuration files + + + + /etc/systemd/bootchart.conf + /etc/systemd/bootchart.conf.d/*.conf + /run/systemd/bootchart.conf.d/*.conf + /usr/lib/systemd/bootchart.conf.d/*.conf + + + + Description + + When starting, systemd-bootchart will read the configuration + file /etc/systemd/bootchart.conf, followed by + the files in the bootchart.conf.d + directories. These configuration files determine logging + parameters and graph output. + + + + + + + Options + + + + + Samples=500 + Configure the amount of samples to record in + total before bootchart exits. Each sample will record at + intervals defined by Frequency=. + + + + Frequency=25 + Configure the sample log frequency. This can + be a fractional number, but must be larger than 0.0. Most + systems can cope with values under 25-50 without impacting + boot time severely. + + + + Relative=no + Configures whether the left axis of the output + graph equals time=0.0 (CLOCK_MONOTONIC + start). This is useful for using bootchart at post-boot time + to profile an already booted system, otherwise the graph would + become extremely large. If set to yes, the horizontal axis + starts at the first recorded sample instead of time=0.0. + + + + + Filter=no + Configures whether the resulting graph should + omit tasks that did not contribute significantly to the boot. + Processes that are too short-lived (only seen in one sample) + or that do not consume any significant CPU time (less than + 0.001sec) will not be displayed in the output + graph. + + + + Output=[path] + Configures the output directory for writing + the graphs. By default, bootchart writes the graphs to + /run/log. + + + + Init=[path] + Configures bootchart to run a non-standard + binary instead of + /usr/lib/systemd/systemd. This option is + only relevant if bootchart was invoked from the kernel command + line with + init=/usr/lib/systemd/systemd-bootchart. + + + + PlotMemoryUsage=no + If set to yes, enables logging and graphing of + processes' PSS memory consumption. + + + + PlotEntropyGraph=no + If set to yes, enables logging and graphing of + the kernel random entropy pool size. + + + + ScaleX=100 + Horizontal scaling factor for all variable + graph components. + + + + ScaleY=20 + Vertical scaling factor for all variable graph + components. + + + + ControlGroup=no + Display process control group. + + + + + + + + See Also + + systemd-bootchart1, + systemd.directives7 + + diff --git a/man/bootctl.xml b/man/bootctl.xml index 52540221e98..00f54c73fc7 100644 --- a/man/bootctl.xml +++ b/man/bootctl.xml @@ -1,6 +1,6 @@ + "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd"> - - - bootctl - systemd - - - - Developer - Kay - Sievers - kay@vrfy.org - - - - - - bootctl - 1 - - - - bootctl - Control the firmware and boot manager settings - - - - - bootctl - OPTIONS - COMMAND - - - - - Description - - bootctl may be used to - query or (in the future) change the firmware and boot - manager settings. - - Firmware information is available only on EFI - systems. - - Currently, only the gummiboot8 boot - manager implements the required boot loader interface - to provide complete boot manager information. - - - - Options - - The following options are understood: - - - - - - - The following commands are understood: - - - - status - - Show firmware and boot - manager information about the system, - including secure boot mode status and - selected firmware entry (where - available). - - - - - - - Exit status - - On success, 0 is returned, a non-zero failure - code otherwise. - - - - See Also - - Boot loader interface, - Boot loader specification, - gummiboot - - + xmlns:xi="http://www.w3.org/2001/XInclude"> + + + bootctl + systemd + + + + Developer + Kay + Sievers + kay@vrfy.org + + + + + + bootctl + 1 + + + + bootctl + Control the firmware and boot manager settings + + + + + bootctl + OPTIONS + COMMAND + + + + + Description + + bootctl may be used to query or (in the + future) change the firmware and boot manager settings. + + Firmware information is available only on EFI systems. + + + Currently, only the + gummiboot8 + boot manager implements the required boot loader interface to + provide complete boot manager information. + + + + Options + + The following options are understood: + + + + + + + The following commands are understood: + + + + status + + Show firmware and boot manager information + about the system, including secure boot mode status and + selected firmware entry (where available). + + + + + + + Exit status + + On success, 0 is returned, a non-zero failure code + otherwise. + + + + See Also + + Boot loader interface, + Boot loader specification, + gummiboot + + diff --git a/man/bootup.xml b/man/bootup.xml index 0854b6c3165..b5c3e1523a9 100644 --- a/man/bootup.xml +++ b/man/bootup.xml @@ -1,6 +1,6 @@ + "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd"> + "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd"> - - - coredumpctl - systemd - - - - Developer - Zbigniew - Jędrzejewski-Szmek - zbyszek@in.waw.pl - - - - - - coredumpctl - 1 - - - - coredumpctl - Retrieve coredumps from the journal - - - - - coredumpctl - OPTIONS - COMMAND - PID|COMM|EXE|MATCH - - - - - Description - - coredumpctl may be used to - retrieve coredumps from - systemd-journald8. - - - - Options - - The following options are understood: - - - - - - Do not print column headers. - - - - - - - Show information of a - single coredump only, instead of - listing all known coredumps. - - - - - - - - Print all possible - data values the specified field - takes in matching coredump entries of the - journal. - - - - - - - Write the core to - . - - - - - - - - - The following commands are understood: - - - - list - - List coredumps - captured in the journal matching - specified characteristics. If no - command is specified, this is the - implied default. - - - - info - - Show detailed - information about coredumps captured - in the journal. - - - - dump - - Extract the last coredump - matching specified characteristics. - The coredump will be written on standard output, - unless an output file is specified with - . - - - - - gdb - - Invoke the GNU - debugger on the last coredump matching - specified characteristics. - - - - - - - - - Matching - - A match can be: - - - - PID - - Process ID of the - process that dumped - core. An integer. - - - - COMM - - Name of the executable - (matches ). - Must not contain slashes. - - - - - EXE - - Path to the executable - (matches ). - Must contain at least one slash. - - - - - MATCH - - General journalctl predicates - (see journalctl1). - Must contain an equal sign. - - - - - - - Exit status - On success, 0 is returned; otherwise, a non-zero failure - code is returned. Not finding any matching coredumps is treated - as failure. - - - - - Examples - - - List all the coredumps of a program named foo - - # coredumpctl list foo - - - - Invoke gdb on the last coredump - - # coredumpctl gdb - - - - Show information about a process that dumped core, matching by its PID 6654 - - # coredumpctl info 6654 - - - - Extract the last coredump of /usr/bin/bar to a file named bar.coredump - - # coredumpctl -o bar.coredump dump /usr/bin/bar - - - - - See Also - - systemd-coredump8, - coredump.conf5, - systemd-journald.service8, - gdb1 - - + xmlns:xi="http://www.w3.org/2001/XInclude"> + + + coredumpctl + systemd + + + + Developer + Zbigniew + Jędrzejewski-Szmek + zbyszek@in.waw.pl + + + + + + coredumpctl + 1 + + + + coredumpctl + Retrieve coredumps from the journal + + + + + coredumpctl + OPTIONS + COMMAND + PID|COMM|EXE|MATCH + + + + + Description + + coredumpctl may be used to + retrieve coredumps from + systemd-journald8. + + + + Options + + The following options are understood: + + + + + + Do not print column headers. + + + + + + + Show information of a single coredump only, + instead of listing all known coredumps. + + + + + + + Print all possible data values the specified + field takes in matching coredump entries of the + journal. + + + + + + + Write the core to . + + + + + + + + + + The following commands are understood: + + + + list + + List coredumps captured in the journal + matching specified characteristics. If no command is + specified, this is the implied default. + + + + info + + Show detailed information about coredumps + captured in the journal. + + + + dump + + Extract the last coredump matching specified + characteristics. The coredump will be written on standard + output, unless an output file is specified with + . + + + + gdb + + Invoke the GNU debugger on the last coredump + matching specified characteristics. + + + + + + + + Matching + + A match can be: + + + + PID + + Process ID of the + process that dumped + core. An integer. + + + + COMM + + Name of the executable (matches + ). Must not contain slashes. + + + + + EXE + + Path to the executable (matches + ). Must contain at least one + slash. + + + + MATCH + + General journalctl predicates (see + journalctl1). + Must contain an equal sign. + + + + + + Exit status + On success, 0 is returned; otherwise, a non-zero failure + code is returned. Not finding any matching coredumps is treated as + failure. + + + + + Examples + + + List all the coredumps of a program named foo + + # coredumpctl list foo + + + + Invoke gdb on the last coredump + + # coredumpctl gdb + + + + Show information about a process that dumped core, + matching by its PID 6654 + + # coredumpctl info 6654 + + + + Extract the last coredump of /usr/bin/bar to a file named + <filename noindex="true">bar.coredump</filename> + + # coredumpctl -o bar.coredump dump /usr/bin/bar + + + + + See Also + + systemd-coredump8, + coredump.conf5, + systemd-journald.service8, + gdb1 + + diff --git a/man/crypttab.xml b/man/crypttab.xml index 1a1002ecf43..aeacc579733 100644 --- a/man/crypttab.xml +++ b/man/crypttab.xml @@ -27,389 +27,366 @@ --> - - crypttab - systemd - - - - Documentation - Miloslav - Trmac - mitr@redhat.com - - - Documentation - Lennart - Poettering - lennart@poettering.net - - - - - - crypttab - 5 - - - - crypttab - Configuration for encrypted block devices - - - - /etc/crypttab - - - - Description - - The /etc/crypttab file - describes encrypted block devices that are set up - during system boot. - - Empty lines and lines starting with the # - character are ignored. Each of the remaining lines - describes one encrypted block device, fields on the - line are delimited by white space. The first two - fields are mandatory, the remaining two are - optional. - - Setting up encrypted block devices using this file - supports three encryption modes: LUKS, TrueCrypt and plain. - See cryptsetup8 - for more information about each mode. When no mode is specified - in the options field and the block device contains a LUKS - signature, it is opened as a LUKS device; otherwise, it is - assumed to be in raw dm-crypt (plain mode) format. - - The first field contains the name of the - resulting encrypted block device; the device is set up - within /dev/mapper/. - - The second field contains a path to the - underlying block device or file, or a specification of a block - device via UUID= followed by the - UUID. - - The third field specifies the encryption - password. If the field is not present or the password - is set to none or -, - the password has to be manually entered during system boot. - Otherwise, the field is interpreted as a absolute path to - a file containing the encryption password. For swap encryption, - /dev/urandom or the hardware - device /dev/hw_random can be used - as the password file; using - /dev/random may prevent boot - completion if the system does not have enough entropy - to generate a truly random encryption key. - - The fourth field, if present, is a - comma-delimited list of options. The following - options are recognized: - - - - - - - Allow discard requests to be - passed through the encrypted block device. This - improves performance on SSD storage but has - security implications. - - - - - - Specifies the cipher to use. See - cryptsetup8 - for possible values and the default value of - this option. A cipher with unpredictable IV - values, such as aes-cbc-essiv:sha256, - is recommended. - - - - - - Specifies the hash to use for - password hashing. See - cryptsetup8 - for possible values and the default value of - this option. - - - - - - Use a detached (separated) - metadata device or file where the LUKS header - is stored. This option is only relevant for - LUKS devices. See - cryptsetup8 - for possible values and the default value of - this option. - - - - - - Specifies the number of bytes to - skip at the start of the key file. See - cryptsetup8 - for possible values and the default value of - this option. - - - - - - Specifies the maximum number - of bytes to read from the key file. See - cryptsetup8 - for possible values and the default value of - this option. This option is ignored in plain - encryption mode, as the key file size is then - given by the key size. - - - - - - Specifies the key slot to - compare the passphrase or key against. - If the key slot does not match the given - passphrase or key, but another would, the - setup of the device will fail regardless. - This option implies . See - cryptsetup8 - for possible values. The default is to try - all key slots in sequential order. - - - - - - Force LUKS mode. When this mode - is used, the following options are ignored since - they are provided by the LUKS header on the - device: , - , - . - - - - - - This device will not be - automatically unlocked on boot. - - - - - - The system will not wait for the - device to show up and be unlocked at boot, and - not fail the boot if it does not show up. - - - - - - Force plain encryption mode. - - - - - - Set up the encrypted block - device in read-only mode. - - - - - - Specifies the key size - in bits. See - cryptsetup8 - for possible values and the default value of - this option. - - - - - - The encrypted block device will - be used as a swap device, and will be formatted - accordingly after setting up the encrypted - block device, with - mkswap8. - This option implies . - - WARNING: Using the - option will destroy the contents of the named - partition during every boot, so make sure the - underlying block device is specified correctly. - - - - - - Use TrueCrypt encryption mode. - When this mode is used, the following options are - ignored since they are provided by the TrueCrypt - header on the device or do not apply: - , - , - , - , - . - - When this mode is used, the passphrase is - read from the key file given in the third field. - Only the first line of this file is read, - excluding the new line character. - - Note that the TrueCrypt format uses both - passphrase and key files to derive a password - for the volume. Therefore, the passphrase and - all key files need to be provided. Use - to provide - the absolute path to all key files. When using - an empty passphrase in combination with one or - more key files, use /dev/null - as the password file in the third field. - - - - - - Use the hidden TrueCrypt volume. - This option implies . - - This will map the hidden volume that is - inside of the volume provided in the second - field. Please note that there is no protection - for the hidden volume if the outer volume is - mounted instead. See - cryptsetup8 - for more information on this limitation. - - - - - - Specifies the absolute path to a - key file to use for a TrueCrypt volume. This - implies and can be - used more than once to provide several key - files. - - See the entry for - on the behavior of the passphrase and key files - when using TrueCrypt encryption mode. - - - - - - Use TrueCrypt in system - encryption mode. This option implies - . - - - - - - Specifies the timeout for - querying for a password. If no unit is - specified, seconds is used. Supported units are - s, ms, us, min, h, d. A timeout of 0 waits - indefinitely (which is the default). - - - - - - Specifies how long - systemd should wait for a device to - show up before giving up on the - entry. The argument is a time in - seconds or explicitly specified - units of s, - min, - h, - ms. - - - - - - - The encrypted block device will - be prepared for using it as /tmp; - it will be formatted using - mke2fs8. - This option implies . - - WARNING: Using the - option will destroy the contents of the named - partition during every boot, so make sure the - underlying block device is specified correctly. - - - - - - Specifies the maximum number of - times the user is queried for a password. - The default is 3. If set to 0, the user is - queried for a password indefinitely. - - - - - - If the encryption password is - read from console, it has to be entered twice to - prevent typos. - - - - - At early boot and when the system manager - configuration is reloaded, this file is translated into - native systemd units - by systemd-cryptsetup-generator8. - - - - Example - - /etc/crypttab example - Set up four encrypted block devices. One using - LUKS for normal storage, another one for usage as a swap - device and two TrueCrypt volumes. - - luks UUID=2505567a-9e27-4efe-a4d5-15ad146c258b -swap /dev/sda7 /dev/urandom swap + + crypttab + systemd + + + + Documentation + Miloslav + Trmac + mitr@redhat.com + + + Documentation + Lennart + Poettering + lennart@poettering.net + + + + + + crypttab + 5 + + + + crypttab + Configuration for encrypted block devices + + + + /etc/crypttab + + + + Description + + The /etc/crypttab file describes + encrypted block devices that are set up during system boot. + + Empty lines and lines starting with the # + character are ignored. Each of the remaining lines describes one + encrypted block device, fields on the line are delimited by white + space. The first two fields are mandatory, the remaining two are + optional. + + Setting up encrypted block devices using this file supports + three encryption modes: LUKS, TrueCrypt and plain. See + cryptsetup8 + for more information about each mode. When no mode is specified in + the options field and the block device contains a LUKS signature, + it is opened as a LUKS device; otherwise, it is assumed to be in + raw dm-crypt (plain mode) format. + + The first field contains the name of the resulting encrypted + block device; the device is set up within + /dev/mapper/. + + The second field contains a path to the underlying block + device or file, or a specification of a block device via + UUID= followed by the UUID. + + The third field specifies the encryption password. If the + field is not present or the password is set to + none or -, the password has + to be manually entered during system boot. Otherwise, the field is + interpreted as a absolute path to a file containing the encryption + password. For swap encryption, /dev/urandom + or the hardware device /dev/hw_random can be + used as the password file; using /dev/random + may prevent boot completion if the system does not have enough + entropy to generate a truly random encryption key. + + The fourth field, if present, is a comma-delimited list of + options. The following options are recognized: + + + + + + + Allow discard requests to be passed through + the encrypted block device. This improves performance on SSD + storage but has security implications. + + + + + + Specifies the cipher to use. See + cryptsetup8 + for possible values and the default value of this option. A + cipher with unpredictable IV values, such as + aes-cbc-essiv:sha256, is + recommended. + + + + + + Specifies the hash to use for password + hashing. See + cryptsetup8 + for possible values and the default value of this + option. + + + + + + Use a detached (separated) metadata device or + file where the LUKS header is stored. This option is only + relevant for LUKS devices. See + cryptsetup8 + for possible values and the default value of this + option. + + + + + + Specifies the number of bytes to skip at the + start of the key file. See + cryptsetup8 + for possible values and the default value of this + option. + + + + + + Specifies the maximum number of bytes to read + from the key file. See + cryptsetup8 + for possible values and the default value of this option. This + option is ignored in plain encryption mode, as the key file + size is then given by the key size. + + + + + + Specifies the key slot to compare the + passphrase or key against. If the key slot does not match the + given passphrase or key, but another would, the setup of the + device will fail regardless. This option implies + . See + cryptsetup8 + for possible values. The default is to try all key slots in + sequential order. + + + + + + Force LUKS mode. When this mode is used, the + following options are ignored since they are provided by the + LUKS header on the device: , + , + . + + + + + + This device will not be automatically unlocked + on boot. + + + + + + The system will not wait for the device to + show up and be unlocked at boot, and not fail the boot if it + does not show up. + + + + + + Force plain encryption mode. + + + + + + Set up the encrypted block device in read-only + mode. + + + + + + Specifies the key size in bits. See + cryptsetup8 + for possible values and the default value of this + option. + + + + + + The encrypted block device will be used as a + swap device, and will be formatted accordingly after setting + up the encrypted block device, with + mkswap8. + This option implies . + + WARNING: Using the option will + destroy the contents of the named partition during every boot, + so make sure the underlying block device is specified + correctly. + + + + + + Use TrueCrypt encryption mode. When this mode + is used, the following options are ignored since they are + provided by the TrueCrypt header on the device or do not + apply: + , + , + , + , + . + + When this mode is used, the passphrase is read from the + key file given in the third field. Only the first line of this + file is read, excluding the new line character. + + Note that the TrueCrypt format uses both passphrase and + key files to derive a password for the volume. Therefore, the + passphrase and all key files need to be provided. Use + to provide the absolute path + to all key files. When using an empty passphrase in + combination with one or more key files, use + /dev/null as the password file in the third + field. + + + + + + Use the hidden TrueCrypt volume. This option + implies . + + This will map the hidden volume that is inside of the + volume provided in the second field. Please note that there is + no protection for the hidden volume if the outer volume is + mounted instead. See + cryptsetup8 + for more information on this limitation. + + + + + + Specifies the absolute path to a key file to + use for a TrueCrypt volume. This implies + and can be used more than once to + provide several key files. + + See the entry for on the + behavior of the passphrase and key files when using TrueCrypt + encryption mode. + + + + + + Use TrueCrypt in system encryption mode. This + option implies . + + + + + + Specifies the timeout for querying for a + password. If no unit is specified, seconds is used. Supported + units are s, ms, us, min, h, d. A timeout of 0 waits + indefinitely (which is the default). + + + + + + Specifies how long systemd should wait for a + device to show up before giving up on the entry. The argument + is a time in seconds or explicitly specified units of + s, + min, + h, + ms. + + + + + + + The encrypted block device will be prepared + for using it as /tmp; it will be + formatted using + mke2fs8. + This option implies . + + WARNING: Using the option will + destroy the contents of the named partition during every boot, + so make sure the underlying block device is specified + correctly. + + + + + + Specifies the maximum number of times the user + is queried for a password. The default is 3. If set to 0, the + user is queried for a password indefinitely. + + + + + + If the encryption password is read from + console, it has to be entered twice to prevent + typos. + + + + + At early boot and when the system manager configuration is + reloaded, this file is translated into native systemd units by + systemd-cryptsetup-generator8. + + + + Example + + /etc/crypttab example + Set up four encrypted block devices. One using LUKS for + normal storage, another one for usage as a swap device and two + TrueCrypt volumes. + + luks UUID=2505567a-9e27-4efe-a4d5-15ad146c258b +swap /dev/sda7 /dev/urandom swap truecrypt /dev/sda2 /etc/container_password tcrypt -hidden /mnt/tc_hidden /dev/null tcrypt-hidden,tcrypt-keyfile=/etc/keyfile - - - - - See Also - - systemd1, - systemd-cryptsetup@.service8, - systemd-cryptsetup-generator8, - cryptsetup8, - mkswap8, - mke2fs8 - - +hidden /mnt/tc_hidden /dev/null tcrypt-hidden,tcrypt-keyfile=/etc/keyfile + + + + + See Also + + systemd1, + systemd-cryptsetup@.service8, + systemd-cryptsetup-generator8, + cryptsetup8, + mkswap8, + mke2fs8 + + diff --git a/man/daemon.xml b/man/daemon.xml index 5d3a9903da3..a8bbfc055b6 100644 --- a/man/daemon.xml +++ b/man/daemon.xml @@ -1,6 +1,6 @@ + "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd"> + "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd"> + "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd"> - - - halt - systemd - - - - Developer - Lennart - Poettering - lennart@poettering.net - - - - - - halt - 8 - - - - halt - poweroff - reboot - Halt, power-off or reboot the machine - - - - - halt OPTIONS - - - poweroff OPTIONS - - - reboot OPTIONS - - - - - Description - - halt, - poweroff, reboot - may be used to halt, power-off or reboot the - machine. - - - - - Options - - The following options are understood: - - - - - - - - - - - - Halt the machine, - regardless of which one of the three - commands is invoked. - - - - - - - Power-off the machine, - regardless of which one of the three - commands is invoked. - - - - - - Reboot the machine, - regardless of which one of the three - commands is invoked. - - - - - - - Force immediate halt, - power-off, reboot. Do not contact the - init system. - - - - - - - Only write wtmp - shutdown entry, do not actually halt, - power-off, reboot. - - - - - - - Do not write wtmp - shutdown entry. - - - - - - Do not send wall - message before - halt, power-off, reboot. - - - - - - Exit status - - On success, 0 is returned, a non-zero failure - code otherwise. - - - - Notes - - These are legacy commands available for - compatibility only. - - - - See Also - - systemd1, - systemctl1, - shutdown8, - wall1 - - + xmlns:xi="http://www.w3.org/2001/XInclude"> + + + halt + systemd + + + + Developer + Lennart + Poettering + lennart@poettering.net + + + + + + halt + 8 + + + + halt + poweroff + reboot + Halt, power-off or reboot the machine + + + + + halt + OPTIONS + + + poweroff + OPTIONS + + + reboot + OPTIONS + + + + + Description + + halt, poweroff, + reboot may be used to halt, power-off or reboot + the machine. + + + + + Options + + The following options are understood: + + + + + + + + + + + + Halt the machine, regardless of which one of + the three commands is invoked. + + + + + + + Power-off the machine, regardless of which one + of the three commands is invoked. + + + + + + Reboot the machine, regardless of which one of + the three commands is invoked. + + + + + + + Force immediate halt, power-off, reboot. Do + not contact the init system. + + + + + + + Only write wtmp shutdown entry, do not + actually halt, power-off, reboot. + + + + + + + Do not write wtmp shutdown + entry. + + + + + + Do not send wall message before halt, + power-off, reboot. + + + + + + Exit status + + On success, 0 is returned, a non-zero failure code + otherwise. + + + + Notes + + These are legacy commands available for compatibility + only. + + + + See Also + + systemd1, + systemctl1, + shutdown8, + wall1 + + diff --git a/man/hostname.xml b/man/hostname.xml index 2f949dedd3b..588f643253c 100644 --- a/man/hostname.xml +++ b/man/hostname.xml @@ -1,7 +1,7 @@ + "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd"> - - hostname - systemd - - - - Developer - Lennart - Poettering - lennart@poettering.net - - - - - - hostname - 5 - - - - hostname - Local hostname configuration file - - - - /etc/hostname - - - - Description - - The /etc/hostname file - configures the name of the local system that is set - during boot using the - sethostname2 - system call. It should contain a single - newline-terminated hostname string. The - hostname may be a free-form string up to 64 characters - in length; however, it is recommended that it consists - only of 7-bit ASCII lower-case characters and no spaces or dots, - and limits itself to the format allowed for DNS domain - name labels, even though this is not a - strict requirement. - - Depending on the operating system, other - configuration files might be checked for configuration - of the hostname as well, however only as fallback. - - You may use - hostnamectl1 - to change the value of this file during runtime from - the command line. Use - systemd-firstboot1 - to initialize it on mounted (but not booted) system - images. - - - - History - - The simple configuration file format of - /etc/hostname originates from - Debian GNU/Linux. - - - - See Also - - systemd1, - sethostname2, - hostname1, - hostname7, - machine-id5, - machine-info5, - hostnamectl1, - systemd-hostnamed.service8, - systemd-firstboot1 - - + + hostname + systemd + + + + Developer + Lennart + Poettering + lennart@poettering.net + + + + + + hostname + 5 + + + + hostname + Local hostname configuration file + + + + /etc/hostname + + + + Description + + The /etc/hostname file configures the + name of the local system that is set during boot using the + sethostname2 + system call. It should contain a single newline-terminated + hostname string. The hostname may be a free-form string up to 64 + characters in length; however, it is recommended that it consists + only of 7-bit ASCII lower-case characters and no spaces or dots, + and limits itself to the format allowed for DNS domain name + labels, even though this is not a strict requirement. + + Depending on the operating system, other configuration files + might be checked for configuration of the hostname as well, + however only as fallback. + + You may use + hostnamectl1 + to change the value of this file during runtime from the command + line. Use + systemd-firstboot1 + to initialize it on mounted (but not booted) system images. + + + + History + + The simple configuration file format of + /etc/hostname originates from Debian + GNU/Linux. + + + + See Also + + systemd1, + sethostname2, + hostname1, + hostname7, + machine-id5, + machine-info5, + hostnamectl1, + systemd-hostnamed.service8, + systemd-firstboot1 + + diff --git a/man/hostnamectl.xml b/man/hostnamectl.xml index de154020d6a..b1f038156d6 100644 --- a/man/hostnamectl.xml +++ b/man/hostnamectl.xml @@ -1,6 +1,6 @@ + "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd"> - - - hostnamectl - systemd - - - - Developer - Lennart - Poettering - lennart@poettering.net - - - - - - hostnamectl - 1 - - - - hostnamectl - Control the system hostname - - - - - hostnamectl - OPTIONS - COMMAND - - - - - Description - - hostnamectl may be used to - query and change the system hostname and related - settings. - - This tool distinguishes three different - hostnames: the high-level "pretty" hostname which - might include all kinds of special characters - (e.g. "Lennart's Laptop"), the static hostname which - is used to initialize the kernel hostname at boot - (e.g. "lennarts-laptop"), and the transient hostname - which is a default received from network configuration. - If a static hostname is set, and is valid (something other - than localhost), then the transient hostname is not used. - - Note that the pretty hostname has little - restrictions on the characters used, while the static - and transient hostnames are limited to the usually - accepted characters of Internet domain names. - - The static hostname is stored in - /etc/hostname, see - hostname5 - for more information. The pretty hostname, chassis - type, and icon name are stored in - /etc/machine-info, see - machine-info5. - - Use - systemd-firstboot1 - to initialize the system host name for mounted (but - not booted) system images. - - - - Options - - The following options are understood: - - - - - - Do not query the user - for authentication for privileged - operations. - - - - - - - - If - status is used (or - no explicit command is given) and one - of those fields is given, - hostnamectl will - print out just this selected - hostname. - - If used with - set-hostname, only - the selected hostname(s) will be - updated. When more than one of those - options is used, all the specified - hostnames will be updated. - - - - - - - - - - - The following commands are understood: - - - - status - - Show current system - hostname and related - information. - - - - set-hostname NAME - - Set the system - hostname to - NAME. By - default, this will alter the pretty, - the static, and the transient hostname - alike; however, if one or more of - , - , - are used, - only the selected hostnames are - changed. If the pretty hostname is - being set, and static or transient are - being set as well, the specified - hostname will be simplified in regards - to the character set used before the - latter are updated. This is done by - replacing spaces with - - and removing - special characters. This ensures that - the pretty and the static hostname are - always closely related while still - following the validity rules of the - specific name. This simplification of - the hostname string is not done if - only the transient and/or static host - names are set, and the pretty host - name is left untouched. - - Pass the empty string - as the hostname to - reset the selected hostnames to their - default (usually - localhost). - - - - set-icon-name NAME - - Set the system icon - name to - NAME. The - icon name is used by some graphical - applications to visualize this host. - The icon name should follow the Icon - Naming Specification. - - Pass an empty string to reset - the icon name to the default value, - which is determined from chassis type - (see below) and possibly other - parameters. - - - - set-chassis TYPE - - Set the chassis type - to TYPE. - The chassis type is used by some - graphical applications to visualize - the host or alter user interaction. - Currently, the following chassis types - are defined: - desktop, - laptop, - server, - tablet, - handset, - watch, - embedded as well as - the special chassis types - vm and - container for - virtualized systems that lack an - immediate physical chassis. - - Pass an empty string to reset - the chassis type to the default value - which is determined from the firmware - and possibly other parameters. - - - - - set-deployment ENVIRONMENT - - Set the deployment - environment - description. ENVIRONMENT - must be a single word without any - control characters. One of the - following is suggested: - development, - integration, - staging, - production. - - - Pass an empty string to reset to - the default empty value. - - - - - set-location LOCATION - - Set the location - string for the system, if it is - known. LOCATION - should be a human-friendly, free-form - string describing the physical - location of the system, if it is known - and applicable. This may be as generic - as Berlin, Germany - or as specific as Left Rack, - 2nd Shelf. - - Pass an empty string to reset to - the default empty value. - - - - - - - Exit status - - On success, 0 is returned, a non-zero failure - code otherwise. - - - - See Also - - systemd1, - hostname1, - hostname5, - machine-info5, - systemctl1, - systemd-hostnamed.service8, - systemd-firstboot1 - - + xmlns:xi="http://www.w3.org/2001/XInclude"> + + + hostnamectl + systemd + + + + Developer + Lennart + Poettering + lennart@poettering.net + + + + + + hostnamectl + 1 + + + + hostnamectl + Control the system hostname + + + + + hostnamectl + OPTIONS + COMMAND + + + + + Description + + hostnamectl may be used to query and + change the system hostname and related settings. + + This tool distinguishes three different hostnames: the + high-level "pretty" hostname which might include all kinds of + special characters (e.g. "Lennart's Laptop"), the static hostname + which is used to initialize the kernel hostname at boot (e.g. + "lennarts-laptop"), and the transient hostname which is a default + received from network configuration. If a static hostname is set, + and is valid (something other than localhost), then the transient + hostname is not used. + + Note that the pretty hostname has little restrictions on the + characters used, while the static and transient hostnames are + limited to the usually accepted characters of Internet domain + names. + + The static hostname is stored in + /etc/hostname, see + hostname5 + for more information. The pretty hostname, chassis type, and icon + name are stored in /etc/machine-info, see + machine-info5. + + Use + systemd-firstboot1 + to initialize the system host name for mounted (but not booted) + system images. + + + + Options + + The following options are understood: + + + + + + Do not query the user for authentication for + privileged operations. + + + + + + + + If status is used (or no + explicit command is given) and one of those fields is given, + hostnamectl will print out just this + selected hostname. + + If used with set-hostname, only the + selected hostname(s) will be updated. When more than one of + those options is used, all the specified hostnames will be + updated. + + + + + + + + + + The following commands are understood: + + + + status + + Show current system + hostname and related + information. + + + + set-hostname NAME + + Set the system hostname to + NAME. By default, this will alter + the pretty, the static, and the transient hostname alike; + however, if one or more of , + , are + used, only the selected hostnames are changed. If the pretty + hostname is being set, and static or transient are being set + as well, the specified hostname will be simplified in regards + to the character set used before the latter are updated. This + is done by replacing spaces with - and + removing special characters. This ensures that the pretty and + the static hostname are always closely related while still + following the validity rules of the specific name. This + simplification of the hostname string is not done if only the + transient and/or static host names are set, and the pretty + host name is left untouched. + + Pass the empty string as the + hostname to reset the selected hostnames to their default + (usually localhost). + + + + set-icon-name NAME + + Set the system icon name to + NAME. The icon name is used by some + graphical applications to visualize this host. The icon name + should follow the Icon + Naming Specification. + + Pass an empty string to reset the icon name to the + default value, which is determined from chassis type (see + below) and possibly other parameters. + + + + set-chassis TYPE + + Set the chassis type to + TYPE. The chassis type is used by + some graphical applications to visualize the host or alter + user interaction. Currently, the following chassis types are + defined: + desktop, + laptop, + server, + tablet, + handset, + watch, + embedded, + as well as the special chassis types + vm and + container for virtualized systems that lack + an immediate physical chassis. + + Pass an empty string to reset the chassis type to the + default value which is determined from the firmware and + possibly other parameters. + + + + + set-deployment ENVIRONMENT + + Set the deployment environment description. + ENVIRONMENT must be a single word + without any control characters. One of the following is + suggested: + development, + integration, + staging, + production. + + + Pass an empty string to reset to the default empty + value. + + + + + set-location LOCATION + + Set the location string for the system, if it + is known. LOCATION should be a + human-friendly, free-form string describing the physical + location of the system, if it is known and applicable. This + may be as generic as Berlin, Germany or as + specific as Left Rack, 2nd Shelf. + + Pass an empty string to reset to the default empty + value. + + + + + + + Exit status + + On success, 0 is returned, a non-zero failure code + otherwise. + + + + See Also + + systemd1, + hostname1, + hostname5, + machine-info5, + systemctl1, + systemd-hostnamed.service8, + systemd-firstboot1 + + diff --git a/man/journald.conf.xml b/man/journald.conf.xml index 4edcc003c0d..8504d66d498 100644 --- a/man/journald.conf.xml +++ b/man/journald.conf.xml @@ -1,7 +1,7 @@ + "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd"> - - journald.conf - systemd - - - - Developer - Lennart - Poettering - lennart@poettering.net - - - - - - journald.conf - 5 - - - - journald.conf - journald.conf.d - Journal service configuration files - - - - /etc/systemd/journald.conf - /etc/systemd/journald.conf.d/*.conf - /run/systemd/journald.conf.d/*.conf - /usr/lib/systemd/journald.conf.d/*.conf - - - - Description - - These files configure various parameters of the - systemd journal service, - systemd-journald.service8. - - - - - - - - Options - - All options are configured in the - [Journal] section: - - - - - Storage= - - Controls where to - store journal data. One of - volatile, - persistent, - auto and - none. If - volatile, journal - log data will be stored only in - memory, i.e. below the - /run/log/journal - hierarchy (which is created if - needed). If - persistent, data will - be stored preferably on disk, - i.e. below the - /var/log/journal - hierarchy (which is created if - needed), with a fallback to - /run/log/journal - (which is created if needed), during - early boot and if the disk is not - writable. auto is - similar to - persistent but the - directory - /var/log/journal - is not created if needed, so that its - existence controls where log data - goes. none turns - off all storage, all log data received - will be dropped. Forwarding to other - targets, such as the console, the - kernel log buffer or a syslog daemon - will still work however. Defaults to - auto. - - - - Compress= - - Takes a boolean - value. If enabled (the default), data - objects that shall be stored in the - journal and are larger than a certain - threshold are compressed before they - are written to the file - system. - - - - Seal= - - Takes a boolean - value. If enabled (the default), and a - sealing key is available (as created - by - journalctl1's - - command), Forward Secure Sealing (FSS) - for all persistent journal files is - enabled. FSS is based on Seekable - Sequential Key Generators by - G. A. Marson and B. Poettering - (doi:10.1007/978-3-642-40203-6_7) - and may be used to protect journal files - from unnoticed alteration. - - - - SplitMode= - - Controls whether to - split up journal files per user. One - of uid, - login and - none. If - uid, all users will - get each their own journal files - regardless of whether they possess a - login session or not, however system - users will log into the system - journal. If login, - actually logged-in users will get each - their own journal files, but users - without login session and system users - will log into the system journal. If - none, journal files - are not split up by user and all - messages are instead stored in the - single system journal. Note that - splitting up journal files by user is - only available for journals stored - persistently. If journals are stored - on volatile storage (see above), only - a single journal file for all user IDs - is kept. Defaults to - uid. - - - - RateLimitInterval= - RateLimitBurst= - - Configures the rate - limiting that is applied to all - messages generated on the system. If, - in the time interval defined by - RateLimitInterval=, - more messages than specified in - RateLimitBurst= are - logged by a service, all further - messages within the interval are - dropped until the interval is over. A - message about the number of dropped - messages is generated. This rate - limiting is applied per-service, so - that two services which log do not - interfere with each other's - limits. Defaults to 1000 messages in - 30s. The time specification for - RateLimitInterval= - may be specified in the following - units: s, - min, - h, - ms, - us. To turn off any - kind of rate limiting, set either - value to 0. - - - - SystemMaxUse= - SystemKeepFree= - SystemMaxFileSize= - RuntimeMaxUse= - RuntimeKeepFree= - RuntimeMaxFileSize= - - Enforce size limits on - the journal files stored. The options - prefixed with - System apply to the - journal files when stored on a - persistent file system, more - specifically - /var/log/journal. The - options prefixed with - Runtime apply to - the journal files when stored on a - volatile in-memory file system, more - specifically - /run/log/journal. The - former is used only when - /var is mounted, - writable, and the directory - /var/log/journal - exists. Otherwise, only the latter - applies. Note that this means that - during early boot and if the - administrator disabled persistent - logging, only the latter options apply, - while the former apply if persistent - logging is enabled and the system is - fully booted - up. journalctl and - systemd-journald - ignore all files with names not ending - with .journal or - .journal~, so only - such files, located in the appropriate - directories, are taken into account - when calculating current disk usage. - - - SystemMaxUse= - and RuntimeMaxUse= - control how much disk space the - journal may use up at maximum. - SystemKeepFree= and - RuntimeKeepFree= - control how much disk space - systemd-journald shall leave free for - other uses. - systemd-journald - will respect both limits and use the - smaller of the two values. - - The first pair defaults to 10% - and the second to 15% of the size of - the respective file system. If the - file system is nearly full and either - SystemKeepFree= or - RuntimeKeepFree= is - violated when systemd-journald is - started, the value will be raised to - percentage that is actually free. This - means that if there was enough - free space before and journal files were - created, and subsequently something - else causes the file system to fill - up, journald will stop using more - space, but it will not be removing - existing files to go reduce footprint - either. - - SystemMaxFileSize= - and - RuntimeMaxFileSize= - control how large individual journal - files may grow at maximum. This - influences the granularity in which - disk space is made available through - rotation, i.e. deletion of historic - data. Defaults to one eighth of the - values configured with - SystemMaxUse= and - RuntimeMaxUse=, so - that usually seven rotated journal - files are kept as history. Specify - values in bytes or use K, M, G, T, P, - E as units for the specified sizes - (equal to 1024, 1024²,... bytes). - Note that size limits are enforced - synchronously when journal files are - extended, and no explicit rotation - step triggered by time is - needed. - - - - MaxFileSec= - - The maximum time to - store entries in a single journal - file before rotating to the next - one. Normally, time-based rotation - should not be required as size-based - rotation with options such as - SystemMaxFileSize= - should be sufficient to ensure that - journal files do not grow without - bounds. However, to ensure that not - too much data is lost at once when old - journal files are deleted, it might - make sense to change this value from - the default of one month. Set to 0 to - turn off this feature. This setting - takes time values which may be - suffixed with the units - year, - month, - week, day, - h or m - to override the default time unit of - seconds. - - - - MaxRetentionSec= - - The maximum time to - store journal entries. This - controls whether journal files - containing entries older then the - specified time span are - deleted. Normally, time-based deletion - of old journal files should not be - required as size-based deletion with - options such as - SystemMaxUse= - should be sufficient to ensure that - journal files do not grow without - bounds. However, to enforce data - retention policies, it might make sense - to change this value from the - default of 0 (which turns off this - feature). This setting also takes - time values which may be suffixed with - the units year, - month, - week, day, - h or m - to override the default time unit of - seconds. - - - - - SyncIntervalSec= - - The timeout before - synchronizing journal files to - disk. After syncing, journal files are - placed in the OFFLINE state. Note that - syncing is unconditionally done - immediately after a log message of - priority CRIT, ALERT or EMERG has been - logged. This setting hence applies - only to messages of the levels ERR, - WARNING, NOTICE, INFO, DEBUG. The - default timeout is 5 minutes. - - - - - ForwardToSyslog= - ForwardToKMsg= - ForwardToConsole= - ForwardToWall= - - Control whether log - messages received by the journal - daemon shall be forwarded to a - traditional syslog daemon, to the - kernel log buffer (kmsg), to the - system console, or sent as wall - messages to all logged-in users. These - options take boolean arguments. If - forwarding to syslog is enabled but no - syslog daemon is running, the - respective option has no effect. By - default, only forwarding wall is - enabled. These settings may be - overridden at boot time with the - kernel command line options - systemd.journald.forward_to_syslog=, - systemd.journald.forward_to_kmsg=, - systemd.journald.forward_to_console= - and - systemd.journald.forward_to_wall=. - When forwarding to the console, the - TTY to log to can be changed with - TTYPath=, described - below. - - - - MaxLevelStore= - MaxLevelSyslog= - MaxLevelKMsg= - MaxLevelConsole= - MaxLevelWall= - - Controls the maximum - log level of messages that are stored - on disk, forwarded to syslog, kmsg, - the console or wall (if that is - enabled, see above). As argument, - takes one of - emerg, - alert, - crit, - err, - warning, - notice, - info, - debug or integer - values in the range of 0..7 (corresponding - to the same levels). Messages equal or below - the log level specified are - stored/forwarded, messages above are - dropped. Defaults to - debug for - MaxLevelStore= and - MaxLevelSyslog=, to - ensure that the all messages are - written to disk and forwarded to - syslog. Defaults to - notice for - MaxLevelKMsg=, - info for - MaxLevelConsole= and - emerg for - MaxLevelWall=. - - - - TTYPath= - - Change the console TTY - to use if - ForwardToConsole=yes - is used. Defaults to - /dev/console. - - - - - - - - See Also - - systemd1, - systemd-journald.service8, - journalctl1, - systemd.journal-fields7, - systemd-system.conf5 - - + xmlns:xi="http://www.w3.org/2001/XInclude"> + + journald.conf + systemd + + + + Developer + Lennart + Poettering + lennart@poettering.net + + + + + + journald.conf + 5 + + + + journald.conf + journald.conf.d + Journal service configuration files + + + + /etc/systemd/journald.conf + /etc/systemd/journald.conf.d/*.conf + /run/systemd/journald.conf.d/*.conf + /usr/lib/systemd/journald.conf.d/*.conf + + + + Description + + These files configure various parameters of the systemd + journal service, + systemd-journald.service8. + + + + + + + + Options + + All options are configured in the + [Journal] section: + + + + + Storage= + + Controls where to store journal data. One of + volatile, + persistent, + auto and + none. If + volatile, journal + log data will be stored only in memory, i.e. below the + /run/log/journal hierarchy (which is + created if needed). If persistent, data + will be stored preferably on disk, i.e. below the + /var/log/journal hierarchy (which is + created if needed), with a fallback to + /run/log/journal (which is created if + needed), during early boot and if the disk is not writable. + auto is similar to + persistent but the directory + /var/log/journal is not created if + needed, so that its existence controls where log data goes. + none turns off all storage, all log data + received will be dropped. Forwarding to other targets, such as + the console, the kernel log buffer or a syslog daemon will + still work however. Defaults to + auto. + + + + Compress= + + Takes a boolean value. If enabled (the + default), data objects that shall be stored in the journal and + are larger than a certain threshold are compressed before they + are written to the file system. + + + + Seal= + + Takes a boolean value. If enabled (the + default), and a sealing key is available (as created by + journalctl1's + command), Forward Secure Sealing + (FSS) for all persistent journal files is enabled. FSS is + based on Seekable Sequential Key + Generators by G. A. Marson and B. Poettering + (doi:10.1007/978-3-642-40203-6_7) and may be used to protect + journal files from unnoticed alteration. + + + + SplitMode= + + Controls whether to split up journal files per + user. One of uid, login + and none. If uid, all + users will get each their own journal files regardless of + whether they possess a login session or not, however system + users will log into the system journal. If + login, actually logged-in users will get + each their own journal files, but users without login session + and system users will log into the system journal. If + none, journal files are not split up by + user and all messages are instead stored in the single system + journal. Note that splitting up journal files by user is only + available for journals stored persistently. If journals are + stored on volatile storage (see above), only a single journal + file for all user IDs is kept. Defaults to + uid. + + + + RateLimitInterval= + RateLimitBurst= + + Configures the rate limiting that is applied + to all messages generated on the system. If, in the time + interval defined by RateLimitInterval=, + more messages than specified in + RateLimitBurst= are logged by a service, + all further messages within the interval are dropped until the + interval is over. A message about the number of dropped + messages is generated. This rate limiting is applied + per-service, so that two services which log do not interfere + with each other's limits. Defaults to 1000 messages in 30s. + The time specification for + RateLimitInterval= may be specified in the + following units: s, min, + h, ms, + us. To turn off any kind of rate limiting, + set either value to 0. + + + + SystemMaxUse= + SystemKeepFree= + SystemMaxFileSize= + RuntimeMaxUse= + RuntimeKeepFree= + RuntimeMaxFileSize= + + Enforce size limits on the journal files + stored. The options prefixed with System + apply to the journal files when stored on a persistent file + system, more specifically + /var/log/journal. The options prefixed + with Runtime apply to the journal files + when stored on a volatile in-memory file system, more + specifically /run/log/journal. The former + is used only when /var is mounted, + writable, and the directory + /var/log/journal exists. Otherwise, only + the latter applies. Note that this means that during early + boot and if the administrator disabled persistent logging, + only the latter options apply, while the former apply if + persistent logging is enabled and the system is fully booted + up. journalctl and + systemd-journald ignore all files with + names not ending with .journal or + .journal~, so only such files, located in + the appropriate directories, are taken into account when + calculating current disk usage. + + + SystemMaxUse= and + RuntimeMaxUse= control how much disk space + the journal may use up at maximum. + SystemKeepFree= and + RuntimeKeepFree= control how much disk + space systemd-journald shall leave free for other uses. + systemd-journald will respect both limits + and use the smaller of the two values. + + The first pair defaults to 10% and the second to 15% of + the size of the respective file system. If the file system is + nearly full and either SystemKeepFree= or + RuntimeKeepFree= is violated when + systemd-journald is started, the value will be raised to + percentage that is actually free. This means that if there was + enough free space before and journal files were created, and + subsequently something else causes the file system to fill up, + journald will stop using more space, but it will not be + removing existing files to go reduce footprint either. + + SystemMaxFileSize= + and + RuntimeMaxFileSize= + control how large individual journal + files may grow at maximum. This + influences the granularity in which + disk space is made available through + rotation, i.e. deletion of historic + data. Defaults to one eighth of the + values configured with + SystemMaxUse= and + RuntimeMaxUse=, so + that usually seven rotated journal + files are kept as history. Specify + values in bytes or use K, M, G, T, P, + E as units for the specified sizes + (equal to 1024, 1024²,... bytes). + Note that size limits are enforced + synchronously when journal files are + extended, and no explicit rotation + step triggered by time is + needed. + + + + MaxFileSec= + + The maximum time to store entries in a single + journal file before rotating to the next one. Normally, + time-based rotation should not be required as size-based + rotation with options such as + SystemMaxFileSize= should be sufficient to + ensure that journal files do not grow without bounds. However, + to ensure that not too much data is lost at once when old + journal files are deleted, it might make sense to change this + value from the default of one month. Set to 0 to turn off this + feature. This setting takes time values which may be suffixed + with the units year, + month, week, + day, h or + m to override the default time unit of + seconds. + + + + MaxRetentionSec= + + The maximum time to store journal entries. + This controls whether journal files containing entries older + then the specified time span are deleted. Normally, time-based + deletion of old journal files should not be required as + size-based deletion with options such as + SystemMaxUse= should be sufficient to + ensure that journal files do not grow without bounds. However, + to enforce data retention policies, it might make sense to + change this value from the default of 0 (which turns off this + feature). This setting also takes time values which may be + suffixed with the units year, + month, week, + day, h or + m to override the default time unit of + seconds. + + + + + SyncIntervalSec= + + The timeout before synchronizing journal files + to disk. After syncing, journal files are placed in the + OFFLINE state. Note that syncing is unconditionally done + immediately after a log message of priority CRIT, ALERT or + EMERG has been logged. This setting hence applies only to + messages of the levels ERR, WARNING, NOTICE, INFO, DEBUG. The + default timeout is 5 minutes. + + + + ForwardToSyslog= + ForwardToKMsg= + ForwardToConsole= + ForwardToWall= + + Control whether log messages received by the + journal daemon shall be forwarded to a traditional syslog + daemon, to the kernel log buffer (kmsg), to the system + console, or sent as wall messages to all logged-in users. + These options take boolean arguments. If forwarding to syslog + is enabled but no syslog daemon is running, the respective + option has no effect. By default, only forwarding wall is + enabled. These settings may be overridden at boot time with + the kernel command line options + systemd.journald.forward_to_syslog=, + systemd.journald.forward_to_kmsg=, + systemd.journald.forward_to_console= and + systemd.journald.forward_to_wall=. When + forwarding to the console, the TTY to log to can be changed + with TTYPath=, described + below. + + + + MaxLevelStore= + MaxLevelSyslog= + MaxLevelKMsg= + MaxLevelConsole= + MaxLevelWall= + + Controls the maximum log level of messages + that are stored on disk, forwarded to syslog, kmsg, the + console or wall (if that is enabled, see above). As argument, + takes one of + emerg, + alert, + crit, + err, + warning, + notice, + info, + debug, + or integer values in the range of 0..7 (corresponding to the + same levels). Messages equal or below the log level specified + are stored/forwarded, messages above are dropped. Defaults to + debug for MaxLevelStore= + and MaxLevelSyslog=, to ensure that the all + messages are written to disk and forwarded to syslog. Defaults + to + notice for MaxLevelKMsg=, + info for MaxLevelConsole=, + and emerg for + MaxLevelWall=. + + + + TTYPath= + + Change the console TTY to use if + ForwardToConsole=yes is used. Defaults to + /dev/console. + + + + + + + + See Also + + systemd1, + systemd-journald.service8, + journalctl1, + systemd.journal-fields7, + systemd-system.conf5 + + diff --git a/man/kernel-command-line.xml b/man/kernel-command-line.xml index e32ed1972e8..3741cf9cc2b 100644 --- a/man/kernel-command-line.xml +++ b/man/kernel-command-line.xml @@ -1,6 +1,6 @@ + "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd"> + "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd"> - - locale.conf - systemd - - - - Developer - Lennart - Poettering - lennart@poettering.net - - - - - - locale.conf - 5 - - - - locale.conf - Configuration file for locale settings - - - - /etc/locale.conf - - - - Description - - The /etc/locale.conf file - configures system-wide locale settings. It is read at - early-boot by - systemd1. - - The basic file format of - locale.conf is a - newline-separated list of environment-like - shell-compatible variable assignments. It is possible - to source the configuration from shell scripts, - however, beyond mere variable assignments, no shell - features are supported, allowing applications to read - the file without implementing a shell compatible - execution engine. - - Note that the kernel command line options - locale.LANG=, - locale.LANGUAGE=, - locale.LC_CTYPE=, - locale.LC_NUMERIC=, - locale.LC_TIME=, - locale.LC_COLLATE=, - locale.LC_MONETARY=, - locale.LC_MESSAGES=, - locale.LC_PAPER=, - locale.LC_NAME=, - locale.LC_ADDRESS=, - locale.LC_TELEPHONE=, - locale.LC_MEASUREMENT=, - locale.LC_IDENTIFICATION= may be - used to override the locale settings at boot. - - The locale settings configured in - /etc/locale.conf are system-wide - and are inherited by every service or user, unless - overridden or unset by individual programs or - individual users. - - Depending on the operating system, other - configuration files might be checked for locale - configuration as well, however only as - fallback. - - localectl1 - may be used to alter the settings in this file during - runtime from the command line. Use - systemd-firstboot1 - to initialize them on mounted (but not booted) system - images. - - - - Options - - The following locale settings may be set using - /etc/locale.conf: - LANG=, - LANGUAGE=, - LC_CTYPE=, - LC_NUMERIC=, - LC_TIME=, - LC_COLLATE=, - LC_MONETARY=, - LC_MESSAGES=, - LC_PAPER=, - LC_NAME=, - LC_ADDRESS=, - LC_TELEPHONE=, - LC_MEASUREMENT=, - LC_IDENTIFICATION=. Note that - LC_ALL may not be configured in - this file. For details about the meaning and semantics - of these settings, refer to - locale7. - - - - Example - - - German locale with English messages - - /etc/locale.conf: - - LANG=de_DE.UTF-8 + + locale.conf + systemd + + + + Developer + Lennart + Poettering + lennart@poettering.net + + + + + + locale.conf + 5 + + + + locale.conf + Configuration file for locale settings + + + + /etc/locale.conf + + + + Description + + The /etc/locale.conf file configures + system-wide locale settings. It is read at early-boot by + systemd1. + + The basic file format of locale.conf is + a newline-separated list of environment-like shell-compatible + variable assignments. It is possible to source the configuration + from shell scripts, however, beyond mere variable assignments, no + shell features are supported, allowing applications to read the + file without implementing a shell compatible execution + engine. + + Note that the kernel command line options + locale.LANG=, + locale.LANGUAGE=, + locale.LC_CTYPE=, + locale.LC_NUMERIC=, + locale.LC_TIME=, + locale.LC_COLLATE=, + locale.LC_MONETARY=, + locale.LC_MESSAGES=, + locale.LC_PAPER=, + locale.LC_NAME=, + locale.LC_ADDRESS=, + locale.LC_TELEPHONE=, + locale.LC_MEASUREMENT=, + locale.LC_IDENTIFICATION= may be + used to override the locale settings at boot. + + The locale settings configured in + /etc/locale.conf are system-wide and are + inherited by every service or user, unless overridden or unset by + individual programs or individual users. + + Depending on the operating system, other configuration files + might be checked for locale configuration as well, however only as + fallback. + + localectl1 + may be used to alter the settings in this file during runtime from + the command line. Use + systemd-firstboot1 + to initialize them on mounted (but not booted) system + images. + + + + Options + + The following locale settings may be set using + /etc/locale.conf: + LANG=, + LANGUAGE=, + LC_CTYPE=, + LC_NUMERIC=, + LC_TIME=, + LC_COLLATE=, + LC_MONETARY=, + LC_MESSAGES=, + LC_PAPER=, + LC_NAME=, + LC_ADDRESS=, + LC_TELEPHONE=, + LC_MEASUREMENT=, + LC_IDENTIFICATION=. + Note that LC_ALL may not be configured in this + file. For details about the meaning and semantics of these + settings, refer to + locale7. + + + + Example + + + German locale with English messages + + /etc/locale.conf: + + LANG=de_DE.UTF-8 LC_MESSAGES=en_US.UTF-8 - - - - - - See Also - - systemd1, - locale7, - localectl1, - systemd-localed.service8, - systemd-firstboot1 - - + + + + + + See Also + + systemd1, + locale7, + localectl1, + systemd-localed.service8, + systemd-firstboot1 + + diff --git a/man/localectl.xml b/man/localectl.xml index b472b6bd9c7..aae6e0629c7 100644 --- a/man/localectl.xml +++ b/man/localectl.xml @@ -1,6 +1,6 @@ + "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd"> - - - localectl - systemd - - - - Developer - Lennart - Poettering - lennart@poettering.net - - - - - - localectl - 1 - - - - localectl - Control the system locale and keyboard layout settings - - - - - localectl - OPTIONS - COMMAND - - - - - Description - - localectl may be used to - query and change the system locale and keyboard layout - settings. - - The system locale controls the language settings - of system services and of the UI before the user logs - in, such as the display manager, as well as the - default for users after login. - - The keyboard settings control the keyboard - layout used on the text console and of the graphical - UI before the user logs in, such as the display - manager, as well as the default for users after - login. - - Use - systemd-firstboot1 - to initialize the system locale for mounted (but not - booted) system images. - - - - Options - - The following options are understood: - - - - - - Do not query the user - for authentication for privileged - operations. - - - - - - If - set-keymap or - set-x11-keymap is - invoked and this option is passed, then - the keymap will not be converted from - the console to X11, or X11 to console, - respectively. - - - - - - - - - - The following commands are understood: - - - - status - - Show current settings - of the system locale and keyboard - mapping. - - - - set-locale LOCALE... - - Set the system - locale. This takes one or more - assignments such as "LANG=de_DE.utf8", - "LC_MESSAGES=en_GB.utf8", and so - on. See - locale7 - for details on the available settings - and their meanings. Use - list-locales for a - list of available locales (see below). - - - - - list-locales - - List available locales - useful for configuration with - set-locale. - - - - set-keymap MAP [TOGGLEMAP] - - Set the system - keyboard mapping for the console and - X11. This takes a mapping name (such - as "de" or "us"), and possibly a - second one to define a toggle keyboard - mapping. Unless - is - passed, the selected setting is also - applied as the default system keyboard - mapping of X11, after converting it to - the closest matching X11 keyboard - mapping. Use - list-keymaps for a - list of available keyboard mappings - (see below). - - - - list-keymaps - - List available - keyboard mappings for the console, - useful for configuration with - set-keymap. - - - - set-x11-keymap LAYOUT [MODEL [VARIANT [OPTIONS]]] - - Set the system default - keyboard mapping for X11 and the - virtual console. This takes a keyboard - mapping name (such as - de or - us), and possibly a - model, variant, and options, see - kbd4 - for details. Unless - is - passed, the selected setting is also - applied as the system console keyboard - mapping, after converting it to the - closest matching console keyboard - mapping. - - - - list-x11-keymap-models - list-x11-keymap-layouts - list-x11-keymap-variants [LAYOUT] - list-x11-keymap-options - - List available X11 - keymap models, layouts, variants and - options, useful for configuration with - set-keymap. The - command - list-x11-keymap-variants - optionally takes a layout parameter to - limit the output to the variants - suitable for the specific - layout. - - - - - - - Exit status - - On success, 0 is returned, a non-zero failure - code otherwise. - - - - - - See Also - - systemd1, - locale7, - locale.conf5, - vconsole.conf5, - loadkeys1, - kbd4, - - The XKB Configuration Guide - , - systemctl1, - systemd-localed.service8, - systemd-firstboot1 - - + xmlns:xi="http://www.w3.org/2001/XInclude"> + + + localectl + systemd + + + + Developer + Lennart + Poettering + lennart@poettering.net + + + + + + localectl + 1 + + + + localectl + Control the system locale and keyboard layout settings + + + + + localectl + OPTIONS + COMMAND + + + + + Description + + localectl may be used to query and change + the system locale and keyboard layout settings. + + The system locale controls the language settings of system + services and of the UI before the user logs in, such as the + display manager, as well as the default for users after + login. + + The keyboard settings control the keyboard layout used on + the text console and of the graphical UI before the user logs in, + such as the display manager, as well as the default for users + after login. + + Use + systemd-firstboot1 + to initialize the system locale for mounted (but not booted) + system images. + + + + Options + + The following options are understood: + + + + + + Do not query the user for authentication for + privileged operations. + + + + + + If set-keymap or + set-x11-keymap is invoked and this option + is passed, then the keymap will not be converted from the + console to X11, or X11 to console, + respectively. + + + + + + + + + + The following commands are understood: + + + + status + + Show current settings of the system locale and + keyboard mapping. + + + + set-locale LOCALE... + + Set the system locale. This takes one or more + assignments such as "LANG=de_DE.utf8", + "LC_MESSAGES=en_GB.utf8", and so on. See + locale7 + for details on the available settings and their meanings. Use + list-locales for a list of available + locales (see below). + + + + list-locales + + List available locales useful for + configuration with + set-locale. + + + + set-keymap MAP [TOGGLEMAP] + + Set the system keyboard mapping for the + console and X11. This takes a mapping name (such as "de" or + "us"), and possibly a second one to define a toggle keyboard + mapping. Unless is passed, the + selected setting is also applied as the default system + keyboard mapping of X11, after converting it to the closest + matching X11 keyboard mapping. Use + list-keymaps for a list of available + keyboard mappings (see below). + + + + list-keymaps + + List available keyboard mappings for the + console, useful for configuration with + set-keymap. + + + + set-x11-keymap LAYOUT [MODEL [VARIANT [OPTIONS]]] + + Set the system default keyboard mapping for + X11 and the virtual console. This takes a keyboard mapping + name (such as de or us), + and possibly a model, variant, and options, see + kbd4 + for details. Unless is passed, + the selected setting is also applied as the system console + keyboard mapping, after converting it to the closest matching + console keyboard mapping. + + + + list-x11-keymap-models + list-x11-keymap-layouts + list-x11-keymap-variants [LAYOUT] + list-x11-keymap-options + + List available X11 keymap models, layouts, + variants and options, useful for configuration with + set-keymap. The command + list-x11-keymap-variants optionally takes a + layout parameter to limit the output to the variants suitable + for the specific layout. + + + + + + + Exit status + + On success, 0 is returned, a non-zero failure code + otherwise. + + + + + + See Also + + systemd1, + locale7, + locale.conf5, + vconsole.conf5, + loadkeys1, + kbd4, + + The XKB Configuration Guide + , + systemctl1, + systemd-localed.service8, + systemd-firstboot1 + + diff --git a/man/localtime.xml b/man/localtime.xml index 1cbdf682746..184f5808e94 100644 --- a/man/localtime.xml +++ b/man/localtime.xml @@ -1,7 +1,7 @@ + "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd"> - - localtime - systemd - - - - Developer - Lennart - Poettering - lennart@poettering.net - - - Developer - Shawn - Landden - shawnlandden@gmail.com - - - - - - localtime - 5 - - - - localtime - Local timezone configuration file - - - - /etc/localtime -> ../usr/share/zoneinfo/… - - - - Description - - The /etc/localtime file - configures the system-wide timezone of the local - system that is used by applications for presentation - to the user. It should be an absolute or relative - symbolic link pointing to - /usr/share/zoneinfo/, followed by - a timezone identifier such as - Europe/Berlin or - Etc/UTC. The resulting link should - lead to the corresponding binary - tzfile5 - timezone data for the configured timezone. - - Because the timezone identifier is extracted from - the symlink target name of - /etc/localtime, this file may not - be a normal file or hardlink. - - The timezone may be overridden for individual - programs by using the TZ environment variable. See - environ7. - - You may use - timedatectl1 - to change the settings of this file from the command - line during runtime. Use - systemd-firstboot1 - to initialize the time zone on mounted (but not - booted) system images. - - - - See Also - - systemd1, - tzset3, - localtime3, - timedatectl1, - systemd-timedated.service8, - systemd-firstboot1 - - + + localtime + systemd + + + + Developer + Lennart + Poettering + lennart@poettering.net + + + Developer + Shawn + Landden + shawnlandden@gmail.com + + + + + + localtime + 5 + + + + localtime + Local timezone configuration file + + + + /etc/localtime -> ../usr/share/zoneinfo/… + + + + Description + + The /etc/localtime file configures the + system-wide timezone of the local system that is used by + applications for presentation to the user. It should be an + absolute or relative symbolic link pointing to + /usr/share/zoneinfo/, followed by a timezone + identifier such as Europe/Berlin or + Etc/UTC. The resulting link should lead to the + corresponding binary + tzfile5 + timezone data for the configured timezone. + + Because the timezone identifier is extracted from the + symlink target name of /etc/localtime, this + file may not be a normal file or hardlink. + + The timezone may be overridden for individual programs by + using the $TZ environment variable. See + environ7. + + You may use + timedatectl1 + to change the settings of this file from the command line during + runtime. Use + systemd-firstboot1 + to initialize the time zone on mounted (but not booted) system + images. + + + + See Also + + systemd1, + tzset3, + localtime3, + timedatectl1, + systemd-timedated.service8, + systemd-firstboot1 + + diff --git a/man/loginctl.xml b/man/loginctl.xml index 11ed0ee4604..9dda14d4548 100644 --- a/man/loginctl.xml +++ b/man/loginctl.xml @@ -1,6 +1,6 @@ + "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd"> - - - loginctl - systemd - - - - Developer - Lennart - Poettering - lennart@poettering.net - - - - - - loginctl - 1 - - - - loginctl - Control the systemd login manager - - - - - loginctl - OPTIONS - COMMAND - NAME - - - - - Description - - loginctl may be used to - introspect and control the state of the - systemd1 - login manager systemd-logind.service8. - - - - Options - - The following options are understood: - - - - - - Do not query the user - for authentication for privileged - operations. - - - - - - - When showing - session/user/seat properties, limit - display to certain properties as - specified as argument. If not - specified, all set properties are - shown. The argument should be a - property name, such as - Sessions. If - specified more than once, all - properties with the specified names - are shown. - - - - - - - When showing - session/user/seat properties, show all - properties regardless of whether they are - set or not. - - - - - - - Do not ellipsize - process tree entries. - - - - - - - When used with - kill-session, - choose which processes to kill. Must - be one of , or - to select whether - to kill only the leader process of the - session or all processes of the - session. If omitted, defaults to - . - - - - - - - When used with - kill-session or - kill-user, choose - which signal to send to selected - processes. Must be one of the well - known signal specifiers, such as - SIGTERM, - SIGINT or - SIGSTOP. If - omitted, defaults to - SIGTERM. - - - - - - - When used with - user-status and - session-status, - controls the number of journal lines - to show, counting from the most recent - ones. Takes a positive integer - argument. Defaults to 10. - - - - - - - - When used with - user-status and - session-status, - controls the formatting of the journal - entries that are shown. For the - available choices, see - journalctl1. - Defaults to - short. - - - - - - - - - - - - - - Commands - - The following commands are understood: - - Session Commands - - - list-sessions - - List current sessions. - - - - session-status ID... - - Show terse runtime - status information about one or more - sessions, followed by the most recent - log data from the journal. Takes one - or more session identifiers as - parameters. If no session identifiers - are passed the status of the caller's - session is shown. This function is - intended to generate human-readable - output. If you are looking for - computer-parsable output, use - show-session - instead. - - - - show-session ID... - - Show properties of one - or more sessions or the manager - itself. If no argument is specified, - properties of the manager will be - shown. If a session ID is specified, - properties of the session are shown. By - default, empty properties are - suppressed. Use - to show those too. To select specific - properties to show, use - . This - command is intended to be used - whenever computer-parsable output is - required. Use - session-status if - you are looking for formatted - human-readable - output. - - - - activate ID - - Activate a - session. This brings a session into - the foreground, if another session is - currently in the foreground on the - respective seat. Takes a session - identifier as argument. If no argument - is specified the session of the caller - is put into - foreground. - - - - lock-session ID... - unlock-session ID... - - Activates/deactivates - the screen lock on one or more - sessions, if the session supports - it. Takes one or more session - identifiers as arguments. If no - argument is specified the session of - the caller is locked/unlocked. - - - - - lock-sessions - unlock-sessions - - Activates/deactivates - the screen lock on all current - sessions supporting it. - - - - - terminate-session ID... - - Terminates a session. - This kills all processes of the - session and deallocates all resources - attached to the session. - - - - - kill-session ID... - - Send a signal to one - or more processes of the session. Use - to select - which process to kill. Use - to select - the signal to send. - - - - User Commands - - list-users - - List currently logged - in users. - - - - user-status USER... - - Show terse runtime - status information about one or more - logged in users, followed by the most - recent log data from the - journal. Takes one or more user names - or numeric user IDs as parameters. If - no parameters are passed the status of - the caller's user is shown. This - function is intended to generate - human-readable output. If you are - looking for computer-parsable output, - use show-user - instead. Users may be specified by - their usernames or numeric user IDs. - - - - - show-user USER... - - Show properties of one - or more users or the manager - itself. If no argument is specified, - properties of the manager will be - shown. If a user is specified, - properties of the user are shown. By - default, empty properties are - suppressed. Use - to show those too. To select specific - properties to show, use - . This - command is intended to be used - whenever computer-parsable output is - required. Use - user-status if - you are looking for formatted - human-readable - output. - - - - enable-linger USER... - disable-linger USER... - - Enable/disable user - lingering for one or more users. If - enabled for a specific user, a user - manager is spawned for the user at - boot and kept around after - logouts. This allows users who are not - logged in to run long-running - services. Takes one or more user names - or numeric UIDs as argument. If no - argument is specified enables/disables - lingering for the user of the session - of the caller. - - - - terminate-user USER... - - Terminates all - sessions of a user. This kills all - processes of all sessions of the user - and deallocates all runtime resources - attached to the user. - - - - - kill-user USER... - - Send a signal to all - processes of a user. Use - to select - the signal to send. - - - - Seat Commands - - list-seats - - List currently - available seats on the local - system. - - - - seat-status NAME... - - Show terse runtime - status information about one or more - seats. Takes one or more seat names as - parameters. If no seat names are - passed the status of the caller's - session's seat is shown. This function - is intended to generate human-readable - output. If you are looking for - computer-parsable output, use - show-seat - instead. - - - - show-seat NAME... - - Show properties of one - or more seats or the manager - itself. If no argument is specified, - properties of the manager will be - shown. If a seat is specified, - properties of the seat are shown. By - default, empty properties are - suppressed. Use - to show those too. To select specific - properties to show, use - . This - command is intended to be used - whenever computer-parsable output is - required. Use - seat-status if you - are looking for formatted - human-readable - output. - - - - attach NAME DEVICE... - - Persistently attach - one or more devices to a seat. The - devices should be specified via device - paths in the /sys - file system. To create a new seat, - attach at least one graphics card to a - previously unused seat name. Seat - names may consist only of a-z, A-Z, - 0-9, - and - _ and must be - prefixed with seat. - To drop assignment of a device to a - specific seat, just reassign it to a - different seat, or use - flush-devices. - - - - - flush-devices - - Removes all device - assignments previously created with - attach. After this - call, only automatically generated - seats will remain, and all seat - hardware is assigned to - them. - - - - terminate-seat NAME... - - Terminates all - sessions on a seat. This kills all - processes of all sessions on the seat - and deallocates all runtime resources - attached to them. - - - - - - - Exit status - - On success, 0 is returned, a non-zero failure - code otherwise. - - - - - - See Also - - systemd1, - systemctl1, - systemd-logind.service8, - logind.conf5 - - + xmlns:xi="http://www.w3.org/2001/XInclude"> + + + loginctl + systemd + + + + Developer + Lennart + Poettering + lennart@poettering.net + + + + + + loginctl + 1 + + + + loginctl + Control the systemd login manager + + + + + loginctl + OPTIONS + COMMAND + NAME + + + + + Description + + loginctl may be used to introspect and + control the state of the + systemd1 + login manager + systemd-logind.service8. + + + + Options + + The following options are understood: + + + + + + Do not query the user for authentication for + privileged operations. + + + + + + + When showing session/user/seat properties, + limit display to certain properties as specified as argument. + If not specified, all set properties are shown. The argument + should be a property name, such as + Sessions. If specified more than once, all + properties with the specified names are + shown. + + + + + + + When showing session/user/seat properties, + show all properties regardless of whether they are set or + not. + + + + + + + Do not ellipsize process tree entries. + + + + + + + When used with + kill-session, choose which processes to + kill. Must be one of , or + to select whether to kill only the leader + process of the session or all processes of the session. If + omitted, defaults to . + + + + + + + When used with kill-session + or kill-user, choose which signal to send + to selected processes. Must be one of the well known signal + specifiers, such as SIGTERM, + SIGINT or SIGSTOP. + If omitted, defaults to + SIGTERM. + + + + + + + When used with user-status + and session-status, controls the number of + journal lines to show, counting from the most recent ones. + Takes a positive integer argument. Defaults to 10. + + + + + + + + When used with user-status + and session-status, controls the formatting + of the journal entries that are shown. For the available + choices, see + journalctl1. + Defaults to short. + + + + + + + + + + + + + + Commands + + The following commands are understood: + + Session Commands + + + list-sessions + + List current sessions. + + + + session-status ID... + + Show terse runtime status information about + one or more sessions, followed by the most recent log data + from the journal. Takes one or more session identifiers as + parameters. If no session identifiers are passed the status of + the caller's session is shown. This function is intended to + generate human-readable output. If you are looking for + computer-parsable output, use show-session + instead. + + + + show-session ID... + + Show properties of one or more sessions or the + manager itself. If no argument is specified, properties of the + manager will be shown. If a session ID is specified, + properties of the session are shown. By default, empty + properties are suppressed. Use to show + those too. To select specific properties to show, use + . This command is intended to be + used whenever computer-parsable output is required. Use + session-status if you are looking for + formatted human-readable output. + + + + activate ID + + Activate a session. This brings a session into + the foreground, if another session is currently in the + foreground on the respective seat. Takes a session identifier + as argument. If no argument is specified the session of the + caller is put into foreground. + + + + lock-session ID... + unlock-session ID... + + Activates/deactivates the screen lock on one + or more sessions, if the session supports it. Takes one or + more session identifiers as arguments. If no argument is + specified the session of the caller is locked/unlocked. + + + + + lock-sessions + unlock-sessions + + Activates/deactivates the screen lock on all + current sessions supporting it. + + + + terminate-session ID... + + Terminates a session. This kills all processes + of the session and deallocates all resources attached to the + session. + + + + kill-session ID... + + Send a signal to one or more processes of the + session. Use to select which + process to kill. Use to select the + signal to send. + + + + User Commands + + list-users + + List currently logged in users. + + + + + user-status USER... + + Show terse runtime status information about + one or more logged in users, followed by the most recent log + data from the journal. Takes one or more user names or numeric + user IDs as parameters. If no parameters are passed the status + of the caller's user is shown. This function is intended to + generate human-readable output. If you are looking for + computer-parsable output, use show-user + instead. Users may be specified by their usernames or numeric + user IDs. + + + + show-user USER... + + Show properties of one or more users or the + manager itself. If no argument is specified, properties of the + manager will be shown. If a user is specified, properties of + the user are shown. By default, empty properties are + suppressed. Use to show those too. To + select specific properties to show, use + . This command is intended to be + used whenever computer-parsable output is required. Use + user-status if you are looking for + formatted human-readable output. + + + + enable-linger USER... + disable-linger USER... + + Enable/disable user lingering for one or more + users. If enabled for a specific user, a user manager is + spawned for the user at boot and kept around after logouts. + This allows users who are not logged in to run long-running + services. Takes one or more user names or numeric UIDs as + argument. If no argument is specified enables/disables + lingering for the user of the session of the caller. + + + + + terminate-user USER... + + Terminates all sessions of a user. This kills + all processes of all sessions of the user and deallocates all + runtime resources attached to the user. + + + + kill-user USER... + + Send a signal to all processes of a user. Use + to select the signal to send. + + + + + Seat Commands + + list-seats + + List currently available seats on the local + system. + + + + seat-status NAME... + + Show terse runtime status information about + one or more seats. Takes one or more seat names as parameters. + If no seat names are passed the status of the caller's + session's seat is shown. This function is intended to generate + human-readable output. If you are looking for + computer-parsable output, use show-seat + instead. + + + + show-seat NAME... + + Show properties of one or more seats or the + manager itself. If no argument is specified, properties of the + manager will be shown. If a seat is specified, properties of + the seat are shown. By default, empty properties are + suppressed. Use to show those too. To + select specific properties to show, use + . This command is intended to be + used whenever computer-parsable output is required. Use + seat-status if you are looking for + formatted human-readable output. + + + + attach NAME DEVICE... + + Persistently attach one or more devices to a + seat. The devices should be specified via device paths in the + /sys file system. To create a new seat, + attach at least one graphics card to a previously unused seat + name. Seat names may consist only of a-z, A-Z, 0-9, + - and _ and must be + prefixed with seat. To drop assignment of a + device to a specific seat, just reassign it to a different + seat, or use flush-devices. + + + + + flush-devices + + Removes all device assignments previously + created with attach. After this call, only + automatically generated seats will remain, and all seat + hardware is assigned to them. + + + + terminate-seat NAME... + + Terminates all sessions on a seat. This kills + all processes of all sessions on the seat and deallocates all + runtime resources attached to them. + + + + + + + Exit status + + On success, 0 is returned, a non-zero failure code + otherwise. + + + + + + See Also + + systemd1, + systemctl1, + systemd-logind.service8, + logind.conf5 + + diff --git a/man/logind.conf.xml b/man/logind.conf.xml index e927cf44511..0818497be09 100644 --- a/man/logind.conf.xml +++ b/man/logind.conf.xml @@ -1,7 +1,7 @@ + "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd"> - - logind.conf - systemd - - - - Developer - Lennart - Poettering - lennart@poettering.net - - - - - - logind.conf - 5 - - - - logind.conf - logind.conf.d - Login manager configuration files - - - - /etc/systemd/logind.conf - /etc/systemd/logind.conf.d/*.conf - /run/systemd/logind.conf.d/*.conf - /usr/lib/systemd/logind.conf.d/*.conf - - - - Description - - These files configure various parameters of the systemd login manager, systemd-logind.service8. - - - - - - - Options - - All options are configured in the - [Login] section: - - - - - NAutoVTs= - - Takes a positive - integer. Configures how many virtual - terminals (VTs) to allocate by default - that, when switched to and are - previously unused, - autovt services are - automatically spawned on. These - services are instantiated from the - template unit - autovt@.service - for the respective VT TTY name, - for example, autovt@tty4.service. By - default, - autovt@.service - is linked to - getty@.service. - In other words, login prompts are started - dynamically as the user switches to - unused virtual terminals. Hence, this - parameter controls how many login - gettys are - available on the VTs. If a VT is - already used by some other subsystem - (for example, a graphical login), this - kind of activation will not be - attempted. Note that the VT configured - in ReserveVT= is - always subject to this kind of - activation, even if it is not one of - the VTs configured with the - NAutoVTs= - directive. Defaults to 6. When set to - 0, automatic spawning of - autovt services is - disabled. - - - - ReserveVT= - - Takes a positive - integer. Identifies one - virtual terminal that shall - unconditionally be reserved for - autovt@.service - activation (see above). The VT - selected with this option will be - marked busy unconditionally, so that no - other subsystem will allocate it. This - functionality is useful to ensure that, - regardless of how many VTs are allocated - by other subsystems, one login - getty is always - available. Defaults to 6 (in other - words, there will always be a - getty available on - Alt-F6.). When set to 0, VT - reservation is - disabled. - - - - KillUserProcesses= - - Takes a boolean - argument. Configures whether the - processes of a user should be killed - when the user completely logs out (i.e. after - the user's last session ended). Defaults to - no. - - Note that setting - KillUserProcesses=1 - will break tools like - screen1. - - - - KillOnlyUsers= - KillExcludeUsers= - - These settings take - space-separated lists of usernames - that influence the effect of - KillUserProcesses=. If - not empty, only processes of users - listed in - KillOnlyUsers= will - be killed when they log out - entirely. Processes of users listed in - KillExcludeUsers= - are excluded from being - killed. KillExcludeUsers= - defaults to root - and takes precedence over - KillOnlyUsers=, - which defaults to the empty list. - - - - IdleAction= - - Configures the action - to take when the system is idle. Takes - one of ignore, - poweroff, - reboot, - halt, - kexec, - suspend, - hibernate, - hybrid-sleep, and - lock. Defaults to - ignore. - - Note that this requires that - user sessions correctly report the - idle status to the system. The system - will execute the action after all - sessions report that they are idle, - no idle inhibitor lock is active, - and subsequently, the time configured - with IdleActionSec= - (see below) has expired. - - - - - IdleActionSec= - - Configures the delay - after which the action configured in - IdleAction= (see - above) is taken after the system is - idle. - - - - InhibitDelayMaxSec= - - Specifies the maximum - time a system shutdown or sleep - request is delayed due to an inhibitor - lock of type delay - being active before the inhibitor is - ignored and the operation executes - anyway. Defaults to - 5. - - - - HandlePowerKey= - HandleSuspendKey= - HandleHibernateKey= - HandleLidSwitch= - HandleLidSwitchDocked= - - Controls whether - logind shall handle the system power - and sleep keys and the lid switch to - trigger actions such as system - power-off or suspend. Can be one of - ignore, - poweroff, - reboot, - halt, - kexec, - suspend, - hibernate, - hybrid-sleep, and - lock. If - ignore, logind will - never handle these keys. If - lock, all running - sessions will be screen-locked; - otherwise, the specified action will - be taken in the respective event. Only - input devices with the - power-switch udev - tag will be watched for key/lid switch - events. HandlePowerKey= - defaults to - poweroff. - HandleSuspendKey= - and - HandleLidSwitch= - default to suspend. - HandleLidSwitchDocked= - defaults to ignore. - HandleHibernateKey= - defaults to - hibernate. If the - system is inserted in a docking station, - or if more than one display is connected, - the action specified by - HandleLidSwitchDocked= - occurs; otherwise the - HandleLidSwitch= - action occurs. - - - - PowerKeyIgnoreInhibited= - SuspendKeyIgnoreInhibited= - HibernateKeyIgnoreInhibited= - LidSwitchIgnoreInhibited= - - Controls whether - actions triggered by the power and - sleep keys and the lid switch are - subject to inhibitor locks. These - settings take boolean arguments. If - no, the inhibitor - locks taken by applications in order - to block the requested operation are - respected. If yes, - the requested operation is executed in - any - case. PowerKeyIgnoreInhibited=, - SuspendKeyIgnoreInhibited= - and - HibernateKeyIgnoreInhibited= - default to no. - LidSwitchIgnoreInhibited= - defaults to - yes. This means - that the lid switch does not respect - suspend blockers by default, but the - power and sleep keys do. - - - - - RuntimeDirectorySize= - - Sets the size limit on - the - $XDG_RUNTIME_DIR - runtime directory for each user who - logs in. Takes a size in bytes, - optionally suffixed with the usual K, G, - M, and T suffixes, to the base 1024 - (IEC). Alternatively, a numerical - percentage suffixed by % - may be specified, which sets the size - limit relative to the amount of - physical RAM. Defaults to 10%. Note - that this size is a safety limit - only. As each runtime directory is a - tmpfs file system, it will only consume - as much memory as is needed. - - - - - RemoveIPC= - - Controls whether - System V and POSIX IPC objects - belonging to the user shall be removed - when the user fully logs out. Takes a - boolean argument. If enabled, the user - may not consume IPC resources after - the last of the user's sessions - terminated. This covers System V - semaphores, shared memory and message - queues, as well as POSIX shared memory - and message queues. Note that IPC - objects of the root user are excluded - from the effect of this - setting. Defaults to - yes. - - - - - - - See Also - - systemd1, - systemd-logind.service8, - loginctl1, - systemd-system.conf5 - - + xmlns:xi="http://www.w3.org/2001/XInclude"> + + logind.conf + systemd + + + + Developer + Lennart + Poettering + lennart@poettering.net + + + + + + logind.conf + 5 + + + + logind.conf + logind.conf.d + Login manager configuration files + + + + /etc/systemd/logind.conf + /etc/systemd/logind.conf.d/*.conf + /run/systemd/logind.conf.d/*.conf + /usr/lib/systemd/logind.conf.d/*.conf + + + + Description + + These files configure various parameters of the systemd login manager, systemd-logind.service8. + + + + + + + Options + + All options are configured in the + [Login] section: + + + + + NAutoVTs= + + Takes a positive integer. Configures how many + virtual terminals (VTs) to allocate by default that, when + switched to and are previously unused, + autovt services are automatically spawned + on. These services are instantiated from the template unit + autovt@.service for the respective VT TTY + name, for example, autovt@tty4.service. + By default, autovt@.service is linked to + getty@.service. In other words, login + prompts are started dynamically as the user switches to unused + virtual terminals. Hence, this parameter controls how many + login gettys are available on the VTs. If a + VT is already used by some other subsystem (for example, a + graphical login), this kind of activation will not be + attempted. Note that the VT configured in + ReserveVT= is always subject to this kind + of activation, even if it is not one of the VTs configured + with the NAutoVTs= directive. Defaults to + 6. When set to 0, automatic spawning of + autovt services is + disabled. + + + + ReserveVT= + + Takes a positive integer. Identifies one + virtual terminal that shall unconditionally be reserved for + autovt@.service activation (see above). + The VT selected with this option will be marked busy + unconditionally, so that no other subsystem will allocate it. + This functionality is useful to ensure that, regardless of how + many VTs are allocated by other subsystems, one login + getty is always available. Defaults to 6 + (in other words, there will always be a + getty available on Alt-F6.). When set to 0, + VT reservation is disabled. + + + + KillUserProcesses= + + Takes a boolean argument. Configures whether + the processes of a user should be killed when the user + completely logs out (i.e. after the user's last session + ended). Defaults to no. + + Note that setting KillUserProcesses=1 + will break tools like + screen1. + + + + KillOnlyUsers= + KillExcludeUsers= + + These settings take space-separated lists of + usernames that influence the effect of + KillUserProcesses=. If not empty, only + processes of users listed in KillOnlyUsers= + will be killed when they log out entirely. Processes of users + listed in KillExcludeUsers= are excluded + from being killed. KillExcludeUsers= + defaults to root and takes precedence over + KillOnlyUsers=, which defaults to the empty + list. + + + + IdleAction= + + Configures the action to take when the system + is idle. Takes one of + ignore, + poweroff, + reboot, + halt, + kexec, + suspend, + hibernate, + hybrid-sleep, and + lock. + Defaults to ignore. + + Note that this requires that user sessions correctly + report the idle status to the system. The system will execute + the action after all sessions report that they are idle, no + idle inhibitor lock is active, and subsequently, the time + configured with IdleActionSec= (see below) + has expired. + + + + + IdleActionSec= + + Configures the delay after which the action + configured in IdleAction= (see above) is + taken after the system is idle. + + + + InhibitDelayMaxSec= + + Specifies the maximum time a system shutdown + or sleep request is delayed due to an inhibitor lock of type + delay being active before the inhibitor is + ignored and the operation executes anyway. Defaults to + 5. + + + + HandlePowerKey= + HandleSuspendKey= + HandleHibernateKey= + HandleLidSwitch= + HandleLidSwitchDocked= + + Controls whether logind shall handle the + system power and sleep keys and the lid switch to trigger + actions such as system power-off or suspend. Can be one of + ignore, + poweroff, + reboot, + halt, + kexec, + suspend, + hibernate, + hybrid-sleep, and + lock. + If ignore, logind will never handle these + keys. If lock, all running sessions will be + screen-locked; otherwise, the specified action will be taken + in the respective event. Only input devices with the + power-switch udev tag will be watched for + key/lid switch events. HandlePowerKey= + defaults to poweroff. + HandleSuspendKey= and + HandleLidSwitch= default to + suspend. + HandleLidSwitchDocked= defaults to + ignore. + HandleHibernateKey= defaults to + hibernate. If the system is inserted in a + docking station, or if more than one display is connected, the + action specified by HandleLidSwitchDocked= + occurs; otherwise the HandleLidSwitch= + action occurs. + + + + PowerKeyIgnoreInhibited= + SuspendKeyIgnoreInhibited= + HibernateKeyIgnoreInhibited= + LidSwitchIgnoreInhibited= + + Controls whether actions triggered by the + power and sleep keys and the lid switch are subject to + inhibitor locks. These settings take boolean arguments. If + no, the inhibitor locks taken by + applications in order to block the requested operation are + respected. If yes, the requested operation + is executed in any case. + PowerKeyIgnoreInhibited=, + SuspendKeyIgnoreInhibited= and + HibernateKeyIgnoreInhibited= default to + no. + LidSwitchIgnoreInhibited= defaults to + yes. This means that the lid switch does + not respect suspend blockers by default, but the power and + sleep keys do. + + + + RuntimeDirectorySize= + + Sets the size limit on the + $XDG_RUNTIME_DIR runtime directory for each + user who logs in. Takes a size in bytes, optionally suffixed + with the usual K, G, M, and T suffixes, to the base 1024 + (IEC). Alternatively, a numerical percentage suffixed by + % may be specified, which sets the size + limit relative to the amount of physical RAM. Defaults to 10%. + Note that this size is a safety limit only. As each runtime + directory is a tmpfs file system, it will only consume as much + memory as is needed. + + + + RemoveIPC= + + Controls whether System V and POSIX IPC + objects belonging to the user shall be removed when the user + fully logs out. Takes a boolean argument. If enabled, the user + may not consume IPC resources after the last of the user's + sessions terminated. This covers System V semaphores, shared + memory and message queues, as well as POSIX shared memory and + message queues. Note that IPC objects of the root user are + excluded from the effect of this setting. Defaults to + yes. + + + + + + + See Also + + systemd1, + systemd-logind.service8, + loginctl1, + systemd-system.conf5 + + diff --git a/man/machine-id.xml b/man/machine-id.xml index 725370d32dc..27a84617564 100644 --- a/man/machine-id.xml +++ b/man/machine-id.xml @@ -1,7 +1,7 @@ + "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd"> - - machine-id - systemd - - - - Developer - Lennart - Poettering - lennart@poettering.net - - - - - - machine-id - 5 - - - - machine-id - Local machine ID configuration file - - - - /etc/machine-id - - - - Description - - The /etc/machine-id file - contains the unique machine ID of the local system - that is set during installation. The machine ID is a - single newline-terminated, hexadecimal, 32-character, - lowercase machine ID string. When decoded from - hexadecimal, this corresponds with a 16-byte/128-bit - string. - - The machine ID is usually generated from a - random source during system installation and stays - constant for all subsequent boots. Optionally, for - stateless systems, it is generated during runtime at - boot if it is found to be empty. - - The machine ID does not change based on user - configuration or when hardware is replaced. - - This machine ID adheres to the same format and - logic as the D-Bus machine ID. - - Programs may use this ID to identify the host - with a globally unique ID in the network, which does - not change even if the local network configuration - changes. Due to this and its greater length, it is - a more useful replacement for the - gethostid3 - call that POSIX specifies. - - The - systemd-machine-id-setup1 - tool may be used by installer tools to initialize the - machine ID at install time. Use - systemd-firstboot1 - to initialize it on mounted (but not booted) system - images. - - - - Relation to OSF UUIDs - - Note that the machine ID historically is not an - OSF UUID as defined by RFC - 4122, nor a Microsoft GUID; however, starting with - systemd v30, newly generated machine IDs do - qualify as v4 UUIDs. - - In order to maintain compatibility with existing - installations, an application requiring a UUID should - decode the machine ID, and then apply the following - operations to turn it into a valid OSF v4 UUID. With - id being an unsigned character - array: - - /* Set UUID version to 4 --- truly random generation */ + + machine-id + systemd + + + + Developer + Lennart + Poettering + lennart@poettering.net + + + + + + machine-id + 5 + + + + machine-id + Local machine ID configuration file + + + + /etc/machine-id + + + + Description + + The /etc/machine-id file contains the + unique machine ID of the local system that is set during + installation. The machine ID is a single newline-terminated, + hexadecimal, 32-character, lowercase machine ID string. When + decoded from hexadecimal, this corresponds with a 16-byte/128-bit + string. + + The machine ID is usually generated from a random source + during system installation and stays constant for all subsequent + boots. Optionally, for stateless systems, it is generated during + runtime at boot if it is found to be empty. + + The machine ID does not change based on user configuration + or when hardware is replaced. + + This machine ID adheres to the same format and logic as the + D-Bus machine ID. + + Programs may use this ID to identify the host with a + globally unique ID in the network, which does not change even if + the local network configuration changes. Due to this and its + greater length, it is a more useful replacement for the + gethostid3 + call that POSIX specifies. + + The + systemd-machine-id-setup1 + tool may be used by installer tools to initialize the machine ID + at install time. Use + systemd-firstboot1 + to initialize it on mounted (but not booted) system images. + + + + Relation to OSF UUIDs + + Note that the machine ID historically is not an OSF UUID as + defined by RFC + 4122, nor a Microsoft GUID; however, starting with systemd + v30, newly generated machine IDs do qualify as v4 UUIDs. + + In order to maintain compatibility with existing + installations, an application requiring a UUID should decode the + machine ID, and then apply the following operations to turn it + into a valid OSF v4 UUID. With id being an + unsigned character array: + + /* Set UUID version to 4 --- truly random generation */ id[6] = (id[6] & 0x0F) | 0x40; /* Set the UUID variant to DCE */ id[8] = (id[8] & 0x3F) | 0x80; - (This code is inspired by - generate_random_uuid() of - drivers/char/random.c from the - Linux kernel sources.) - - - - - History - - The simple configuration file format of - /etc/machine-id originates in the - /var/lib/dbus/machine-id file - introduced by D-Bus. In fact, this latter file might be a - symlink to - /etc/machine-id. - - - - See Also - - systemd1, - systemd-machine-id-setup1, - gethostid3, - hostname5, - machine-info5, - os-release5, - sd-id1283, - sd_id128_get_machine3, - systemd-firstboot1 - - + (This code is inspired by + generate_random_uuid() of + drivers/char/random.c from the Linux kernel + sources.) + + + + + History + + The simple configuration file format of + /etc/machine-id originates in the + /var/lib/dbus/machine-id file introduced by + D-Bus. In fact, this latter file might be a symlink to + /etc/machine-id. + + + + See Also + + systemd1, + systemd-machine-id-setup1, + gethostid3, + hostname5, + machine-info5, + os-release5, + sd-id1283, + sd_id128_get_machine3, + systemd-firstboot1 + + diff --git a/man/machine-info.xml b/man/machine-info.xml index 4dd3741c8aa..518face143e 100644 --- a/man/machine-info.xml +++ b/man/machine-info.xml @@ -1,7 +1,7 @@ + "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd"> - - machine-info - systemd - - - - Developer - Lennart - Poettering - lennart@poettering.net - - - - - - machine-info - 5 - - - - machine-info - Local machine information file - - - - /etc/machine-info - - - - Description - - The /etc/machine-info file - contains machine metadata. - - The basic file format of - machine-info is a - newline-separated list of environment-like - shell-compatible variable assignments. It is possible - to source the configuration from shell scripts, - however, beyond mere variable assignments no shell - features are supported, allowing applications to read - the file without implementing a shell compatible - execution engine. - - /etc/machine-info contains - metadata about the machine that is set by the user or - administrator. - - Depending on the operating system other - configuration files might be checked for machine - information as well, however only as fallback. - - You may use - hostnamectl1 - to change the settings of this file from the command - line. - - - - Options - - The following machine metadata parameters may - be set using - /etc/machine-info: - - - - - PRETTY_HOSTNAME= - - A pretty - human-readable UTF-8 machine identifier - string. This should contain a name - like Lennart's - Laptop which is useful to - present to the user and does not - suffer by the syntax limitations of - internet domain names. If possible, the - internet hostname as configured in - /etc/hostname - should be kept similar to this - one. Example: if this value is - Lennart's Computer - an Internet hostname of - lennarts-computer - might be a good choice. If this - parameter is not set, an application - should fall back to the Internet host - name for presentation - purposes. - - - - ICON_NAME= - - An icon identifying - this machine according to the XDG - Icon Naming Specification. If - this parameter is not set, an - application should fall back to - computer or a - similar icon name. - - - - CHASSIS= - - The chassis - type. Currently, the following chassis - types are defined: - desktop, - laptop, - server, - tablet, - handset, - watch, and - embedded as well as - the special chassis types - vm and - container for - virtualized systems that lack an - immediate physical chassis. Note that - many systems allow detection of the - chassis type automatically (based on - firmware information or - suchlike). This setting (if set) shall - take precedence over automatically - detected information and is useful to - override misdetected configuration or - to manually configure the chassis type - where automatic detection is not - available. - - - - DEPLOYMENT= - - Describes the system - deployment environment. One of the - following is suggested: - development, - integration, - staging, - production. - - - - - LOCATION= - - Describes the system - location if applicable and - known. Takes a human-friendly, - free-form string. This may be as - generic as Berlin, - Germany or as specific as - Left Rack, 2nd - Shelf. - - - - - - Example - - PRETTY_HOSTNAME="Lennart's Tablet" + + machine-info + systemd + + + + Developer + Lennart + Poettering + lennart@poettering.net + + + + + + machine-info + 5 + + + + machine-info + Local machine information file + + + + /etc/machine-info + + + + Description + + The /etc/machine-info file contains + machine metadata. + + The basic file format of machine-info + is a newline-separated list of environment-like shell-compatible + variable assignments. It is possible to source the configuration + from shell scripts, however, beyond mere variable assignments no + shell features are supported, allowing applications to read the + file without implementing a shell compatible execution + engine. + + /etc/machine-info contains metadata + about the machine that is set by the user or administrator. + + Depending on the operating system other configuration files + might be checked for machine information as well, however only as + fallback. + + You may use + hostnamectl1 + to change the settings of this file from the command line. + + + + Options + + The following machine metadata parameters may be set using + /etc/machine-info: + + + + + PRETTY_HOSTNAME= + + A pretty human-readable UTF-8 machine + identifier string. This should contain a name like + Lennart's Laptop which is useful to present + to the user and does not suffer by the syntax limitations of + internet domain names. If possible, the internet hostname as + configured in /etc/hostname should be + kept similar to this one. Example: if this value is + Lennart's Computer an Internet hostname of + lennarts-computer might be a good choice. + If this parameter is not set, an application should fall back + to the Internet host name for presentation + purposes. + + + + ICON_NAME= + + An icon identifying this machine according to + the XDG + Icon Naming Specification. If this parameter is not + set, an application should fall back to + computer or a similar icon + name. + + + + CHASSIS= + + The chassis type. Currently, the following + chassis types are defined: + desktop, + laptop, + server, + tablet, + handset, + watch, and + embedded + as well as the special chassis types + vm and + container for + virtualized systems that lack an immediate physical chassis. + Note that many systems allow detection of the chassis type + automatically (based on firmware information or suchlike). + This setting (if set) shall take precedence over automatically + detected information and is useful to override misdetected + configuration or to manually configure the chassis type where + automatic detection is not available. + + + + DEPLOYMENT= + + Describes the system deployment environment. + One of the following is suggested: + development, + integration, + staging, + production. + + + + + LOCATION= + + Describes the system location if applicable + and known. Takes a human-friendly, free-form string. This may + be as generic as Berlin, Germany or as + specific as Left Rack, 2nd Shelf. + + + + + + + Example + + PRETTY_HOSTNAME="Lennart's Tablet" ICON_NAME=computer-tablet CHASSIS=tablet DEPLOYMENT=production - - - - See Also - - systemd1, - os-release5, - hostname5, - machine-id5, - hostnamectl1, - systemd-hostnamed.service8 - - + + + + See Also + + systemd1, + os-release5, + hostname5, + machine-id5, + hostnamectl1, + systemd-hostnamed.service8 + + diff --git a/man/machinectl.xml b/man/machinectl.xml index 61ea1c45d8f..9b07af42264 100644 --- a/man/machinectl.xml +++ b/man/machinectl.xml @@ -1,6 +1,6 @@ + "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd"> - - - machinectl - systemd - - - - Developer - Lennart - Poettering - lennart@poettering.net - - - - - - machinectl - 1 - - - - machinectl - Control the systemd machine manager - - - - - machinectl - OPTIONS - COMMAND - NAME - - - - - Description - - machinectl may be used to - introspect and control the state of the - systemd1 - virtual machine and container registration manager systemd-machined.service8. - - - - Options - - The following options are understood: - - - - - - - When showing machine - or image properties, limit the output - to certain properties as specified by - the argument. If not specified, all - set properties are shown. The argument - should be a property name, such as - Name. If specified - more than once, all properties with - the specified names are - shown. - - - - - - - When showing machine - or image properties, show all - properties regardless of whether they - are set or not. - - When listing VM or container - images, do not suppress images - beginning in a dot character - (.). - - - - - - - Do not ellipsize - process tree entries. - - - - - - - Do not query the user - for authentication for privileged - operations. - - - - - - When used with - kill, - choose which processes to kill. Must - be one of , or - to select whether - to kill only the leader process of the - machine or all processes of the - machine. If omitted, defaults to - . - - - - - - - When used with - kill, choose - which signal to send to selected - processes. Must be one of the - well-known signal specifiers, such as - SIGTERM, - SIGINT or - SIGSTOP. If - omitted, defaults to - SIGTERM. - - - - - - When used with - bind creates the - destination directory before applying - the bind mount. - - - - - - - When used with - bind applies a - read-only bind - mount. - - - - - - - - When used with - status, controls - the number of journal lines to show, - counting from the most recent - ones. Takes a positive integer - argument. Defaults to 10. - - - - - - - - When used with - status, controls - the formatting of the journal entries - that are shown. For the available - choices, see - journalctl1. - Defaults to - short. - - - - - - When downloading a - container or VM image, specify whether - the image shall be verified before it - is made available. Takes one of - no, - checksum and - signature. If - no no verification - is done. If - checksum is - specified the download is checked for - integrity after transfer is complete, - but no signatures are verified. If - signature is - specified, the checksum is verified - and the images's signature is checked - against a local keyring of trustable - vendors. It is strongly recommended to - set this option to - signature if the - server and protocol support this. - Defaults to - signature. - - - - - - When downloading a - container or VM image, and a local - copy by the specified local machine - name already exists, delete it first - and replace it by the newly downloaded - image. - - - - - - Specifies the index - server to use for downloading - dkr images with the - pull-dkr. Takes a - http://, - https:// URL. - - - - - - - - - - - - - - Commands - - The following commands are understood: - - Machine Commands - - - list - - List currently running - (online) virtual machines and - containers. To enumerate container - images that can be started, - use list-images - (see below). - - - - status NAME... - - Show terse runtime - status information about one or more - virtual machines and containers, - followed by the most recent log data - from the journal. This function is - intended to generate human-readable - output. If you are looking for - computer-parsable output, use - show instead. Note - that the log data shown is reported by - the virtual machine or container - manager, and frequently contains - console output of the machine, but not - necessarily journal contents of the - machine itself. - - - - show NAME... - - Show properties of one - or more registered virtual machines or - containers or the manager itself. If - no argument is specified, properties - of the manager will be shown. If an - NAME is specified, properties of this - virtual machine or container are - shown. By default, empty properties - are suppressed. Use - to show those - too. To select specific properties to - show, use - . This - command is intended to be used - whenever computer-parsable output is - required. Use - status if you are - looking for formatted human-readable - output. - - - - start NAME... - - Start a container as a - system service, using - systemd-nspawn1. - This starts - systemd-nspawn@.service, - instantiated for the specified machine - name, similar to the effect of - systemctl start on - the service - name. systemd-nspawn - looks for a container image by the - specified name in - /var/lib/machines/ - (and other search paths, see below) and runs - it. Use list-images - (see below), for listing available - container images to start. - - Note that - systemd-machined.service8 - also interfaces with a variety of - other container and VM managers, - systemd-nspawn is - just one implementation of it. Most of - the commands available in - machinectl may be - used on containers or VMs controlled - by other managers, not just - systemd-nspawn. Starting - VMs and container images on those - managers requires manager-specific - tools. - - To interactively start a - container on the command line with - full access to the container's - console, please invoke - systemd-nspawn - directly. To stop a running container - use machinectl - poweroff, see - below. - - - - login NAME - - Open an interactive terminal login - session to a container. This will - create a TTY connection to a specific - container and asks for the execution of a - getty on it. Note that this is only - supported for containers running - systemd1 - as init system. - - This command will open a full - login prompt on the container, which - then asks for username and - password. Use - systemd-run1 - with the - switch to invoke a single command, - either interactively or in the - background within a local - container. - - - - enable NAME... - disable NAME... - - Enable or disable a - container as a system service to start - at system boot, using - systemd-nspawn1. - This enables or disables - systemd-nspawn@.service, - instantiated for the specified machine - name, similar to the effect of - systemctl enable or - systemctl disable - on the service name. - - - - poweroff NAME... - - Power off one or more - containers. This will trigger a reboot - by sending SIGRTMIN+4 to the - container's init process, which causes - systemd-compatible init systems to - shut down cleanly. This operation does - not work on containers that do not run - a - systemd1-compatible - init system, such as sysvinit. Use - terminate (see - below) to immediately terminate a - container or VM, without cleanly - shutting it down. - - - - reboot NAME... - - Reboot one or more - containers. This will trigger a reboot - by sending SIGINT to the container's - init process, which is roughly - equivalent to pressing Ctrl+Alt+Del on - a non-containerized system, and is - compatible with containers running any - system manager. - - - - terminate NAME... - - Immediately terminates - a virtual machine or container, - without cleanly shutting it down. This - kills all processes of the virtual - machine or container and deallocates - all resources attached to that - instance. Use - poweroff to issue a - clean shutdown request. - - - - kill NAME... - - Send a signal to one - or more processes of the virtual - machine or container. This means - processes as seen by the host, not the - processes inside the virtual machine - or container. - Use to - select which process to kill. Use - to select - the signal to send. - - - - bind NAME PATH [PATH] - - Bind mounts a - directory from the host into the - specified container. The first - directory argument is the source - directory on the host, the second - directory argument the source - directory on the host. When the latter - is omitted the destination path in the - container is the same as the source - path on the host. When combined with - the - switch a ready-only bind mount is - created. When combined with the - switch the - destination path is first created - before the mount is applied. Note that - this option is currently only - supported for - systemd-nspawn1 - containers. - - - - copy-to NAME PATH [PATH] - - Copies files or - directories from the host system into - a running container. Takes a container - name, followed by the source path on - the host and the destination path in - the container. If the destination path - is omitted the same as the source path - is used. - - - - - copy-from NAME PATH [PATH] - - Copies files or - directories from a container into the - host system. Takes a container name, - followed by the source path in the - container the destination path on the - host. If the destination path is - omitted the same as the source path is - used. - - - - Image Commands - - - list-images - - Show a list of locally - installed container and VM - images. This enumerates all raw disk - images and container directories and - subvolumes in - /var/lib/machines/ (and other search paths, see below). Use - start (see above) - to run a container off one of the - listed images. Note that by default - containers whose name begins with a - dot (.) are not - shown. To show these too, specify - . Note that a - special image .host - always implicitly exists and refers to - the image the host itself is booted - from. - - - - image-status NAME... - - Show terse status - information about one or more - container or VM images. This function - is intended to generate human-readable - output. Use - show-image (see - below) to generate computer-parsable - output instead. - - - - show-image NAME... - - Show properties of one - or more registered virtual machine or - container images, or the manager - itself. If no argument is specified, - properties of the manager will be - shown. If an NAME is specified, - properties of this virtual machine or - container image are shown. By default, - empty properties are suppressed. Use - to show those - too. To select specific properties to - show, use - . This - command is intended to be used - whenever computer-parsable output is - required. Use - image-status if you - are looking for formatted - human-readable - output. - - - - clone NAME NAME - - Clones a container or - disk image. The arguments specify the - name of the image to clone and the - name of the newly cloned image. Note - that plain directory container images - are cloned into subvolume images with - this command. Note that cloning a - container or VM image is optimized for - btrfs file systems, and might not be - efficient on others, due to file - system limitations. - - - - rename NAME NAME - - Renames a container or - disk image. The arguments specify the - name of the image to rename and the - new name of the - image. - - - - read-only NAME [BOOL] - - Marks or (unmarks) a - container or disk image - read-only. Takes a VM or container - image name, followed by a boolean as - arguments. If the boolean is omitted, - positive is implied, i.e. the image is - marked read-only. - - - - - remove NAME... - - Removes one or more - container or disk images. The special - image .host, which - refers to the host's own directory - tree may not be - removed. - - - - - Image Transfer Commands - - - pull-tar URL [NAME] - - Downloads a - .tar container - image from the specified URL, and - makes it available under the specified - local machine name. The URL must be of - type http:// or - https://, and must - refer to a .tar, - .tar.gz, - .tar.xz or - .tar.bz2 archive - file. If the local machine name is - omitted the name it is automatically - derived from the last component of the - URL, with its suffix removed. - - The image is verified before it - is made available, unless - is - specified. Verification is done via - SHA256SUMS and SHA256SUMS.gpg files, - that need to be made available on the - same web server, under the same URL as - the .tar file, - but with the last component (the - filename) of the URL replaced. With - - only the SHA256 checksum for the file - is verified, based on the - SHA256SUMS - file. With - - the SHA256SUMS file is first verified - with detached GPG signature file - SHA256SUMS.gpg. The - public key for this verification step - needs to be available in - /usr/lib/systemd/import-pubring.gpg - or - /etc/systemd/import-pubring.gpg. - - The container image will be - downloaded and stored in a read-only - subvolume in - /var/lib/machines/, - that is named after the specified URL - and its HTTP etag. A writable snapshot - is then taken from this subvolume, and - named after the specified local - name. This behaviour ensures that - creating multiple container instances - of the same URL is efficient, as - multiple downloads are not - necessary. In order to create only the - read-only image, and avoid creating - its writable snapshot, specify - - as local machine - name. - - Note that the read-only - subvolume is prefixed with - .tar-, and - is thus now shown by - list-images, unless - is passed. - - Note that pressing C-c during - execution of this command will not - abort the download. Use - cancel-transfer, - described below. - - - - pull-raw URL [NAME] - - Downloads a - .raw container or - VM disk image from the specified URL, - and makes it available under the - specified local machine name. The URL - must be of type - http:// or - https://. The - container image must either be a - .qcow2 or raw - disk image, optionally compressed as - .gz, - .xz, or - .bz2. If the - local machine name is omitted the name - it is automatically derived from the - last component of the URL, with its - suffix removed. - - Image verification is identical - for raw and tar images (see above). - - If the the downloaded image is - in .qcow2 format - it es converted into a raw image file - before it is made available. - - Downloaded images of this type - will be placed as read-only - .raw file in - /var/lib/machines/. A - local, writable (reflinked) copy is - then made under the specified local - machine name. To omit creation of the - local, writable copy pass - - as local machine - name. - - Similar to the behaviour of - pull-tar, the - read-only image is prefixed with - .raw-, and thus - now shown by - list-images, unless - is - passed. - - Note that pressing C-c during - execution of this command will not - abort the download. Use - cancel-transfer, - described below. - - - - pull-dkr REMOTE [NAME] - - Downloads a - dkr container image - and makes it available locally. The - remote name refers to a - dkr container - name. If omitted, the local machine - name is derived from the - dkr container - name. - - Image verification is not - available for dkr - containers, and thus - must - always be specified with this - command. - - This command downloads all - (missing) layers for the specified - container and places them in read-only - subvolumes in - /var/lib/machines/. A - writable snapshot of the newest layer - is then created under the specified - local machine name. To omit creation - of this writable snapshot, pass - - as local machine - name. - - The read-only layer subvolumes - are prefixed with - .dkr-, and thus - now shown by - list-images, unless - is - passed. - - To specify the - dkr index server to - use for looking up the specified - container, use - . - - Note that pressing C-c during - execution of this command will not - abort the download. Use - cancel-transfer, - described below. - - - - list-transfers - - Shows a list of - container or VM image downloads that - are currently in - progress. - - - - cancel-transfers ID... - - Aborts download of the - container or VM image with the - specified ID. To list ongoing - transfers and their IDs, use - list-transfers. - - - - - - - - - Files and Directories - - Machine images are preferably stored in - /var/lib/machines/, but are also - searched for in - /usr/local/lib/machines/ and - /usr/lib/machines/. For - compatibility reasons the directory - /var/lib/container/ is searched, - too. Note that images stored below - /usr are always considered - read-only. It is possible to symlink machines images - from other directories into - /var/lib/machines/ to make them - available for control with - machinectl. - - Disk images are understood by - systemd-nspawn1 - and machinectl in three - formats: - - - A simple directory tree, - containing the files and directories of the - container to boot. - - A subvolume (on btrfs file - systems), which are similar to the simple - directories, described above. However, they - have additional benefits, such as efficient - cloning and quota reporting. - - "Raw" disk images, i.e. binary - images of disks with a GPT or MBR partition - table. Images of this type are regular - files with the suffix - .raw. - - - See - systemd-nspawn1 - for more information on image formats, in particular - it's and - options. - - - - Examples - - Download an Ubuntu image and open a shell in it - - # machinectl pull-tar https://cloud-images.ubuntu.com/trusty/current/trusty-server-cloudimg-amd64-root.tar.gz + xmlns:xi="http://www.w3.org/2001/XInclude"> + + + machinectl + systemd + + + + Developer + Lennart + Poettering + lennart@poettering.net + + + + + + machinectl + 1 + + + + machinectl + Control the systemd machine manager + + + + + machinectl + OPTIONS + COMMAND + NAME + + + + + Description + + machinectl may be used to introspect and + control the state of the + systemd1 + virtual machine and container registration manager + systemd-machined.service8. + + + + Options + + The following options are understood: + + + + + + + When showing machine or image properties, + limit the output to certain properties as specified by the + argument. If not specified, all set properties are shown. The + argument should be a property name, such as + Name. If specified more than once, all + properties with the specified names are + shown. + + + + + + + When showing machine or image properties, show + all properties regardless of whether they are set or + not. + + When listing VM or container images, do not suppress + images beginning in a dot character + (.). + + + + + + + Do not ellipsize process tree entries. + + + + + + + Do not query the user for authentication for + privileged operations. + + + + + + When used with kill, choose + which processes to kill. Must be one of + , or to select + whether to kill only the leader process of the machine or all + processes of the machine. If omitted, defaults to + . + + + + + + + When used with kill, choose + which signal to send to selected processes. Must be one of the + well-known signal specifiers, such as + SIGTERM, SIGINT or + SIGSTOP. If omitted, defaults to + SIGTERM. + + + + + + When used with bind creates + the destination directory before applying the bind + mount. + + + + + + + When used with bind applies + a read-only bind mount. + + + + + + + + When used with status, + controls the number of journal lines to show, counting from + the most recent ones. Takes a positive integer argument. + Defaults to 10. + + + + + + + + When used with status, + controls the formatting of the journal entries that are shown. + For the available choices, see + journalctl1. + Defaults to short. + + + + + + When downloading a container or VM image, + specify whether the image shall be verified before it is made + available. Takes one of no, + checksum and signature. + If no no verification is done. If + checksum is specified the download is + checked for integrity after transfer is complete, but no + signatures are verified. If signature is + specified, the checksum is verified and the images's signature + is checked against a local keyring of trustable vendors. It is + strongly recommended to set this option to + signature if the server and protocol + support this. Defaults to + signature. + + + + + + When downloading a container or VM image, and + a local copy by the specified local machine name already + exists, delete it first and replace it by the newly downloaded + image. + + + + + + Specifies the index server to use for + downloading dkr images with the + pull-dkr. Takes a + http://, https:// + URL. + + + + + + + + + + + + + + Commands + + The following commands are understood: + + Machine Commands + + + list + + List currently running (online) virtual + machines and containers. To enumerate container images that + can be started, use list-images (see + below). + + + + status NAME... + + Show terse runtime status information about + one or more virtual machines and containers, followed by the + most recent log data from the journal. This function is + intended to generate human-readable output. If you are looking + for computer-parsable output, use show + instead. Note that the log data shown is reported by the + virtual machine or container manager, and frequently contains + console output of the machine, but not necessarily journal + contents of the machine itself. + + + + show NAME... + + Show properties of one or more registered + virtual machines or containers or the manager itself. If no + argument is specified, properties of the manager will be + shown. If an NAME is specified, properties of this virtual + machine or container are shown. By default, empty properties + are suppressed. Use to show those too. + To select specific properties to show, use + . This command is intended to be + used whenever computer-parsable output is required. Use + status if you are looking for formatted + human-readable output. + + + + start NAME... + + Start a container as a system service, using + systemd-nspawn1. + This starts systemd-nspawn@.service, + instantiated for the specified machine name, similar to the + effect of systemctl start on the service + name. systemd-nspawn looks for a container + image by the specified name in + /var/lib/machines/ (and other search + paths, see below) and runs it. Use + list-images (see below), for listing + available container images to start. + + Note that + systemd-machined.service8 + also interfaces with a variety of other container and VM + managers, systemd-nspawn is just one + implementation of it. Most of the commands available in + machinectl may be used on containers or VMs + controlled by other managers, not just + systemd-nspawn. Starting VMs and container + images on those managers requires manager-specific + tools. + + To interactively start a container on the command line + with full access to the container's console, please invoke + systemd-nspawn directly. To stop a running + container use machinectl poweroff, see + below. + + + + login NAME + + Open an interactive terminal login session to + a container. This will create a TTY connection to a specific + container and asks for the execution of a getty on it. Note + that this is only supported for containers running + systemd1 + as init system. + + This command will open a full login prompt on the + container, which then asks for username and password. Use + systemd-run1 + with the switch to invoke a single + command, either interactively or in the background within a + local container. + + + + enable NAME... + disable NAME... + + Enable or disable a container as a system + service to start at system boot, using + systemd-nspawn1. + This enables or disables + systemd-nspawn@.service, instantiated for + the specified machine name, similar to the effect of + systemctl enable or systemctl + disable on the service name. + + + + poweroff NAME... + + Power off one or more containers. This will + trigger a reboot by sending SIGRTMIN+4 to the container's init + process, which causes systemd-compatible init systems to shut + down cleanly. This operation does not work on containers that + do not run a + systemd1-compatible + init system, such as sysvinit. Use + terminate (see below) to immediately + terminate a container or VM, without cleanly shutting it + down. + + + + reboot NAME... + + Reboot one or more containers. This will + trigger a reboot by sending SIGINT to the container's init + process, which is roughly equivalent to pressing Ctrl+Alt+Del + on a non-containerized system, and is compatible with + containers running any system manager. + + + + terminate NAME... + + Immediately terminates a virtual machine or + container, without cleanly shutting it down. This kills all + processes of the virtual machine or container and deallocates + all resources attached to that instance. Use + poweroff to issue a clean shutdown + request. + + + + kill NAME... + + Send a signal to one or more processes of the + virtual machine or container. This means processes as seen by + the host, not the processes inside the virtual machine or + container. Use to select which + process to kill. Use to select the + signal to send. + + + + bind NAME PATH [PATH] + + Bind mounts a directory from the host into the + specified container. The first directory argument is the + source directory on the host, the second directory argument + the source directory on the host. When the latter is omitted + the destination path in the container is the same as the + source path on the host. When combined with the + switch a ready-only bind mount is + created. When combined with the + switch the destination path is first created before the mount + is applied. Note that this option is currently only supported + for + systemd-nspawn1 + containers. + + + + copy-to NAME PATH [PATH] + + Copies files or directories from the host + system into a running container. Takes a container name, + followed by the source path on the host and the destination + path in the container. If the destination path is omitted the + same as the source path is used. + + + + + copy-from NAME PATH [PATH] + + Copies files or directories from a container + into the host system. Takes a container name, followed by the + source path in the container the destination path on the host. + If the destination path is omitted the same as the source path + is used. + + + + Image Commands + + + list-images + + Show a list of locally installed container and + VM images. This enumerates all raw disk images and container + directories and subvolumes in + /var/lib/machines/ (and other search + paths, see below). Use start (see above) to + run a container off one of the listed images. Note that by + default containers whose name begins with a dot + (.) are not shown. To show these too, + specify . Note that a special image + .host always implicitly exists and refers + to the image the host itself is booted from. + + + + image-status NAME... + + Show terse status information about one or + more container or VM images. This function is intended to + generate human-readable output. Use + show-image (see below) to generate + computer-parsable output instead. + + + + show-image NAME... + + Show properties of one or more registered + virtual machine or container images, or the manager itself. If + no argument is specified, properties of the manager will be + shown. If an NAME is specified, properties of this virtual + machine or container image are shown. By default, empty + properties are suppressed. Use to show + those too. To select specific properties to show, use + . This command is intended to be + used whenever computer-parsable output is required. Use + image-status if you are looking for + formatted human-readable output. + + + + clone NAME NAME + + Clones a container or disk image. The + arguments specify the name of the image to clone and the name + of the newly cloned image. Note that plain directory container + images are cloned into subvolume images with this command. + Note that cloning a container or VM image is optimized for + btrfs file systems, and might not be efficient on others, due + to file system limitations. + + + + rename NAME NAME + + Renames a container or disk image. The + arguments specify the name of the image to rename and the new + name of the image. + + + + read-only NAME [BOOL] + + Marks or (unmarks) a container or disk image + read-only. Takes a VM or container image name, followed by a + boolean as arguments. If the boolean is omitted, positive is + implied, i.e. the image is marked read-only. + + + + + remove NAME... + + Removes one or more container or disk images. + The special image .host, which refers to + the host's own directory tree may not be + removed. + + + + + Image Transfer Commands + + + pull-tar URL [NAME] + + Downloads a .tar + container image from the specified URL, and makes it available + under the specified local machine name. The URL must be of + type http:// or + https://, and must refer to a + .tar, .tar.gz, + .tar.xz or .tar.bz2 + archive file. If the local machine name is omitted the name it + is automatically derived from the last component of the URL, + with its suffix removed. + + The image is verified before it is made available, + unless is specified. Verification + is done via SHA256SUMS and SHA256SUMS.gpg files, that need to + be made available on the same web server, under the same URL + as the .tar file, but with the last + component (the filename) of the URL replaced. With + only the SHA256 checksum + for the file is verified, based on the + SHA256SUMS file. With + the SHA256SUMS file is + first verified with detached GPG signature file + SHA256SUMS.gpg. The public key for this + verification step needs to be available in + /usr/lib/systemd/import-pubring.gpg or + /etc/systemd/import-pubring.gpg. + + The container image will be downloaded and stored in a + read-only subvolume in + /var/lib/machines/, that is named after + the specified URL and its HTTP etag. A writable snapshot is + then taken from this subvolume, and named after the specified + local name. This behaviour ensures that creating multiple + container instances of the same URL is efficient, as multiple + downloads are not necessary. In order to create only the + read-only image, and avoid creating its writable snapshot, + specify - as local machine name. + + Note that the read-only subvolume is prefixed with + .tar-, and is thus now shown by + list-images, unless + is passed. + + Note that pressing C-c during execution of this command + will not abort the download. Use + cancel-transfer, described + below. + + + + pull-raw URL [NAME] + + Downloads a .raw + container or VM disk image from the specified URL, and makes + it available under the specified local machine name. The URL + must be of type http:// or + https://. The container image must either + be a .qcow2 or raw disk image, optionally + compressed as .gz, + .xz, or .bz2. If the + local machine name is omitted the name it is automatically + derived from the last component of the URL, with its suffix + removed. + + Image verification is identical for raw and tar images + (see above). + + If the the downloaded image is in + .qcow2 format it es converted into a raw + image file before it is made available. + + Downloaded images of this type will be placed as + read-only .raw file in + /var/lib/machines/. A local, writable + (reflinked) copy is then made under the specified local + machine name. To omit creation of the local, writable copy + pass - as local machine name. + + Similar to the behaviour of pull-tar, + the read-only image is prefixed with + .raw-, and thus now shown by + list-images, unless + is passed. + + Note that pressing C-c during execution of this command + will not abort the download. Use + cancel-transfer, described + below. + + + + pull-dkr REMOTE [NAME] + + Downloads a dkr container + image and makes it available locally. The remote name refers + to a dkr container name. If omitted, the + local machine name is derived from the dkr + container name. + + Image verification is not available for + dkr containers, and thus + must always be specified with + this command. + + This command downloads all (missing) layers for the + specified container and places them in read-only subvolumes in + /var/lib/machines/. A writable snapshot + of the newest layer is then created under the specified local + machine name. To omit creation of this writable snapshot, pass + - as local machine name. + + The read-only layer subvolumes are prefixed with + .dkr-, and thus now shown by + list-images, unless + is passed. + + To specify the dkr index server to + use for looking up the specified container, use + . + + Note that pressing C-c during execution of this command + will not abort the download. Use + cancel-transfer, described + below. + + + + list-transfers + + Shows a list of container or VM image + downloads that are currently in progress. + + + + cancel-transfers ID... + + Aborts download of the container or VM image + with the specified ID. To list ongoing transfers and their + IDs, use list-transfers. + + + + + + + + Files and Directories + + Machine images are preferably stored in + /var/lib/machines/, but are also searched for + in /usr/local/lib/machines/ and + /usr/lib/machines/. For compatibility reasons + the directory /var/lib/container/ is + searched, too. Note that images stored below + /usr are always considered read-only. It is + possible to symlink machines images from other directories into + /var/lib/machines/ to make them available for + control with machinectl. + + Disk images are understood by + systemd-nspawn1 + and machinectl in three formats: + + + A simple directory tree, containing the files + and directories of the container to boot. + + A subvolume (on btrfs file systems), which are + similar to the simple directories, described above. However, + they have additional benefits, such as efficient cloning and + quota reporting. + + "Raw" disk images, i.e. binary images of disks + with a GPT or MBR partition table. Images of this type are + regular files with the suffix + .raw. + + + See + systemd-nspawn1 + for more information on image formats, in particular it's + and + options. + + + + Examples + + Download an Ubuntu image and open a shell in it + + # machinectl pull-tar https://cloud-images.ubuntu.com/trusty/current/trusty-server-cloudimg-amd64-root.tar.gz # systemd-nspawn -M trusty-server-cloudimg-amd64-root - This downloads and verifies the - specified .tar image, and - then uses - systemd-nspawn1 - to open a shell in it. - - - - Download a Fedora image, set a root password in it, start it as service - - # machinectl pull-raw --verify=no http://ftp.halifax.rwth-aachen.de/fedora/linux/releases/21/Cloud/Images/x86_64/Fedora-Cloud-Base-20141203-21.x86_64.raw.xz -# systemd-nspawn -M Fedora-Cloud-Base-20141203-21 -# passwd -# exit -# machinectl start Fedora-Cloud-Base-20141203-21 -# machinectl login Fedora-Cloud-Base-20141203-21 - - This downloads the specified - .raw image with - verification disabled. Then a shell is opened - in it and a root password is set. Afterwards - the shell is left, and the machine started as - system service. With the last command a login - prompt into the container is requested. - - - - Download a Fedora <literal>dkr</literal> image - - # machinectl pull-dkr --verify=no mattdm/fedora + This downloads and verifies the specified + .tar image, and then uses + systemd-nspawn1 + to open a shell in it. + + + + Download a Fedora image, set a root password in it, start + it as service + + # machinectl pull-raw --verify=no + http://ftp.halifax.rwth-aachen.de/fedora/linux/releases/21/Cloud/Images/x86_64/Fedora-Cloud-Base-20141203-21.x86_64.raw.xz + # systemd-nspawn -M Fedora-Cloud-Base-20141203-21 # passwd # + exit # machinectl start Fedora-Cloud-Base-20141203-21 # + machinectl login Fedora-Cloud-Base-20141203-21 + + This downloads the specified .raw + image with verification disabled. Then a shell is opened in it + and a root password is set. Afterwards the shell is left, and + the machine started as system service. With the last command a + login prompt into the container is requested. + + + + Download a Fedora <literal>dkr</literal> image + + # machinectl pull-dkr --verify=no mattdm/fedora # systemd-nspawn -M fedora - Downloads a dkr image - and opens a shell in it. Note that the - specified download command might require an - index server to be specified with the - --dkr-index-url=. - - - - - Exit status - - On success, 0 is returned, a non-zero failure - code otherwise. - - - - - - See Also - - systemd-machined.service8, - systemd-nspawn1, - systemd.special7 - - + Downloads a dkr image and opens a shell + in it. Note that the specified download command might require an + index server to be specified with the + --dkr-index-url=. + + + + + Exit status + + On success, 0 is returned, a non-zero failure code + otherwise. + + + + + + See Also + + systemd-machined.service8, + systemd-nspawn1, + systemd.special7 + + diff --git a/man/modules-load.d.xml b/man/modules-load.d.xml index 4b578d714ce..34a937db68b 100644 --- a/man/modules-load.d.xml +++ b/man/modules-load.d.xml @@ -20,83 +20,82 @@ along with systemd; If not, see . --> - - - modules-load.d - systemd - - - - Developer - Lennart - Poettering - lennart@poettering.net - - - - - - modules-load.d - 5 - - - - modules-load.d - Configure kernel modules to load at boot - - - - /etc/modules-load.d/*.conf - /run/modules-load.d/*.conf - /usr/lib/modules-load.d/*.conf - - - - Description - - systemd-modules-load.service8 - reads files from the above directories which contain - kernel modules to load during boot in a static list. - Each configuration file is named in the style of - /etc/modules-load.d/program.conf. Note - that it is usually a better idea to rely on the - automatic module loading by PCI IDs, USB IDs, DMI IDs - or similar triggers encoded in the kernel modules - themselves instead of static configuration like - this. In fact, most modern kernel modules are prepared - for automatic loading already. - - - - Configuration Format - - The configuration files should simply contain a - list of kernel module names to load, separated by - newlines. Empty lines and lines whose first - non-whitespace character is # or ; are ignored. - - - - - - Example - - /etc/modules-load.d/virtio-net.conf example: - - # Load virtio-net.ko at boot + xmlns:xi="http://www.w3.org/2001/XInclude"> + + + modules-load.d + systemd + + + + Developer + Lennart + Poettering + lennart@poettering.net + + + + + + modules-load.d + 5 + + + + modules-load.d + Configure kernel modules to load at boot + + + + /etc/modules-load.d/*.conf + /run/modules-load.d/*.conf + /usr/lib/modules-load.d/*.conf + + + + Description + + systemd-modules-load.service8 + reads files from the above directories which contain kernel + modules to load during boot in a static list. Each configuration + file is named in the style of + /etc/modules-load.d/program.conf. + Note that it is usually a better idea to rely on the automatic + module loading by PCI IDs, USB IDs, DMI IDs or similar triggers + encoded in the kernel modules themselves instead of static + configuration like this. In fact, most modern kernel modules are + prepared for automatic loading already. + + + + Configuration Format + + The configuration files should simply contain a list of + kernel module names to load, separated by newlines. Empty lines + and lines whose first non-whitespace character is # or ; are + ignored. + + + + + + Example + + /etc/modules-load.d/virtio-net.conf example: + + # Load virtio-net.ko at boot virtio-net - - - - - See Also - - systemd1, - systemd-modules-load.service8, - systemd-delta1, - modprobe8 - - + + + + + See Also + + systemd1, + systemd-modules-load.service8, + systemd-delta1, + modprobe8 + + diff --git a/man/nss-myhostname.xml b/man/nss-myhostname.xml index c7a2cd9ae7b..cf2b0200f2e 100644 --- a/man/nss-myhostname.xml +++ b/man/nss-myhostname.xml @@ -1,6 +1,6 @@ + "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd"> + "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd"> + "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd"> - - os-release - systemd - - - - Developer - Lennart - Poettering - lennart@poettering.net - - - - - - os-release - 5 - - - - os-release - Operating system identification - - - - /etc/os-release - /usr/lib/os-release - - - - Description - - The /etc/os-release and - /usr/lib/os-release files contain - operating system identification data. - - The basic file format of - os-release is a newline-separated - list of environment-like shell-compatible variable - assignments. It is possible to source the - configuration from shell scripts, however, beyond mere - variable assignments, no shell features are supported - (this means variable expansion is explicitly not - supported), allowing applications to read the file - without implementing a shell compatible execution - engine. Variable assignment values must be enclosed in - double or single quotes if they include spaces, - semicolons or other special characters outside of A-Z, - a-z, 0-9. Shell special characters ("$", quotes, - backslash, backtick) must be escaped with backslashes, - following shell style. All strings should be in UTF-8 - format, and non-printable characters should not be used. - It is not supported to concatenate multiple individually - quoted strings. Lines beginning with "#" shall be - ignored as comments. - - The file /etc/os-release - takes precedence over - /usr/lib/os-release. Applications - should check for the former, and exclusively use its - data if it exists, and only fall back to - /usr/lib/os-release if it is - missing. Applications should not read data from both - files at the same - time. /usr/lib/os-release is the - recommended place to store OS release information as - part of vendor trees. - /etc/os-release should be a - relative symlink to - /usr/lib/os-release, - to provide compatibility with applications only - looking at /etc. A relative - symlink instead of an absolute symlink is - necessary to avoid breaking the link in a chroot or - initrd environment such as dracut. - - os-release contains data - that is defined by the operating system vendor and - should generally not be changed by the - administrator. - - As this file only encodes names and identifiers - it should not be localized. - - The /etc/os-release and - /usr/lib/os-release files might - be symlinks to other files, but it is important that - the file is available from earliest boot on, and hence - must be located on the root file system. - - For a longer rationale for - os-release please refer to - the Announcement of /etc/os-release. - - - - Options - - The following OS identifications parameters may be set using - os-release: - - - - - NAME= - - A string identifying - the operating system, without a - version component, and suitable for - presentation to the user. If not set, - defaults to - NAME=Linux. Example: - NAME=Fedora or - NAME="Debian - GNU/Linux". - - - - VERSION= - - A string identifying - the operating system version, - excluding any OS name information, - possibly including a release code - name, and suitable for presentation to - the user. This field is - optional. Example: - VERSION=17 or - VERSION="17 (Beefy - Miracle)". - - - - ID= - - A lower-case string - (no spaces or other characters outside - of 0-9, a-z, ".", "_" and "-") - identifying the operating system, - excluding any version information and - suitable for processing by scripts or - usage in generated filenames. If not - set, defaults to - ID=linux. Example: - ID=fedora or - ID=debian. - - - - ID_LIKE= - - A space-separated list - of operating system identifiers in the - same syntax as the - ID= setting. It should - list identifiers of operating systems - that are closely related to the local - operating system in regards to - packaging and programming interfaces, - for example listing one or more - OS identifiers the local - OS is a derivative from. An - OS should generally only list other OS - identifiers it itself is a derivative - of, and not any OSes that - are derived from it, though symmetric - relationships are possible. Build - scripts and similar should check this - variable if they need to identify the - local operating system and the value - of ID= is not - recognized. Operating systems should - be listed in order of how closely the - local operating system relates to the - listed ones, starting with the - closest. This field is - optional. Example: for an operating - system with - ID=centos, an - assignment of ID_LIKE="rhel - fedora" would be - appropriate. For an operating system - with ID=ubuntu, an - assignment of - ID_LIKE=debian is - appropriate. - - - - VERSION_ID= - - A lower-case string - (mostly numeric, no spaces or other - characters outside of 0-9, a-z, ".", - "_" and "-") identifying the operating - system version, excluding any OS name - information or release code name, and - suitable for processing by scripts or - usage in generated filenames. This - field is optional. Example: - VERSION_ID=17 or - VERSION_ID=11.04. - - - - PRETTY_NAME= - - A pretty operating - system name in a format suitable for - presentation to the user. May or may - not contain a release code name or OS - version of some kind, as suitable. If - not set, defaults to - PRETTY_NAME="Linux". Example: - PRETTY_NAME="Fedora 17 (Beefy - Miracle)". - - - - ANSI_COLOR= - - A suggested - presentation color when showing the - OS name on the console. This - should be specified as string suitable - for inclusion in the ESC [ m - ANSI/ECMA-48 escape code for setting - graphical rendition. This field is - optional. Example: - ANSI_COLOR="0;31" - for red, or - ANSI_COLOR="1;34" - for light blue. - - - - CPE_NAME= - - A CPE name for the - operating system, following the Common - Platform Enumeration - Specification as proposed by - the MITRE Corporation. This field - is optional. Example: - CPE_NAME="cpe:/o:fedoraproject:fedora:17" - - - - - HOME_URL= - SUPPORT_URL= - BUG_REPORT_URL= - PRIVACY_POLICY_URL= - - Links to resources on - the Internet related the operating - system. HOME_URL= - should refer to the homepage of the - operating system, or alternatively - some homepage of the specific version - of the operating - system. SUPPORT_URL= - should refer to the main support page - for the operating system, if there is - any. This is primarily intended for - operating systems which vendors - provide support - for. BUG_REPORT_URL= - should refer to the main bug reporting - page for the operating system, if - there is any. This is primarily - intended for operating systems that - rely on community QA. - PRIVACY_POLICY_URL= - should refer to the main privacy policy - page for the operation system, if there - is any. These settings - are optional, and providing only some - of these settings is common. These - URLs are intended to be exposed in - "About this system" UIs behind links - with captions such as "About this - Operating System", "Obtain Support", - "Report a Bug", or "Privacy Policy". The - values should be in RFC3986 - format, and should be - http: or - https: URLs, and - possibly mailto: or - tel:. Only one URL - shall be listed in each setting. If - multiple resources need to be - referenced, it is recommended to - provide an online landing page linking - all available resources. Examples: - HOME_URL="https://fedoraproject.org/" - and - BUG_REPORT_URL="https://bugzilla.redhat.com/" - - - - BUILD_ID= - - A string uniquely - identifying the system image used as - the origin for a distribution (it is - not updated with system updates). The - field can be identical between - different VERSION_IDs as BUILD_ID is - an only a unique identifier to a - specific version. Distributions that - release each update as a new version - would only need to use VERSION_ID as - each build is already distinct based - on the VERSION_ID. This field is - optional. Example: - BUILD_ID="2013-03-20.3" - or - BUILD_ID=201303203. - - - - - - - If you are reading this file from C code or a - shell script to determine the OS or a specific version - of it, use the ID and VERSION_ID fields, possibly with - ID_LIKE as fallback for ID. When looking for an OS - identification string for presentation to the user use - the PRETTY_NAME field. - - Note that operating system vendors may choose - not to provide version information, for example to - accommodate for rolling releases. In this case, VERSION - and VERSION_ID may be unset. Applications should not - rely on these fields to be set. - - Operating system vendors may extend the file - format and introduce new fields. It is highly - recommended to prefix new fields with an OS specific - name in order to avoid name clashes. Applications - reading this file must ignore unknown fields. Example: - DEBIAN_BTS="debbugs://bugs.debian.org/" - - - - Example - - NAME=Fedora + + os-release + systemd + + + + Developer + Lennart + Poettering + lennart@poettering.net + + + + + + os-release + 5 + + + + os-release + Operating system identification + + + + /etc/os-release + /usr/lib/os-release + + + + Description + + The /etc/os-release and + /usr/lib/os-release files contain operating + system identification data. + + The basic file format of os-release is + a newline-separated list of environment-like shell-compatible + variable assignments. It is possible to source the configuration + from shell scripts, however, beyond mere variable assignments, no + shell features are supported (this means variable expansion is + explicitly not supported), allowing applications to read the file + without implementing a shell compatible execution engine. Variable + assignment values must be enclosed in double or single quotes if + they include spaces, semicolons or other special characters + outside of A-Z, a-z, 0-9. Shell special characters ("$", quotes, + backslash, backtick) must be escaped with backslashes, following + shell style. All strings should be in UTF-8 format, and + non-printable characters should not be used. It is not supported + to concatenate multiple individually quoted strings. Lines + beginning with "#" shall be ignored as comments. + + The file /etc/os-release takes + precedence over /usr/lib/os-release. + Applications should check for the former, and exclusively use its + data if it exists, and only fall back to + /usr/lib/os-release if it is missing. + Applications should not read data from both files at the same + time. /usr/lib/os-release is the recommended + place to store OS release information as part of vendor trees. + /etc/os-release should be a relative symlink + to /usr/lib/os-release, to provide + compatibility with applications only looking at + /etc. A relative symlink instead of an + absolute symlink is necessary to avoid breaking the link in a + chroot or initrd environment such as dracut. + + os-release contains data that is + defined by the operating system vendor and should generally not be + changed by the administrator. + + As this file only encodes names and identifiers it should + not be localized. + + The /etc/os-release and + /usr/lib/os-release files might be symlinks + to other files, but it is important that the file is available + from earliest boot on, and hence must be located on the root file + system. + + For a longer rationale for os-release + please refer to the Announcement of + /etc/os-release. + + + + Options + + The following OS identifications parameters may be set using + os-release: + + + + + NAME= + + A string identifying the operating system, + without a version component, and suitable for presentation to + the user. If not set, defaults to + NAME=Linux. Example: + NAME=Fedora or NAME="Debian + GNU/Linux". + + + + VERSION= + + A string identifying the operating system + version, excluding any OS name information, possibly including + a release code name, and suitable for presentation to the + user. This field is optional. Example: + VERSION=17 or VERSION="17 (Beefy + Miracle)". + + + + ID= + + A lower-case string (no spaces or other + characters outside of 0-9, a-z, ".", "_" and "-") identifying + the operating system, excluding any version information and + suitable for processing by scripts or usage in generated + filenames. If not set, defaults to + ID=linux. Example: + ID=fedora or + ID=debian. + + + + ID_LIKE= + + A space-separated list of operating system + identifiers in the same syntax as the ID= + setting. It should list identifiers of operating systems that + are closely related to the local operating system in regards + to packaging and programming interfaces, for example listing + one or more OS identifiers the local OS is a derivative from. + An OS should generally only list other OS identifiers it + itself is a derivative of, and not any OSes that are derived + from it, though symmetric relationships are possible. Build + scripts and similar should check this variable if they need to + identify the local operating system and the value of + ID= is not recognized. Operating systems + should be listed in order of how closely the local operating + system relates to the listed ones, starting with the closest. + This field is optional. Example: for an operating system with + ID=centos, an assignment of + ID_LIKE="rhel fedora" would be appropriate. + For an operating system with ID=ubuntu, an + assignment of ID_LIKE=debian is + appropriate. + + + + VERSION_ID= + + A lower-case string (mostly numeric, no spaces + or other characters outside of 0-9, a-z, ".", "_" and "-") + identifying the operating system version, excluding any OS + name information or release code name, and suitable for + processing by scripts or usage in generated filenames. This + field is optional. Example: VERSION_ID=17 + or VERSION_ID=11.04. + + + + PRETTY_NAME= + + A pretty operating system name in a format + suitable for presentation to the user. May or may not contain + a release code name or OS version of some kind, as suitable. + If not set, defaults to + PRETTY_NAME="Linux". Example: + PRETTY_NAME="Fedora 17 (Beefy + Miracle)". + + + + ANSI_COLOR= + + A suggested presentation color when showing + the OS name on the console. This should be specified as string + suitable for inclusion in the ESC [ m ANSI/ECMA-48 escape code + for setting graphical rendition. This field is optional. + Example: ANSI_COLOR="0;31" for red, or + ANSI_COLOR="1;34" for light + blue. + + + + CPE_NAME= + + A CPE name for the operating system, following + the Common + Platform Enumeration Specification as proposed by the + MITRE Corporation. This field is optional. Example: + CPE_NAME="cpe:/o:fedoraproject:fedora:17" + + + + + HOME_URL= + SUPPORT_URL= + BUG_REPORT_URL= + PRIVACY_POLICY_URL= + + Links to resources on the Internet related the + operating system. HOME_URL= should refer to + the homepage of the operating system, or alternatively some + homepage of the specific version of the operating system. + SUPPORT_URL= should refer to the main + support page for the operating system, if there is any. This + is primarily intended for operating systems which vendors + provide support for. BUG_REPORT_URL= should + refer to the main bug reporting page for the operating system, + if there is any. This is primarily intended for operating + systems that rely on community QA. + PRIVACY_POLICY_URL= should refer to the + main privacy policy page for the operation system, if there is + any. These settings are optional, and providing only some of + these settings is common. These URLs are intended to be + exposed in "About this system" UIs behind links with captions + such as "About this Operating System", "Obtain Support", + "Report a Bug", or "Privacy Policy". The values should be in + RFC3986 + format, and should be http: or + https: URLs, and possibly + mailto: or tel:. Only + one URL shall be listed in each setting. If multiple resources + need to be referenced, it is recommended to provide an online + landing page linking all available resources. Examples: + HOME_URL="https://fedoraproject.org/" and + BUG_REPORT_URL="https://bugzilla.redhat.com/" + + + + BUILD_ID= + + A string uniquely identifying the system image + used as the origin for a distribution (it is not updated with + system updates). The field can be identical between different + VERSION_IDs as BUILD_ID is an only a unique identifier to a + specific version. Distributions that release each update as a + new version would only need to use VERSION_ID as each build is + already distinct based on the VERSION_ID. This field is + optional. Example: BUILD_ID="2013-03-20.3" + or BUILD_ID=201303203. + + + + + + + If you are reading this file from C code or a shell script + to determine the OS or a specific version of it, use the + ID and VERSION_ID fields, + possibly with ID_LIKE as fallback for + ID. When looking for an OS identification + string for presentation to the user use the + PRETTY_NAME field. + + Note that operating system vendors may choose not to provide + version information, for example to accommodate for rolling + releases. In this case, VERSION and + VERSION_ID may be unset. Applications should + not rely on these fields to be set. + + Operating system vendors may extend the file + format and introduce new fields. It is highly + recommended to prefix new fields with an OS specific + name in order to avoid name clashes. Applications + reading this file must ignore unknown fields. Example: + DEBIAN_BTS="debbugs://bugs.debian.org/" + + + + Example + + NAME=Fedora VERSION="17 (Beefy Miracle)" ID=fedora VERSION_ID=17 @@ -384,17 +311,17 @@ ANSI_COLOR="0;34" CPE_NAME="cpe:/o:fedoraproject:fedora:17" HOME_URL="https://fedoraproject.org/" BUG_REPORT_URL="https://bugzilla.redhat.com/" - - - - See Also - - systemd1, - lsb_release1, - hostname5, - machine-id5, - machine-info5 - - + + + + See Also + + systemd1, + lsb_release1, + hostname5, + machine-id5, + machine-info5 + + diff --git a/man/pam_systemd.xml b/man/pam_systemd.xml index 3e106ea69b8..b4a3f502b44 100644 --- a/man/pam_systemd.xml +++ b/man/pam_systemd.xml @@ -1,6 +1,6 @@ + "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd"> + "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd"> - - resolved.conf - systemd - - - - Developer - Tom - Gundersen - teg@jklm.no - - - - - - resolved.conf - 5 - - - - resolved.conf - resolved.conf.d - Network Name Resolution configuration files - - - - /etc/systemd/resolved.conf - /etc/systemd/resolved.conf.d/*.conf - /run/systemd/resolved.conf.d/*.conf - /usr/lib/systemd/resolved.conf.d/*.conf - - - - Description - - These configuration files control local DNS and LLMNR - name resolving. - - - - - - - - Options - - - - - DNS= - A space separated list - of IPv4 and IPv6 addresses to be used - as system DNS servers. DNS requests - are sent to one of the listed DNS - servers in parallel to any - per-interface DNS servers acquired - from - systemd-networkd.service8. For - compatibility reasons, if set to the - empty list the DNS servers listed in - /etc/resolv.conf - are used, if any are - configured there. This setting - defaults to the empty - list. - - - - FallbackDNS= - A space separated list - of IPv4 and IPv6 addresses to be used - as the fallback DNS servers. Any - per-interface DNS servers obtained - from - systemd-networkd.service8 - take precedence over this setting, as - do any servers set via - DNS= above or - /etc/resolv.conf. This - setting is hence only used if no other - DNS server information is known. If - this option is not given, a - compiled-in list of DNS servers is - used instead. - - - - LLMNR= - Takes a boolean - argument or - resolve. Controls - Link-Local Multicast Name Resolution support (RFC - 4794) on the local host. If - true enables full LLMNR responder and - resolver support. If false disable - both. If set to - resolve only - resolving support is enabled, but - responding is disabled. Note that - systemd-networkd.service8 - also maintains per-interface LLMNR - settings. LLMNR will be enabled on an - interface only if the per-interface - and the global setting is - on. - - - - - - - See Also - - systemd1, - systemd-resolved.service8, - systemd-networkd.service8, - resolv.conf4 - - + xmlns:xi="http://www.w3.org/2001/XInclude"> + + resolved.conf + systemd + + + + Developer + Tom + Gundersen + teg@jklm.no + + + + + + resolved.conf + 5 + + + + resolved.conf + resolved.conf.d + Network Name Resolution configuration files + + + + /etc/systemd/resolved.conf + /etc/systemd/resolved.conf.d/*.conf + /run/systemd/resolved.conf.d/*.conf + /usr/lib/systemd/resolved.conf.d/*.conf + + + + Description + + These configuration files control local DNS and LLMNR + name resolving. + + + + + + + + Options + + + + + DNS= + A space separated list of IPv4 and IPv6 + addresses to be used as system DNS servers. DNS requests are + sent to one of the listed DNS servers in parallel to any + per-interface DNS servers acquired from + systemd-networkd.service8. + For compatibility reasons, if set to the empty list the DNS + servers listed in /etc/resolv.conf are + used, if any are configured there. This setting defaults to + the empty list. + + + + FallbackDNS= + A space separated list of IPv4 and IPv6 + addresses to be used as the fallback DNS servers. Any + per-interface DNS servers obtained from + systemd-networkd.service8 + take precedence over this setting, as do any servers set via + DNS= above or + /etc/resolv.conf. This setting is hence + only used if no other DNS server information is known. If this + option is not given, a compiled-in list of DNS servers is used + instead. + + + + LLMNR= + Takes a boolean argument or + resolve. Controls Link-Local Multicast Name + Resolution support (RFC 4794) on + the local host. If true enables full LLMNR responder and + resolver support. If false disable both. If set to + resolve only resolving support is enabled, + but responding is disabled. Note that + systemd-networkd.service8 + also maintains per-interface LLMNR settings. LLMNR will be + enabled on an interface only if the per-interface and the + global setting is on. + + + + + + + See Also + + systemd1, + systemd-resolved.service8, + systemd-networkd.service8, + resolv.conf4 + + diff --git a/man/runlevel.xml b/man/runlevel.xml index db9a4367248..fc1f5238551 100644 --- a/man/runlevel.xml +++ b/man/runlevel.xml @@ -1,6 +1,6 @@ + "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd"> - - - runlevel - systemd - - - - Developer - Lennart - Poettering - lennart@poettering.net - - - - - - runlevel - 8 - - - - runlevel - Print previous and current SysV runlevel - - - - - runlevel options - - - - - Description - - runlevel prints the previous - and current SysV runlevel if they are known. - - The two runlevel characters are separated by a - single space character. If a runlevel cannot be - determined, N is printed instead. If neither can be - determined, the word "unknown" is printed. - - Unless overridden in the environment, this will - check the utmp database for recent runlevel - changes. - - - - Options - - The following option is understood: - - - - - - - - - - - - - Exit status - - If one or both runlevels could be determined, 0 - is returned, a non-zero failure code otherwise. - - - - - Environment - - - - $RUNLEVEL - - If - $RUNLEVEL is set, - runlevel will print - this value as current runlevel and - ignore utmp. - - - - $PREVLEVEL - - If - $PREVLEVEL is set, - runlevel will print - this value as previous runlevel and - ignore utmp. - - - - - - Files - - - - /var/run/utmp - - The utmp database - runlevel reads the - previous and current runlevel - from. - - - - - - - Notes - - This is a legacy command available for compatibility - only. It should not be used anymore, as the concept of - runlevels is obsolete. - - - - See Also - - systemd1, - systemctl1 - - + xmlns:xi="http://www.w3.org/2001/XInclude" + conditional="HAVE_UTMP"> + + + runlevel + systemd + + + + Developer + Lennart + Poettering + lennart@poettering.net + + + + + + runlevel + 8 + + + + runlevel + Print previous and current SysV runlevel + + + + + runlevel options + + + + + Description + + runlevel prints the previous and current + SysV runlevel if they are known. + + The two runlevel characters are separated by a single space + character. If a runlevel cannot be determined, N is printed + instead. If neither can be determined, the word "unknown" is + printed. + + Unless overridden in the environment, this will check the + utmp database for recent runlevel changes. + + + + Options + + The following option is understood: + + + + + + + + + + + + + Exit status + + If one or both runlevels could be determined, 0 is returned, + a non-zero failure code otherwise. + + + + + Environment + + + + $RUNLEVEL + + If $RUNLEVEL is set, + runlevel will print this value as current + runlevel and ignore utmp. + + + + $PREVLEVEL + + If $PREVLEVEL is set, + runlevel will print this value as previous + runlevel and ignore utmp. + + + + + + Files + + + + /var/run/utmp + + The utmp database runlevel + reads the previous and current runlevel + from. + + + + + + Notes + + This is a legacy command available for compatibility only. + It should not be used anymore, as the concept of runlevels is + obsolete. + + + + See Also + + systemd1, + systemctl1 + + diff --git a/man/sd-daemon.xml b/man/sd-daemon.xml index 5f331e740a1..b7ba3636566 100644 --- a/man/sd-daemon.xml +++ b/man/sd-daemon.xml @@ -1,6 +1,6 @@ + "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd"> - - - sd-daemon - systemd - - - - Developer - Lennart - Poettering - lennart@poettering.net - - - - - - sd-daemon - 3 - - - - sd-daemon - SD_EMERG - SD_ALERT - SD_CRIT - SD_ERR - SD_WARNING - SD_NOTICE - SD_INFO - SD_DEBUG - APIs for - new-style daemons - - - - - #include <systemd/sd-daemon.h> - - - - pkg-config --cflags --libs libsystemd - - - - - - Description - - sd-daemon.h provide APIs - for new-style daemons, as implemented by the - systemd1 - init system. - - See - sd_listen_fds3, - sd_notify3, - sd_booted3, - sd_is_fifo3, - sd_watchdog_enabled3 - for more information about the functions - implemented. In addition to these functions, a couple - of logging prefixes are defined as macros: - - #define SD_EMERG "<0>" /* system is unusable */ + xmlns:xi="http://www.w3.org/2001/XInclude"> + + + sd-daemon + systemd + + + + Developer + Lennart + Poettering + lennart@poettering.net + + + + + + sd-daemon + 3 + + + + sd-daemon + SD_EMERG + SD_ALERT + SD_CRIT + SD_ERR + SD_WARNING + SD_NOTICE + SD_INFO + SD_DEBUG + APIs for + new-style daemons + + + + + #include <systemd/sd-daemon.h> + + + + pkg-config --cflags --libs libsystemd + + + + + + Description + + sd-daemon.h provide APIs for new-style + daemons, as implemented by the + systemd1 + init system. + + See + sd_listen_fds3, + sd_notify3, + sd_booted3, + sd_is_fifo3, + sd_watchdog_enabled3 + for more information about the functions implemented. In addition + to these functions, a couple of logging prefixes are defined as + macros: + + #define SD_EMERG "<0>" /* system is unusable */ #define SD_ALERT "<1>" /* action must be taken immediately */ #define SD_CRIT "<2>" /* critical conditions */ #define SD_ERR "<3>" /* error conditions */ @@ -95,53 +95,50 @@ #define SD_INFO "<6>" /* informational */ #define SD_DEBUG "<7>" /* debug-level messages */ - These prefixes are intended to be used in - conjunction with stderr-based logging as implemented - by systemd. If a systemd service definition file is - configured with - StandardError=journal, - StandardError=syslog or - StandardError=kmsg, these prefixes - can be used to encode a log level in lines - printed. This is similar to the kernel - printk()-style logging. See - klogctl2 - for more information. - - The log levels are identical to - syslog3's - log level system. To use these prefixes simply prefix - every line with one of these strings. A line that is - not prefixed will be logged at the default log level - SD_INFO. - - - Hello World - - A daemon may log with the log level - NOTICE by issuing this call: - - fprintf(stderr, SD_NOTICE "Hello World!\n"); - - - - - - - See Also - - systemd1, - sd_listen_fds3, - sd_notify3, - sd_booted3, - sd_is_fifo3, - sd_watchdog_enabled3, - daemon7, - systemd.service5, - systemd.socket5, - fprintf3, - pkg-config1 - - + These prefixes are intended to be used in conjunction with + stderr-based logging as implemented by systemd. If a systemd + service definition file is configured with + StandardError=journal, + StandardError=syslog or + StandardError=kmsg, these prefixes can be used + to encode a log level in lines printed. This is similar to the + kernel printk()-style logging. See + klogctl2 + for more information. + + The log levels are identical to + syslog3's + log level system. To use these prefixes simply prefix every line + with one of these strings. A line that is not prefixed will be + logged at the default log level SD_INFO. + + + Hello World + + A daemon may log with the log level NOTICE by issuing this + call: + + fprintf(stderr, SD_NOTICE "Hello World!\n"); + + + + + + + See Also + + systemd1, + sd_listen_fds3, + sd_notify3, + sd_booted3, + sd_is_fifo3, + sd_watchdog_enabled3, + daemon7, + systemd.service5, + systemd.socket5, + fprintf3, + pkg-config1 + + diff --git a/man/sd-id128.xml b/man/sd-id128.xml index d9ebb9c6801..ea7972055d0 100644 --- a/man/sd-id128.xml +++ b/man/sd-id128.xml @@ -1,6 +1,6 @@ + "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd"> - - - sd-id128 - systemd - - - - Developer - Lennart - Poettering - lennart@poettering.net - - - - - - sd-id128 - 3 - - - - sd-id128 - sd_id128_t - SD_ID128_MAKE - SD_ID128_CONST_STR - SD_ID128_FORMAT_STR - SD_ID128_FORMAT_VAL - sd_id128_equal - APIs for processing 128-bit IDs - - - - - #include <systemd/sd-id128.h> - - - - pkg-config --cflags --libs libsystemd - - - - - - Description - - sd-id128.h provides APIs to - process and generate 128-bit ID values. The 128-bit ID - values processed and generated by these APIs are a - generalization of OSF UUIDs as defined by RFC - 4122 but use a simpler string - format. These functions impose no structure on the - used IDs, much unlike OSF UUIDs or Microsoft GUIDs, - but are fully compatible with those types of IDs. - - - See - sd_id128_to_string3, - sd_id128_randomize3 and - sd_id128_get_machine3 - for more information about the implemented - functions. - - A 128-bit ID is implemented as the following - union type: - - typedef union sd_id128 { - uint8_t bytes[16]; - uint64_t qwords[2]; + xmlns:xi="http://www.w3.org/2001/XInclude"> + + + sd-id128 + systemd + + + + Developer + Lennart + Poettering + lennart@poettering.net + + + + + + sd-id128 + 3 + + + + sd-id128 + sd_id128_t + SD_ID128_MAKE + SD_ID128_CONST_STR + SD_ID128_FORMAT_STR + SD_ID128_FORMAT_VAL + sd_id128_equal + APIs for processing 128-bit IDs + + + + + #include <systemd/sd-id128.h> + + + + pkg-config --cflags --libs libsystemd + + + + + + Description + + sd-id128.h provides APIs to process and + generate 128-bit ID values. The 128-bit ID values processed and + generated by these APIs are a generalization of OSF UUIDs as + defined by RFC + 4122 but use a simpler string format. These functions + impose no structure on the used IDs, much unlike OSF UUIDs or + Microsoft GUIDs, but are fully compatible with those types of IDs. + + + See + sd_id128_to_string3, + sd_id128_randomize3 + and + sd_id128_get_machine3 + for more information about the implemented functions. + + A 128-bit ID is implemented as the following + union type: + + typedef union sd_id128 { + uint8_t bytes[16]; + uint64_t qwords[2]; } sd_id128_t; - This union type allows accessing the 128-bit ID - as 16 separate bytes or two 64-bit words. It is generally - safer to access the ID components by their 8-bit array - to avoid endianness issues. This union is intended to - be passed call-by-value (as opposed to - call-by-reference) and may be directly manipulated by - clients. - - A couple of macros are defined to denote and - decode 128-bit IDs: - - SD_ID128_MAKE() may be used - to denote a constant 128-bit ID in source code. A - commonly used idiom is to assign a name to a 128-bit - ID using this macro: - - #define SD_MESSAGE_COREDUMP SD_ID128_MAKE(fc,2e,22,bc,6e,e6,47,b6,b9,07,29,ab,34,a2,50,b1) - - SD_ID128_CONST_STR() may be - used to convert constant 128-bit IDs into constant - strings for output. The following example code will - output the string - "fc2e22bc6ee647b6b90729ab34a250b1": - int main(int argc, char *argv[]) { - puts(SD_ID128_CONST_STR(SD_MESSAGE_COREDUMP)); + This union type allows accessing the 128-bit ID as 16 + separate bytes or two 64-bit words. It is generally safer to + access the ID components by their 8-bit array to avoid endianness + issues. This union is intended to be passed call-by-value (as + opposed to call-by-reference) and may be directly manipulated by + clients. + + A couple of macros are defined to denote and decode 128-bit + IDs: + + SD_ID128_MAKE() may be used to denote a + constant 128-bit ID in source code. A commonly used idiom is to + assign a name to a 128-bit ID using this macro: + + #define SD_MESSAGE_COREDUMP SD_ID128_MAKE(fc,2e,22,bc,6e,e6,47,b6,b9,07,29,ab,34,a2,50,b1) + + SD_ID128_CONST_STR() may be used to + convert constant 128-bit IDs into constant strings for output. The + following example code will output the string + "fc2e22bc6ee647b6b90729ab34a250b1": + int main(int argc, char *argv[]) { + puts(SD_ID128_CONST_STR(SD_MESSAGE_COREDUMP)); } - SD_ID128_FORMAT_STR and - SD_ID128_FORMAT_VAL() may be used - to format a 128-bit ID in a - printf3 - format string, as shown in the following - example: - - int main(int argc, char *argv[]) { - sd_id128_t id; - id = SD_ID128_MAKE(ee,89,be,71,bd,6e,43,d6,91,e6,c5,5d,eb,03,02,07); - printf("The ID encoded in this C file is " SD_ID128_FORMAT_STR ".\n", SD_ID128_FORMAT_VAL(id)); - return 0; + SD_ID128_FORMAT_STR and + SD_ID128_FORMAT_VAL() may be used to format a + 128-bit ID in a + printf3 + format string, as shown in the following example: + + int main(int argc, char *argv[]) { + sd_id128_t id; + id = SD_ID128_MAKE(ee,89,be,71,bd,6e,43,d6,91,e6,c5,5d,eb,03,02,07); + printf("The ID encoded in this C file is " SD_ID128_FORMAT_STR ".\n", SD_ID128_FORMAT_VAL(id)); + return 0; } - Use sd_id128_equal() to compare two 128-bit IDs: + Use sd_id128_equal() to compare two 128-bit IDs: - int main(int argc, char *argv[]) { - sd_id128_t a, b, c; - a = SD_ID128_MAKE(ee,89,be,71,bd,6e,43,d6,91,e6,c5,5d,eb,03,02,07); - b = SD_ID128_MAKE(f2,28,88,9c,5f,09,44,15,9d,d7,04,77,58,cb,e7,3e); - c = a; - assert(sd_id128_equal(a, c)); - assert(!sd_id128_equal(a, b)); - return 0; + int main(int argc, char *argv[]) { + sd_id128_t a, b, c; + a = SD_ID128_MAKE(ee,89,be,71,bd,6e,43,d6,91,e6,c5,5d,eb,03,02,07); + b = SD_ID128_MAKE(f2,28,88,9c,5f,09,44,15,9d,d7,04,77,58,cb,e7,3e); + c = a; + assert(sd_id128_equal(a, c)); + assert(!sd_id128_equal(a, b)); + return 0; } - Note that new, randomized IDs may be generated - with - journalctl1's - option. - - - - - - See Also - - systemd1, - sd_id128_to_string3, - sd_id128_randomize3, - sd_id128_get_machine3, - printf3, - journalctl1, - sd-journal7, - pkg-config1, - machine-id5 - - + Note that new, randomized IDs may be generated with + journalctl1's + option. + + + + + + See Also + + systemd1, + sd_id128_to_string3, + sd_id128_randomize3, + sd_id128_get_machine3, + printf3, + journalctl1, + sd-journal7, + pkg-config1, + machine-id5 + + diff --git a/man/sd-journal.xml b/man/sd-journal.xml index edf7c32d6dc..9b1a52207fe 100644 --- a/man/sd-journal.xml +++ b/man/sd-journal.xml @@ -1,6 +1,6 @@ + "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd"> - - - sd-journal - systemd - - - - Developer - Lennart - Poettering - lennart@poettering.net - - - - - - sd-journal - 3 - - - - sd-journal - APIs for submitting and querying log entries to and from the journal - - - - - #include <systemd/sd-journal.h> - - - - pkg-config --cflags --libs libsystemd - - - - - - Description - - sd-journal.h provides APIs - to submit and query log entries. The APIs exposed act - both as client for the - systemd-journald.service8 - journal service and as parser for the journal files - on disk. - - - See - sd_journal_print3, - sd_journal_stream_fd3, - sd_journal_open3, - sd_journal_next3, - sd_journal_get_realtime_usec3, - sd_journal_add_match3, - sd_journal_seek_head3, - sd_journal_get_cursor3, - sd_journal_get_cutoff_realtime_usec3, - sd_journal_get_cutoff_monotonic_usec3, - sd_journal_get_usage3, - sd_journal_get_catalog3 - and - sd_journal_get_fd3 - for more information about the functions - implemented. - - Command line access for submitting entries to - the journal is available with the - systemd-cat1 - tool. Command line access for querying entries from - the journal is available with the - journalctl1 - tool. - - - - - - See Also - - systemd1, - sd_journal_print3, - sd_journal_stream_fd3, - sd_journal_open3, - sd_journal_next3, - sd_journal_get_data3, - sd_journal_get_realtime_usec3, - sd_journal_add_match3, - sd_journal_seek_head3, - sd_journal_get_cursor3, - sd_journal_get_cutoff_realtime_usec3, - sd_journal_get_cutoff_monotonic_usec3, - sd_journal_get_usage3, - sd_journal_get_fd3, - sd_journal_query_unique3, - sd_journal_get_catalog3, - journalctl1, - sd-id1283, - pkg-config1 - - + xmlns:xi="http://www.w3.org/2001/XInclude"> + + + sd-journal + systemd + + + + Developer + Lennart + Poettering + lennart@poettering.net + + + + + + sd-journal + 3 + + + + sd-journal + APIs for submitting and querying log entries to and + from the journal + + + + + #include <systemd/sd-journal.h> + + + + pkg-config --cflags --libs libsystemd + + + + + + Description + + sd-journal.h provides APIs to submit + and query log entries. The APIs exposed act both as client for the + systemd-journald.service8 + journal service and as parser for the journal files on disk. + + + See + sd_journal_print3, + sd_journal_stream_fd3, + sd_journal_open3, + sd_journal_next3, + sd_journal_get_realtime_usec3, + sd_journal_add_match3, + sd_journal_seek_head3, + sd_journal_get_cursor3, + sd_journal_get_cutoff_realtime_usec3, + sd_journal_get_cutoff_monotonic_usec3, + sd_journal_get_usage3, + sd_journal_get_catalog3 + and + sd_journal_get_fd3 + for more information about the functions implemented. + + Command line access for submitting entries to the journal is + available with the + systemd-cat1 + tool. Command line access for querying entries from the journal is + available with the + journalctl1 + tool. + + + + + + See Also + + systemd1, + sd_journal_print3, + sd_journal_stream_fd3, + sd_journal_open3, + sd_journal_next3, + sd_journal_get_data3, + sd_journal_get_realtime_usec3, + sd_journal_add_match3, + sd_journal_seek_head3, + sd_journal_get_cursor3, + sd_journal_get_cutoff_realtime_usec3, + sd_journal_get_cutoff_monotonic_usec3, + sd_journal_get_usage3, + sd_journal_get_fd3, + sd_journal_query_unique3, + sd_journal_get_catalog3, + journalctl1, + sd-id1283, + pkg-config1 + + diff --git a/man/sd-login.xml b/man/sd-login.xml index f21170db160..328f71164da 100644 --- a/man/sd-login.xml +++ b/man/sd-login.xml @@ -1,6 +1,6 @@ + "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd"> - - - sd-login - systemd - - - - Developer - Lennart - Poettering - lennart@poettering.net - - - - - - sd-login - 3 - - - - sd-login - APIs for - tracking logins - - - - - #include <systemd/sd-login.h> - - - - pkg-config --cflags --libs libsystemd - - - - - Description - - sd-login.h provides APIs to - introspect and monitor seat, login session and user - status information on the local system. - - See Multi-Seat - on Linux for an introduction into multi-seat - support on Linux, the background for this set of APIs. - - Note that these APIs only allow purely passive access - and monitoring of seats, sessions and users. To - actively make changes to the seat configuration, - terminate login sessions, or switch session on a seat - you need to utilize the D-Bus API of - systemd-logind, instead. - - These functions synchronously access data in - /proc, - /sys/fs/cgroup and - /run. All of these are virtual - file systems, hence the runtime cost of the accesses - is relatively cheap. - - It is possible (and often a very good choice) to - mix calls to the synchronous interface of - sd-login.h with the asynchronous - D-Bus interface of systemd-logind. However, if this is - done you need to think a bit about possible races - since the stream of events from D-Bus and from - sd-login.h interfaces such as the - login monitor are asynchronous and not ordered against - each other. - - If the functions return string arrays, these are - generally NULL terminated and need to be freed by the - caller with the libc - free3 - call after use, including the strings referenced - therein. Similarly, individual strings returned need to - be freed, as well. - - As a special exception, instead of an empty - string array NULL may be returned, which should be - treated equivalent to an empty string array. - - See - sd_pid_get_session3, - sd_uid_get_state3, - sd_session_is_active3, - sd_seat_get_active3, - sd_get_seats3, - sd_login_monitor_new3 - for more information about the functions - implemented. - - - - - - See Also - - systemd1, - sd_pid_get_session3, - sd_uid_get_state3, - sd_session_is_active3, - sd_seat_get_active3, - sd_get_seats3, - sd_login_monitor_new3, - sd-daemon3, - pkg-config1 - - + xmlns:xi="http://www.w3.org/2001/XInclude"> + + + sd-login + systemd + + + + Developer + Lennart + Poettering + lennart@poettering.net + + + + + + sd-login + 3 + + + + sd-login + APIs for + tracking logins + + + + + #include <systemd/sd-login.h> + + + + pkg-config --cflags --libs libsystemd + + + + + Description + + sd-login.h provides APIs to introspect + and monitor seat, login session and user status information on the + local system. + + See Multi-Seat + on Linux for an introduction into multi-seat support on + Linux, the background for this set of APIs. + + Note that these APIs only allow purely passive access and + monitoring of seats, sessions and users. To actively make changes + to the seat configuration, terminate login sessions, or switch + session on a seat you need to utilize the D-Bus API of + systemd-logind, instead. + + These functions synchronously access data in + /proc, /sys/fs/cgroup + and /run. All of these are virtual file + systems, hence the runtime cost of the accesses is relatively + cheap. + + It is possible (and often a very good choice) to mix calls + to the synchronous interface of sd-login.h + with the asynchronous D-Bus interface of systemd-logind. However, + if this is done you need to think a bit about possible races since + the stream of events from D-Bus and from + sd-login.h interfaces such as the login + monitor are asynchronous and not ordered against each + other. + + If the functions return string arrays, these are generally + NULL terminated and need to be freed by the + caller with the libc + free3 + call after use, including the strings referenced therein. + Similarly, individual strings returned need to be freed, as + well. + + As a special exception, instead of an empty string array + NULL may be returned, which should be treated + equivalent to an empty string array. + + See + sd_pid_get_session3, + sd_uid_get_state3, + sd_session_is_active3, + sd_seat_get_active3, + sd_get_seats3, + sd_login_monitor_new3 + for more information about the functions + implemented. + + + + + + See Also + + systemd1, + sd_pid_get_session3, + sd_uid_get_state3, + sd_session_is_active3, + sd_seat_get_active3, + sd_get_seats3, + sd_login_monitor_new3, + sd-daemon3, + pkg-config1 + + diff --git a/man/sd_booted.xml b/man/sd_booted.xml index 28c153a3245..4dd674b8ead 100644 --- a/man/sd_booted.xml +++ b/man/sd_booted.xml @@ -1,6 +1,6 @@ + "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd"> - - - sd_booted - systemd - - - - Developer - Lennart - Poettering - lennart@poettering.net - - - - - - sd_booted - 3 - - - - sd_booted - Test whether the system is running the systemd init system - - - - - #include <systemd/sd-daemon.h> - - - int sd_booted - void - - - - - - Description - sd_booted() checks whether - the system was booted up using the systemd init system. - - - - Return Value - - On failure, this call returns a negative - errno-style error code. If the system was booted up - with systemd as init system, this call returns a - positive return value, zero otherwise. - - - - Notes - - - - Internally, this function checks whether the - directory /run/systemd/system/ - exists. A simple check like this can also be - implemented trivially in shell or any other - language. - - - - See Also - - systemd1, - sd-daemon3 - - + xmlns:xi="http://www.w3.org/2001/XInclude"> + + + sd_booted + systemd + + + + Developer + Lennart + Poettering + lennart@poettering.net + + + + + + sd_booted + 3 + + + + sd_booted + Test whether the system is running the systemd init system + + + + + #include <systemd/sd-daemon.h> + + + int sd_booted + void + + + + + + Description + sd_booted() checks whether the system + was booted up using the systemd init system. + + + + Return Value + + On failure, this call returns a negative errno-style error + code. If the system was booted up with systemd as init system, + this call returns a positive return value, zero otherwise. + + + + Notes + + + + Internally, this function checks whether the directory + /run/systemd/system/ exists. A simple check + like this can also be implemented trivially in shell or any other + language. + + + + See Also + + systemd1, + sd-daemon3 + + diff --git a/man/sd_bus_message_get_cookie.xml b/man/sd_bus_message_get_cookie.xml index 3e3f9bd7be8..02374d7508e 100644 --- a/man/sd_bus_message_get_cookie.xml +++ b/man/sd_bus_message_get_cookie.xml @@ -1,6 +1,6 @@ + "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd"> + "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd"> + "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd"> + "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd"> + "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd"> + "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd"> + "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd"> + "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd"> - - - sd_is_fifo - systemd - - - - Developer - Lennart - Poettering - lennart@poettering.net - - - - - - sd_is_fifo - 3 - - - - sd_is_fifo - sd_is_socket - sd_is_socket_inet - sd_is_socket_unix - sd_is_mq - sd_is_special - Check the type of a file descriptor - - - - - #include <systemd/sd-daemon.h> - - - int sd_is_fifo - int fd - const char *path - - - - int sd_is_socket - int fd - int family - int type - int listening - - - - int sd_is_socket_inet - int fd - int family - int type - int listening - uint16_t port - - - - int sd_is_socket_unix - int fd - int type - int listening - const char *path - size_t length - - - - int sd_is_mq - int fd - const char *path - - - - int sd_is_special - int fd - const char *path - - - - - - - Description - - sd_is_fifo() may be called - to check whether the specified file descriptor refers - to a FIFO or pipe. If the path - parameter is not NULL, it is - checked whether the FIFO is bound to the specified - file system path. - - sd_is_socket() may be - called to check whether the specified file descriptor - refers to a socket. If the - family parameter is not - AF_UNSPEC, it is checked whether - the socket is of the specified family (AF_UNIX, - AF_INET, ...). If the - type parameter is not 0, it is - checked whether the socket is of the specified type - (SOCK_STREAM, - SOCK_DGRAM, ...). If the - listening parameter is positive, - it is checked whether the socket is in accepting mode, - i.e. listen() has been called for - it. If listening is 0, it is - checked whether the socket is not in this mode. If the - parameter is negative, no such check is made. The - listening parameter should only - be used for stream sockets and should be set to a - negative value otherwise. - - sd_is_socket_inet() is - similar to sd_is_socket(), but - optionally checks the IPv4 or IPv6 port number the - socket is bound to, unless port - is zero. For this call family - must be passed as either AF_UNSPEC, AF_INET, or - AF_INET6. - - sd_is_socket_unix() is - similar to sd_is_socket() but - optionally checks the AF_UNIX path the socket is bound - to, unless the path parameter - is NULL. For normal file system AF_UNIX sockets, - set the length parameter to 0. For - Linux abstract namespace sockets, set the - length to the size of the - address, including the initial 0 byte, and set the - path to the initial 0 byte of - the socket address. - - sd_is_mq() may be called to - check whether the specified file descriptor refers to - a POSIX message queue. If the - path parameter is not - NULL, it is checked whether the - message queue is bound to the specified name. - - sd_is_special() may be - called to check whether the specified file descriptor - refers to a special file. If the - path parameter is not - NULL, it is checked whether the file - descriptor is bound to the specified file - name. Special files in this context are character - device nodes and files in /proc - or /sys. - - - - Return Value - - On failure, these calls return a negative - errno-style error code. If the file descriptor is of - the specified type and bound to the specified address, - a positive return value is returned, otherwise - zero. - - - - Notes - - - - Internally, these function use a combination of - fstat() and - getsockname() to check the file - descriptor type and where it is bound to. - - - - See Also - - systemd1, - sd-daemon3, - sd_listen_fds3, - systemd.service5, - systemd.socket5 - - + xmlns:xi="http://www.w3.org/2001/XInclude"> + + + sd_is_fifo + systemd + + + + Developer + Lennart + Poettering + lennart@poettering.net + + + + + + sd_is_fifo + 3 + + + + sd_is_fifo + sd_is_socket + sd_is_socket_inet + sd_is_socket_unix + sd_is_mq + sd_is_special + Check the type of a file descriptor + + + + + #include <systemd/sd-daemon.h> + + + int sd_is_fifo + int fd + const char *path + + + + int sd_is_socket + int fd + int family + int type + int listening + + + + int sd_is_socket_inet + int fd + int family + int type + int listening + uint16_t port + + + + int sd_is_socket_unix + int fd + int type + int listening + const char *path + size_t length + + + + int sd_is_mq + int fd + const char *path + + + + int sd_is_special + int fd + const char *path + + + + + + + Description + + sd_is_fifo() may be called to check + whether the specified file descriptor refers to a FIFO or pipe. If + the path parameter is not + NULL, it is checked whether the FIFO is bound + to the specified file system path. + + sd_is_socket() may be called to check + whether the specified file descriptor refers to a socket. If the + family parameter is not + AF_UNSPEC, it is checked whether the socket + is of the specified family (AF_UNIX, AF_INET, + ...). If the type parameter is not 0, it is + checked whether the socket is of the specified type + (SOCK_STREAM, + SOCK_DGRAM, ...). If the + listening parameter is positive, it is + checked whether the socket is in accepting mode, i.e. + listen() has been called for it. If + listening is 0, it is checked whether the + socket is not in this mode. If the parameter is negative, no such + check is made. The listening parameter + should only be used for stream sockets and should be set to a + negative value otherwise. + + sd_is_socket_inet() is similar to + sd_is_socket(), but optionally checks the + IPv4 or IPv6 port number the socket is bound to, unless + port is zero. For this call + family must be passed as either + AF_UNSPEC, AF_INET, or + AF_INET6. + + sd_is_socket_unix() is similar to + sd_is_socket() but optionally checks the + AF_UNIX path the socket is bound to, unless + the path parameter is + NULL. For normal file system + AF_UNIX sockets, set the + length parameter to 0. For Linux abstract + namespace sockets, set the length to the + size of the address, including the initial 0 byte, and set the + path to the initial 0 byte of the socket + address. + + sd_is_mq() may be called to check + whether the specified file descriptor refers to a POSIX message + queue. If the path parameter is not + NULL, it is checked whether the message queue + is bound to the specified name. + + sd_is_special() may be called to check + whether the specified file descriptor refers to a special file. If + the path parameter is not + NULL, it is checked whether the file + descriptor is bound to the specified file name. Special files in + this context are character device nodes and files in + /proc or /sys. + + + + Return Value + + On failure, these calls return a negative errno-style error + code. If the file descriptor is of the specified type and bound to + the specified address, a positive return value is returned, + otherwise zero. + + + + Notes + + + + Internally, these function use a combination of + fstat() and + getsockname() to check the file descriptor + type and where it is bound to. + + + + See Also + + systemd1, + sd-daemon3, + sd_listen_fds3, + systemd.service5, + systemd.socket5 + + diff --git a/man/sd_journal_add_match.xml b/man/sd_journal_add_match.xml index 21a5ab13421..420f56356a4 100644 --- a/man/sd_journal_add_match.xml +++ b/man/sd_journal_add_match.xml @@ -1,6 +1,6 @@ + "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd"> + "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd"> + "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd"> + "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd"> + "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd"> + "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd"> + "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd"> + "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd"> + "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd"> + "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd"> + "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd"> + "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd"> + "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd"> + "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd"> + "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd"> - - - sd_listen_fds - systemd - - - - Developer - Lennart - Poettering - lennart@poettering.net - - - - - - sd_listen_fds - 3 - - - - sd_listen_fds - SD_LISTEN_FDS_START - Check for file descriptors passed by the system manager - - - - - #include <systemd/sd-daemon.h> - - #define SD_LISTEN_FDS_START 3 - - - int sd_listen_fds - int unset_environment - - - - - - Description - - sd_listen_fds() shall be - called by a daemon to check for file descriptors - passed by the init system as part of the socket-based - activation logic. - - If the unset_environment - parameter is non-zero, - sd_listen_fds() will unset the - $LISTEN_FDS and $LISTEN_PID - environment variables before returning (regardless of - whether the function call itself succeeded or - not). Further calls to - sd_listen_fds() will then fail, - but the variables are no longer inherited by child - processes. - - If a daemon receives more than one file - descriptor, they will be passed in the same order as - configured in the systemd socket unit file (see - systemd.socket5 - for details). Nonetheless, it is recommended to verify - the correct socket types before using them. To - simplify this checking, the functions - sd_is_fifo3, - sd_is_socket3, - sd_is_socket_inet3, - sd_is_socket_unix3 - are provided. In order to maximize flexibility, it is - recommended to make these checks as loose as possible - without allowing incorrect setups. i.e. often, the - actual port number a socket is bound to matters little - for the service to work, hence it should not be - verified. On the other hand, whether a socket is a - datagram or stream socket matters a lot for the most - common program logics and should be checked. - - This function call will set the FD_CLOEXEC flag - for all passed file descriptors to avoid further - inheritance to children of the calling process. - - If multiple socket units activate the same - service the order of the file descriptors passed to - its main process is undefined. If additional file - descriptors have been passed to the service manager - using - sd_pid_notify_with_fds3's - FDSTORE=1 messages, these file - descriptors are passed last, in arbitrary order, and - with duplicates removed. - - - - Return Value - - On failure, this call returns a negative - errno-style error code. If - $LISTEN_FDS/$LISTEN_PID - was not set or was not correctly set for this daemon and - hence no file descriptors were received, 0 is - returned. Otherwise, the number of file descriptors - passed is returned. The application may find them - starting with file descriptor SD_LISTEN_FDS_START, - i.e. file descriptor 3. - - - - Notes - - - - Internally, this function checks whether the - $LISTEN_PID environment variable - equals the daemon PID. If not, it returns - immediately. Otherwise, it parses the number passed in - the $LISTEN_FDS environment - variable, then sets the FD_CLOEXEC flag for the parsed - number of file descriptors starting from - SD_LISTEN_FDS_START. Finally, it returns the parsed - number. - - - - Environment - - - - $LISTEN_PID - $LISTEN_FDS - - Set by the init system - for supervised processes that use - socket-based activation. This - environment variable specifies the - data - sd_listen_fds() - parses. See above for - details. - - - - - - See Also - - - systemd1, - sd-daemon3, - sd_is_fifo3, - sd_is_socket3, - sd_is_socket_inet3, - sd_is_socket_unix3, - daemon7, - systemd.service5, - systemd.socket5 - - + xmlns:xi="http://www.w3.org/2001/XInclude"> + + + sd_listen_fds + systemd + + + + Developer + Lennart + Poettering + lennart@poettering.net + + + + + + sd_listen_fds + 3 + + + + sd_listen_fds + SD_LISTEN_FDS_START + Check for file descriptors passed by the system manager + + + + + #include <systemd/sd-daemon.h> + + #define SD_LISTEN_FDS_START 3 + + + int sd_listen_fds + int unset_environment + + + + + + Description + + sd_listen_fds() shall be called by a + daemon to check for file descriptors passed by the init system as + part of the socket-based activation logic. + + If the unset_environment parameter is + non-zero, sd_listen_fds() will unset the + $LISTEN_FDS and $LISTEN_PID + environment variables before returning (regardless of whether the + function call itself succeeded or not). Further calls to + sd_listen_fds() will then fail, but the + variables are no longer inherited by child processes. + + If a daemon receives more than one file descriptor, they + will be passed in the same order as configured in the systemd + socket unit file (see + systemd.socket5 + for details). Nonetheless, it is recommended to verify the correct + socket types before using them. To simplify this checking, the + functions + sd_is_fifo3, + sd_is_socket3, + sd_is_socket_inet3, + sd_is_socket_unix3 + are provided. In order to maximize flexibility, it is recommended + to make these checks as loose as possible without allowing + incorrect setups. i.e. often, the actual port number a socket is + bound to matters little for the service to work, hence it should + not be verified. On the other hand, whether a socket is a datagram + or stream socket matters a lot for the most common program logics + and should be checked. + + This function call will set the FD_CLOEXEC flag for all + passed file descriptors to avoid further inheritance to children + of the calling process. + + If multiple socket units activate the same service the order + of the file descriptors passed to its main process is undefined. + If additional file descriptors have been passed to the service + manager using + sd_pid_notify_with_fds3's + FDSTORE=1 messages, these file descriptors are + passed last, in arbitrary order, and with duplicates + removed. + + + + Return Value + + On failure, this call returns a negative errno-style error + code. If + $LISTEN_FDS/$LISTEN_PID was + not set or was not correctly set for this daemon and hence no file + descriptors were received, 0 is returned. Otherwise, the number of + file descriptors passed is returned. The application may find them + starting with file descriptor SD_LISTEN_FDS_START, i.e. file + descriptor 3. + + + + Notes + + + + Internally, this function checks whether the + $LISTEN_PID environment variable equals the + daemon PID. If not, it returns immediately. Otherwise, it parses + the number passed in the $LISTEN_FDS + environment variable, then sets the FD_CLOEXEC flag for the parsed + number of file descriptors starting from SD_LISTEN_FDS_START. + Finally, it returns the parsed number. + + + + Environment + + + + $LISTEN_PID + $LISTEN_FDS + + Set by the init system + for supervised processes that use + socket-based activation. This + environment variable specifies the + data + sd_listen_fds() + parses. See above for + details. + + + + + + See Also + + + systemd1, + sd-daemon3, + sd_is_fifo3, + sd_is_socket3, + sd_is_socket_inet3, + sd_is_socket_unix3, + daemon7, + systemd.service5, + systemd.socket5 + + diff --git a/man/sd_login_monitor_new.xml b/man/sd_login_monitor_new.xml index ba6623826fd..a7b47a3207f 100644 --- a/man/sd_login_monitor_new.xml +++ b/man/sd_login_monitor_new.xml @@ -1,6 +1,6 @@ + "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd"> + "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd"> + "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd"> - - - sd_notify - systemd - - - - Developer - Lennart - Poettering - lennart@poettering.net - - - - - - sd_notify - 3 - - - - sd_notify - sd_notifyf - sd_pid_notify - sd_pid_notifyf - sd_pid_notify_with_fds - Notify service manager about start-up completion and other service status changes - - - - - #include <systemd/sd-daemon.h> - - - int sd_notify - int unset_environment - const char *state - - - - int sd_notifyf - int unset_environment - const char *format - ... - - - - int sd_pid_notify - pid_t pid - int unset_environment - const char *state - - - - int sd_pid_notifyf - pid_t pid - int unset_environment - const char *format - ... - - - - int sd_pid_notify_with_fds - pid_t pid - int unset_environment - const char *state - const int *fds - unsigned n_fds - - - - - - Description - sd_notify() may be called - by a service to notify the service manager about - state changes. It can be used to send arbitrary - information, encoded in an environment-block-like - string. Most importantly it can be used for start-up - completion notification. - - If the unset_environment - parameter is non-zero, sd_notify() - will unset the $NOTIFY_SOCKET - environment variable before returning (regardless of - whether the function call itself succeeded or - not). Further calls to - sd_notify() will then fail, but - the variable is no longer inherited by child - processes. - - The state parameter - should contain a newline-separated list of variable - assignments, similar in style to an environment - block. A trailing newline is implied if none is - specified. The string may contain any kind of variable - assignments, but the following shall be considered - well-known: - - - - READY=1 - - Tells the service - manager that service startup is - finished. This is only used by systemd - if the service definition file has - Type=notify set. Since there is little - value in signaling non-readiness, the - only value services should send is - READY=1 - (i.e. READY=0 is - not defined). - - - - RELOADING=1 - - Tells the service manager - that the service is reloading its - configuration. This is useful to allow - the service manager to track the service's - internal state, and present it to the - user. Note that a service that sends - this notification must also send a - READY=1 - notification when it completed - reloading its - configuration. - - - - STOPPING=1 - - Tells the service manager - that the service is beginning its - shutdown. This is useful to allow the - service manager to track the service's - internal state, and present it to the - user. - - - - STATUS=... - - Passes a single-line - UTF-8 status string back to the service manager - that describes the service state. This - is free-form and can be used for - various purposes: general state - feedback, fsck-like programs could - pass completion percentages and - failing programs could pass a human - readable error message. Example: - STATUS=Completed 66% of file - system - check... - - - - ERRNO=... - - If a service fails, the - errno-style error code, formatted as - string. Example: ERRNO=2 for - ENOENT. - - - - BUSERROR=... - - If a service fails, the - D-Bus error-style error code. Example: - BUSERROR=org.freedesktop.DBus.Error.TimedOut - - - - MAINPID=... - - The main process ID (PID) of the - service, in case the service manager did - not fork off the process - itself. Example: - MAINPID=4711 - - - - WATCHDOG=1 - - Tells the service manager to - update the watchdog timestamp. This is - the keep-alive ping that services need - to issue in regular intervals if - WatchdogSec= is - enabled for it. See - systemd.service5 - for information how to enable this - functionality and - sd_watchdog_enabled3 - for the details of how the service can - check if the the watchdog is enabled. - - - - - - FDSTORE=1 - - Stores additional file - descriptors in the service - manager. File descriptors sent this - way will be maintained per-service by - the service manager and be passed - again using the usual file descriptor - passing logic on the next invocation - of the service (see - sd_listen_fds3). This - is useful for implementing service - restart schemes where services - serialize their state to - /run, push their - file descriptors to the system - manager, and are then restarted, - retrieving their state again via - socket passing and - /run. Note that - the service manager will accept - messages for a service only if - FileDescriptorStoreMax= - is set to non-zero for it (defaults to - zero). See - systemd.service5 - for details. Multiple arrays of file - descriptors may be sent in separate - messages, in which case the arrays are - combined. Note that the service - manager removes duplicate file - descriptors before passing them to the - service. Use - sd_pid_notify_with_fds() - to send messages with - FDSTORE=1, see - below. - - - - - It is recommended to prefix variable names that - are not listed above with X_ to - avoid namespace clashes. - - Note that systemd will accept status data sent - from a service only if the - NotifyAccess= option is correctly - set in the service definition file. See - systemd.service5 - for details. - - sd_notifyf() is similar to - sd_notify() but takes a - printf()-like format string plus - arguments. - - sd_pid_notify() and - sd_pid_notifyf() are similar to - sd_notify() and - sd_notifyf() but take a process - ID (PID) to use as originating PID for the message as - first argument. This is useful to send notification - messages on behalf of other processes, provided the - appropriate privileges are available. If the PID - argument is specified as 0 the process ID of the - calling process is used, in which case the calls are - fully equivalent to sd_notify() - and sd_notifyf(). - - sd_pid_notify_with_fds() is - similar to sd_pid_notify() but - takes an additional array of file descriptors. These - file descriptors are sent along the notification - message to the service manager. This is particularly - useful for sending FDSTORE=1 - messages, as described above. The additional arguments - are a pointer to the file descriptor array plus the - number of file descriptors in the array. If the number - of file descriptors is passed as 0, the call is fully - equivalent to sd_pid_notify(), - i.e. no file descriptors are passed. Note that sending - file descriptors to the service manager on messages - that do not expect them (i.e. without - FDSTORE=1) they are immediately - closed on reception. - - - - Return Value - - On failure, these calls return a negative - errno-style error code. If - $NOTIFY_SOCKET was not set and - hence no status data could be sent, 0 is returned. If - the status was sent, these functions return with a - positive return value. In order to support both, init - systems that implement this scheme and those which - do not, it is generally recommended to ignore the return - value of this call. - - - - Notes - - - - Internally, these functions send a single - datagram with the state string as payload to the - AF_UNIX socket referenced in the - $NOTIFY_SOCKET environment - variable. If the first character of - $NOTIFY_SOCKET is @, the string is - understood as Linux abstract namespace socket. The - datagram is accompanied by the process credentials of - the sending service, using SCM_CREDENTIALS. - - - - Environment - - - - $NOTIFY_SOCKET - - Set by the service manager - for supervised processes for status - and start-up completion - notification. This environment variable - specifies the socket - sd_notify() talks - to. See above for details. - - - - - - Examples - - - Start-up Notification - - When a service finished starting up, it - might issue the following call to notify - the service manager: - - sd_notify(0, "READY=1"); - - - - Extended Start-up Notification - - A service could send the following after - completing initialization: - - sd_notifyf(0, "READY=1\n" - "STATUS=Processing requests...\n" - "MAINPID=%lu", - (unsigned long) getpid()); - - - - Error Cause Notification - - A service could send the following shortly before exiting, on failure: - - sd_notifyf(0, "STATUS=Failed to start up: %s\n" - "ERRNO=%i", - strerror(errno), - errno); - - - - Store a File Descriptor in the Service Manager - - To store an open file descriptor in the - service manager, in order to continue - operation after a service restart without - losing state use - FDSTORE=1: - - sd_pid_notify_with_fds(0, 0, "FDSTORE=1", &fd, 1); - - - - - See Also - - systemd1, - sd-daemon3, - daemon7, - systemd.service5, - sd_watchdog_enabled3 - - + xmlns:xi="http://www.w3.org/2001/XInclude"> + + + sd_notify + systemd + + + + Developer + Lennart + Poettering + lennart@poettering.net + + + + + + sd_notify + 3 + + + + sd_notify + sd_notifyf + sd_pid_notify + sd_pid_notifyf + sd_pid_notify_with_fds + Notify service manager about start-up completion and other service status changes + + + + + #include <systemd/sd-daemon.h> + + + int sd_notify + int unset_environment + const char *state + + + + int sd_notifyf + int unset_environment + const char *format + ... + + + + int sd_pid_notify + pid_t pid + int unset_environment + const char *state + + + + int sd_pid_notifyf + pid_t pid + int unset_environment + const char *format + ... + + + + int sd_pid_notify_with_fds + pid_t pid + int unset_environment + const char *state + const int *fds + unsigned n_fds + + + + + + Description + sd_notify() may be called by a service + to notify the service manager about state changes. It can be used + to send arbitrary information, encoded in an + environment-block-like string. Most importantly it can be used for + start-up completion notification. + + If the unset_environment parameter is + non-zero, sd_notify() will unset the + $NOTIFY_SOCKET environment variable before + returning (regardless of whether the function call itself + succeeded or not). Further calls to + sd_notify() will then fail, but the variable + is no longer inherited by child processes. + + The state parameter should contain a + newline-separated list of variable assignments, similar in style + to an environment block. A trailing newline is implied if none is + specified. The string may contain any kind of variable + assignments, but the following shall be considered + well-known: + + + + READY=1 + + Tells the service manager that service startup + is finished. This is only used by systemd if the service + definition file has Type=notify set. Since there is little + value in signaling non-readiness, the only value services + should send is READY=1 (i.e. + READY=0 is not defined). + + + + RELOADING=1 + + Tells the service manager that the service is + reloading its configuration. This is useful to allow the + service manager to track the service's internal state, and + present it to the user. Note that a service that sends this + notification must also send a READY=1 + notification when it completed reloading its + configuration. + + + + STOPPING=1 + + Tells the service manager that the service is + beginning its shutdown. This is useful to allow the service + manager to track the service's internal state, and present it + to the user. + + + + STATUS=... + + Passes a single-line UTF-8 status string back + to the service manager that describes the service state. This + is free-form and can be used for various purposes: general + state feedback, fsck-like programs could pass completion + percentages and failing programs could pass a human readable + error message. Example: STATUS=Completed 66% of file + system check... + + + + ERRNO=... + + If a service fails, the errno-style error + code, formatted as string. Example: ERRNO=2 + for ENOENT. + + + + BUSERROR=... + + If a service fails, the D-Bus error-style + error code. Example: + BUSERROR=org.freedesktop.DBus.Error.TimedOut + + + + MAINPID=... + + The main process ID (PID) of the service, in + case the service manager did not fork off the process itself. + Example: MAINPID=4711 + + + + WATCHDOG=1 + + Tells the service manager to update the + watchdog timestamp. This is the keep-alive ping that services + need to issue in regular intervals if + WatchdogSec= is enabled for it. See + systemd.service5 + for information how to enable this functionality and + sd_watchdog_enabled3 + for the details of how the service can check if the the + watchdog is enabled. + + + + + FDSTORE=1 + + Stores additional file descriptors in the + service manager. File descriptors sent this way will be + maintained per-service by the service manager and be passed + again using the usual file descriptor passing logic on the + next invocation of the service (see + sd_listen_fds3). + This is useful for implementing service restart schemes where + services serialize their state to /run, + push their file descriptors to the system manager, and are + then restarted, retrieving their state again via socket + passing and /run. Note that the service + manager will accept messages for a service only if + FileDescriptorStoreMax= is set to non-zero + for it (defaults to zero). See + systemd.service5 + for details. Multiple arrays of file descriptors may be sent + in separate messages, in which case the arrays are combined. + Note that the service manager removes duplicate file + descriptors before passing them to the service. Use + sd_pid_notify_with_fds() to send messages + with FDSTORE=1, see + below. + + + + + It is recommended to prefix variable names that are not + listed above with X_ to avoid namespace + clashes. + + Note that systemd will accept status data sent from a + service only if the NotifyAccess= option is + correctly set in the service definition file. See + systemd.service5 + for details. + + sd_notifyf() is similar to + sd_notify() but takes a + printf()-like format string plus + arguments. + + sd_pid_notify() and + sd_pid_notifyf() are similar to + sd_notify() and + sd_notifyf() but take a process ID (PID) to + use as originating PID for the message as first argument. This is + useful to send notification messages on behalf of other processes, + provided the appropriate privileges are available. If the PID + argument is specified as 0 the process ID of the calling process + is used, in which case the calls are fully equivalent to + sd_notify() and + sd_notifyf(). + + sd_pid_notify_with_fds() is similar to + sd_pid_notify() but takes an additional array + of file descriptors. These file descriptors are sent along the + notification message to the service manager. This is particularly + useful for sending FDSTORE=1 messages, as + described above. The additional arguments are a pointer to the + file descriptor array plus the number of file descriptors in the + array. If the number of file descriptors is passed as 0, the call + is fully equivalent to sd_pid_notify(), i.e. + no file descriptors are passed. Note that sending file descriptors + to the service manager on messages that do not expect them (i.e. + without FDSTORE=1) they are immediately closed + on reception. + + + + Return Value + + On failure, these calls return a negative errno-style error + code. If $NOTIFY_SOCKET was not set and hence + no status data could be sent, 0 is returned. If the status was + sent, these functions return with a positive return value. In + order to support both, init systems that implement this scheme and + those which do not, it is generally recommended to ignore the + return value of this call. + + + + Notes + + + + Internally, these functions send a single datagram with the + state string as payload to the AF_UNIX socket + referenced in the $NOTIFY_SOCKET environment + variable. If the first character of + $NOTIFY_SOCKET is @, the + string is understood as Linux abstract namespace socket. The + datagram is accompanied by the process credentials of the sending + service, using SCM_CREDENTIALS. + + + + Environment + + + + $NOTIFY_SOCKET + + Set by the service manager for supervised + processes for status and start-up completion notification. + This environment variable specifies the socket + sd_notify() talks to. See above for + details. + + + + + + Examples + + + Start-up Notification + + When a service finished starting up, it might issue the + following call to notify the service manager: + + sd_notify(0, "READY=1"); + + + + Extended Start-up Notification + + A service could send the following after completing + initialization: + + sd_notifyf(0, "READY=1\n" + "STATUS=Processing requests...\n" + "MAINPID=%lu", + (unsigned long) getpid()); + + + + Error Cause Notification + + A service could send the following shortly before exiting, on failure: + + sd_notifyf(0, "STATUS=Failed to start up: %s\n" + "ERRNO=%i", + strerror(errno), + errno); + + + + Store a File Descriptor in the Service Manager + + To store an open file descriptor in the service manager, + in order to continue operation after a service restart without + losing state use FDSTORE=1: + + sd_pid_notify_with_fds(0, 0, "FDSTORE=1", &fd, 1); + + + + + See Also + + systemd1, + sd-daemon3, + daemon7, + systemd.service5, + sd_watchdog_enabled3 + + diff --git a/man/sd_pid_get_session.xml b/man/sd_pid_get_session.xml index 050f701da3e..f708d0d5e1b 100644 --- a/man/sd_pid_get_session.xml +++ b/man/sd_pid_get_session.xml @@ -1,6 +1,6 @@ + "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd"> + "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd"> + "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd"> + "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd"> + "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd"> - - - sd_watchdog_enabled - systemd - - - - Developer - Lennart - Poettering - lennart@poettering.net - - - - - - sd_watchdog_enabled - 3 - - - - sd_watchdog_enabled - Check whether the service manager expects watchdog keep-alive notifications from a service - - - - - #include <systemd/sd-daemon.h> - - - int sd_watchdog_enabled - int unset_environment - uint64_t *usec - - - - - - Description - sd_watchdog_enabled() may - be called by a service to detect whether the service - manager expects regular keep-alive watchdog - notification events from it, and the timeout after - which the manager will act on the service if it did - not get such a notification. - - If the $WATCHDOG_USEC - environment variable is set, and the - $WATCHDOG_PID variable is unset or - set to the PID of the current process, the service - manager expects notifications from this process. The - manager will usually terminate a service when it does - not get a notification message within the specified - time after startup and after each previous message. It - is recommended that a daemon sends a keep-alive - notification message to the service manager every half - of the time returned here. Notification messages may - be sent with - sd_notify3 - with a message string of - WATCHDOG=1. - - If the unset_environment - parameter is non-zero, - sd_watchdog_enabled() will unset - the $WATCHDOG_USEC and - $WATCHDOG_PID environment variables - before returning (regardless of whether the function - call itself succeeded or not). Those variables are no - longer inherited by child processes. Further calls to - sd_watchdog_enabled() will also - return with zero. - - If the usec parameter is - non-NULL, sd_watchdog_enabled() - will write the timeout in µs for the watchdog - logic to it. - - To enable service supervision with the watchdog - logic, use WatchdogSec= in service - files. See - systemd.service5 - for details. - - - - Return Value - - On failure, this call returns a negative - errno-style error code. If the service manager expects - watchdog keep-alive notification messages to be sent, - > 0 is returned, otherwise 0 is returned. Only if - the return value is > 0, the - usec parameter is valid after - the call. - - - - Notes - - - - Internally, this functions parses the - $WATCHDOG_PID and - $WATCHDOG_USEC environment - variable. The call will ignore these variables if - $WATCHDOG_PID does not contain the PID - of the current process, under the assumption that in - that case, the variables were set for a different - process further up the process tree. - - - - Environment - - - - $WATCHDOG_PID - - Set by the system - manager for supervised process for - which watchdog support is enabled, and - contains the PID of that process. See - above for details. - - - - $WATCHDOG_USEC - - Set by the system - manager for supervised process for - which watchdog support is enabled, and - contains the watchdog timeout in µs - See above for - details. - - - - - - History - - The watchdog functionality and the - $WATCHDOG_USEC variable were - added in systemd-41. - - sd_watchdog_enabled() - function was added in systemd-209. Since that version - the $WATCHDOG_PID variable is also - set. - - - - See Also - - systemd1, - sd-daemon3, - daemon7, - systemd.service5, - sd_notify3 - - + xmlns:xi="http://www.w3.org/2001/XInclude"> + + + sd_watchdog_enabled + systemd + + + + Developer + Lennart + Poettering + lennart@poettering.net + + + + + + sd_watchdog_enabled + 3 + + + + sd_watchdog_enabled + Check whether the service manager expects watchdog keep-alive notifications from a service + + + + + #include <systemd/sd-daemon.h> + + + int sd_watchdog_enabled + int unset_environment + uint64_t *usec + + + + + + Description + sd_watchdog_enabled() may be called by + a service to detect whether the service manager expects regular + keep-alive watchdog notification events from it, and the timeout + after which the manager will act on the service if it did not get + such a notification. + + If the $WATCHDOG_USEC environment + variable is set, and the $WATCHDOG_PID variable + is unset or set to the PID of the current process, the service + manager expects notifications from this process. The manager will + usually terminate a service when it does not get a notification + message within the specified time after startup and after each + previous message. It is recommended that a daemon sends a + keep-alive notification message to the service manager every half + of the time returned here. Notification messages may be sent with + sd_notify3 + with a message string of WATCHDOG=1. + + If the unset_environment parameter is + non-zero, sd_watchdog_enabled() will unset + the $WATCHDOG_USEC and + $WATCHDOG_PID environment variables before + returning (regardless of whether the function call itself + succeeded or not). Those variables are no longer inherited by + child processes. Further calls to + sd_watchdog_enabled() will also return with + zero. + + If the usec parameter is non-NULL, + sd_watchdog_enabled() will write the timeout + in µs for the watchdog logic to it. + + To enable service supervision with the watchdog logic, use + WatchdogSec= in service files. See + systemd.service5 + for details. + + + + Return Value + + On failure, this call returns a negative errno-style error + code. If the service manager expects watchdog keep-alive + notification messages to be sent, > 0 is returned, otherwise 0 + is returned. Only if the return value is > 0, the + usec parameter is valid after the + call. + + + + Notes + + + + Internally, this functions parses the + $WATCHDOG_PID and + $WATCHDOG_USEC environment variable. The call + will ignore these variables if $WATCHDOG_PID + does not contain the PID of the current process, under the + assumption that in that case, the variables were set for a + different process further up the process tree. + + + + Environment + + + + $WATCHDOG_PID + + Set by the system manager for supervised + process for which watchdog support is enabled, and contains + the PID of that process. See above for + details. + + + + $WATCHDOG_USEC + + Set by the system manager for supervised + process for which watchdog support is enabled, and contains + the watchdog timeout in µs See above for + details. + + + + + + History + + The watchdog functionality and the + $WATCHDOG_USEC variable were added in + systemd-41. + + sd_watchdog_enabled() function was + added in systemd-209. Since that version the + $WATCHDOG_PID variable is also set. + + + + See Also + + systemd1, + sd-daemon3, + daemon7, + systemd.service5, + sd_notify3 + + diff --git a/man/shutdown.xml b/man/shutdown.xml index 6a4c1844a47..a8af387c676 100644 --- a/man/shutdown.xml +++ b/man/shutdown.xml @@ -1,6 +1,6 @@ + "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd"> - - - shutdown - systemd - - - - Developer - Lennart - Poettering - lennart@poettering.net - - - - - - shutdown - 8 - - - - shutdown - Halt, power-off or reboot the machine - - - - - shutdown OPTIONS TIME WALL - - - - - Description - - shutdown may be used to halt, - power-off or reboot the machine. - - The first argument may be a time string (which - is usually now). Optionally, this - may be followed by a wall message to be sent to all - logged-in users before going down. - - The time string may either be in the format - hh:mm for hour/minutes specifying - the time to execute the shutdown at, specified in 24h - clock format. Alternatively it may be in the syntax - +m referring to the specified - number of minutes m from now. now - is an alias for +0, i.e. for - triggering an immediate shutdown. If no time argument - is specified, +1 is - implied. - - Note that to specify a wall message you must - specify a time argument, too. - - If the time argument is used, 5 minutes - before the system goes down the - /run/nologin file is created to - ensure that further logins shall not be - allowed. - - - - Options - - The following options are understood: - - - - - - - - - - - - - Halt the machine. - - - - - - - Power-off the - machine (the default). - - - - - - - Reboot the - machine. - - - - - - Equivalent to - , unless - is - specified. - - - - - - Do not halt, power-off, - reboot, just write wall - message. - - - - - - Do not send wall - message before - halt, power-off, reboot. - - - - - - Cancel a pending - shutdown. This may be used cancel the - effect of an invocation of - shutdown with a - time argument that is not - +0 or - now. - - - - - - - Exit status - - On success, 0 is returned, a non-zero failure - code otherwise. - - - - See Also - - systemd1, - systemctl1, - halt8, - wall1 - - + xmlns:xi="http://www.w3.org/2001/XInclude"> + + + shutdown + systemd + + + + Developer + Lennart + Poettering + lennart@poettering.net + + + + + + shutdown + 8 + + + + shutdown + Halt, power-off or reboot the machine + + + + + shutdown + OPTIONS + TIME + WALL + + + + + Description + + shutdown may be used to halt, power-off + or reboot the machine. + + The first argument may be a time string (which is usually + now). Optionally, this may be followed by a + wall message to be sent to all logged-in users before going + down. + + The time string may either be in the format + hh:mm for hour/minutes specifying the time to + execute the shutdown at, specified in 24h clock format. + Alternatively it may be in the syntax +m + referring to the specified number of minutes m from now. + now is an alias for +0, i.e. + for triggering an immediate shutdown. If no time argument is + specified, +1 is implied. + + Note that to specify a wall message you must specify a time + argument, too. + + If the time argument is used, 5 minutes before the system + goes down the /run/nologin file is created to + ensure that further logins shall not be allowed. + + + + Options + + The following options are understood: + + + + + + + + + + + + + Halt the machine. + + + + + + + Power-off the machine (the + default). + + + + + + + Reboot the + machine. + + + + + + Equivalent to , + unless is specified. + + + + + + Do not halt, power-off, reboot, just write + wall message. + + + + + + Do not send wall + message before + halt, power-off, reboot. + + + + + + Cancel a pending shutdown. This may be used + cancel the effect of an invocation of + shutdown with a time argument that is not + +0 or + now. + + + + + + + Exit status + + On success, 0 is returned, a non-zero failure code + otherwise. + + + + See Also + + systemd1, + systemctl1, + halt8, + wall1 + + diff --git a/man/sysctl.d.xml b/man/sysctl.d.xml index c67a199fb51..5a35cfe2c84 100644 --- a/man/sysctl.d.xml +++ b/man/sysctl.d.xml @@ -19,158 +19,153 @@ along with systemd; If not, see . --> - - - sysctl.d - systemd - - - - Developer - Lennart - Poettering - lennart@poettering.net - - - - - - sysctl.d - 5 - - - - sysctl.d - Configure kernel parameters at boot - - - - /etc/sysctl.d/*.conf - /run/sysctl.d/*.conf - /usr/lib/sysctl.d/*.conf - - - - Description - - At boot, - systemd-sysctl.service8 - reads configuration files from the above directories - to configure - sysctl8 - kernel parameters. - - - - Configuration Format - - The configuration files contain a list of - variable assignments, separated by newlines. Empty - lines and lines whose first non-whitespace character - is # or ; are - ignored. - - Note that either / or - . may be used as separators within - sysctl variable names. If the first separator is a - slash, remaining slashes and dots are left intact. If - the first separator is a dot, dots and slashes are - interchanged. kernel.domainname=foo - and kernel/domainname=foo are - equivalent and will cause foo to - be written to - /proc/sys/kernel/domainname. - Either - net.ipv4.conf.enp3s0/200.forwarding - or - net/ipv4/conf/enp3s0.200/forwarding - may be used to refer to - /proc/sys/net/ipv4/conf/enp3s0.200/forwarding. - - - The settings configured with - sysctl.d files will be applied - early on boot. The network interface-specific options - will also be applied individually for each network - interface as it shows up in the system. (More - specifically, - net.ipv4.conf.*, - net.ipv6.conf.*, - net.ipv4.neigh.* and net.ipv6.neigh.*). - - Many sysctl parameters only become available - when certain kernel modules are loaded. Modules are - usually loaded on demand, e.g. when certain hardware - is plugged in or network brought up. This means that - systemd-sysctl.service8 which runs - during early boot will not configure such parameters - if they become available after it has run. To - set such parameters, it is recommended to add - an udev7 rule to set those parameters when they become - available. Alternatively, a slightly simpler and - less efficient option is to add the module to - modules-load.d5, causing it to be loaded statically - before sysctl settings are applied (see - example below). - - - - - - Examples - - Set kernel YP domain name - /etc/sysctl.d/domain-name.conf: - - - kernel.domainname=example.com - - - - Disable packet filter on bridged packets (method one) - /etc/udev/rules.d/99-bridge.rules: - - - ACTION=="add", SUBSYSTEM=="module", KERNEL=="bridge", RUN+="/usr/lib/systemd/systemd-sysctl --prefix=/net/bridge" + xmlns:xi="http://www.w3.org/2001/XInclude"> + + + sysctl.d + systemd + + + + Developer + Lennart + Poettering + lennart@poettering.net + + + + + + sysctl.d + 5 + + + + sysctl.d + Configure kernel parameters at boot + + + + /etc/sysctl.d/*.conf + /run/sysctl.d/*.conf + /usr/lib/sysctl.d/*.conf + + + + Description + + At boot, + systemd-sysctl.service8 + reads configuration files from the above directories to configure + sysctl8 + kernel parameters. + + + + Configuration Format + + The configuration files contain a list of variable + assignments, separated by newlines. Empty lines and lines whose + first non-whitespace character is # or + ; are ignored. + + Note that either / or + . may be used as separators within sysctl + variable names. If the first separator is a slash, remaining + slashes and dots are left intact. If the first separator is a dot, + dots and slashes are interchanged. + kernel.domainname=foo and + kernel/domainname=foo are equivalent and will + cause foo to be written to + /proc/sys/kernel/domainname. Either + net.ipv4.conf.enp3s0/200.forwarding or + net/ipv4/conf/enp3s0.200/forwarding may be used + to refer to + /proc/sys/net/ipv4/conf/enp3s0.200/forwarding. + + + The settings configured with sysctl.d + files will be applied early on boot. The network + interface-specific options will also be applied individually for + each network interface as it shows up in the system. (More + specifically, net.ipv4.conf.*, + net.ipv6.conf.*, + net.ipv4.neigh.* and + net.ipv6.neigh.*). + + Many sysctl parameters only become available when certain + kernel modules are loaded. Modules are usually loaded on demand, + e.g. when certain hardware is plugged in or network brought up. + This means that + systemd-sysctl.service8 + which runs during early boot will not configure such parameters if + they become available after it has run. To set such parameters, it + is recommended to add an + udev7 + rule to set those parameters when they become available. + Alternatively, a slightly simpler and less efficient option is to + add the module to + modules-load.d5, + causing it to be loaded statically before sysctl settings are + applied (see example below). + + + + + + Examples + + Set kernel YP domain name + /etc/sysctl.d/domain-name.conf: + + + kernel.domainname=example.com + + + + Disable packet filter on bridged packets (method one) + /etc/udev/rules.d/99-bridge.rules: + + + ACTION=="add", SUBSYSTEM=="module", KERNEL=="bridge", RUN+="/usr/lib/systemd/systemd-sysctl --prefix=/net/bridge" - /etc/sysctl.d/bridge.conf: - + /etc/sysctl.d/bridge.conf: + - net.bridge.bridge-nf-call-ip6tables = 0 + net.bridge.bridge-nf-call-ip6tables = 0 net.bridge.bridge-nf-call-iptables = 0 net.bridge.bridge-nf-call-arptables = 0 - + - - Disable packet filter on bridged packets (method two) - /etc/modules-load.d/bridge.conf: - + + Disable packet filter on bridged packets (method two) + /etc/modules-load.d/bridge.conf: + - bridge + bridge - /etc/sysctl.d/bridge.conf: - + /etc/sysctl.d/bridge.conf: + - net.bridge.bridge-nf-call-ip6tables = 0 + net.bridge.bridge-nf-call-ip6tables = 0 net.bridge.bridge-nf-call-iptables = 0 net.bridge.bridge-nf-call-arptables = 0 - - - - - See Also - - systemd1, - systemd-sysctl.service8, - systemd-delta1, - sysctl8, - sysctl.conf5, - modprobe8 - - + + + + + See Also + + systemd1, + systemd-sysctl.service8, + systemd-delta1, + sysctl8, + sysctl.conf5, + modprobe8 + + diff --git a/man/systemd-analyze.xml b/man/systemd-analyze.xml index ecfc7af2af4..61315a0d898 100644 --- a/man/systemd-analyze.xml +++ b/man/systemd-analyze.xml @@ -1,6 +1,6 @@ + "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd"> - - - systemd-analyze - systemd - - - - Developer - Lennart - Poettering - lennart@poettering.net - - - Developer - Harald - Hoyer - harald@redhat.com - - - - - - systemd-analyze - 1 - - - - systemd-analyze - Analyze system boot-up performance - - - - - systemd-analyze - OPTIONS - time - - - systemd-analyze - OPTIONS - blame - - - systemd-analyze - OPTIONS - critical-chain - UNIT - - - systemd-analyze - OPTIONS - plot - > file.svg - - - systemd-analyze - OPTIONS - dot - PATTERN - > file.dot - - - systemd-analyze - OPTIONS - dump - - - systemd-analyze - OPTIONS - set-log-level - LEVEL - - - systemd-analyze - OPTIONS - verify - FILES - - - - - Description - - systemd-analyze may be used - to determine system boot-up performance statistics and - retrieve other state and tracing information from the - system and service manager, and to verify the - correctness of unit files. - - systemd-analyze time - prints the time spent in the kernel before - userspace has been reached, the time spent in the - initial RAM disk (initrd) before normal system - userspace has been reached, and the time normal system - userspace took to initialize. Note that these - measurements simply measure the time passed up to the - point where all system services have been spawned, but - not necessarily until they fully finished - initialization or the disk is idle. - - systemd-analyze blame prints - a list of all running units, ordered by the time they - took to initialize. This information may be used to - optimize boot-up times. Note that the output might be - misleading as the initialization of one service might - be slow simply because it waits for the initialization - of another service to complete. - - systemd-analyze critical-chain [UNIT...] - prints a tree of the time-critical chain of units - (for each of the specified UNITs - or for the default target otherwise). - The time after the unit is active or started is printed - after the "@" character. The time the unit takes to - start is printed after the "+" character. - Note that the output might be misleading as the - initialization of one service might depend on socket - activation and because of the parallel execution - of units. - - systemd-analyze plot prints - an SVG graphic detailing which system services have - been started at what time, highlighting the time they - spent on initialization. - - systemd-analyze dot generates - textual dependency graph description in dot format for - further processing with the GraphViz - dot1 - tool. Use a command line like systemd-analyze - dot | dot -Tsvg > systemd.svg to generate a - graphical dependency tree. Unless - or - is passed, the generated graph will show both ordering - and requirement dependencies. Optional pattern - globbing style specifications - (e.g. *.target) may be given at - the end. A unit dependency is included in the graph if - any of these patterns match either the origin or - destination node. - - systemd-analyze dump outputs - a (usually very long) human-readable serialization of - the complete server state. Its format is subject to - change without notice and should not be parsed by - applications. - - systemd-analyze set-log-level - LEVEL changes the - current log level of the systemd - daemon to LEVEL (accepts - the same values as - described in - systemd1). - - systemd-analyze verify will - load unit files and print warnings if any errors are - detected. Files specified on the command line will be - loaded, but also any other units referenced by - them. This command works by prepending the directories - for all command line arguments at the beginning of the - unit load path, which means that all units files found - in those directories will be used in preference to the - unit files found in the standard locations, even if - not listed explicitly. - - If no command is passed, systemd-analyze - time is implied. - - - - - Options - - The following options are understood: - - - - - - Operates on the user - systemd instance. - - - - - - Operates on the system - systemd instance. This is the implied - default. - - - - - - - When used in - conjunction with the - dot command (see - above), selects which dependencies are - shown in the dependency graph. If - is passed, - only dependencies of type - After= or - Before= are - shown. If - is passed, only dependencies of type - Requires=, - RequiresOverridable=, - Requisite=, - RequisiteOverridable=, - Wants= and - Conflicts= are - shown. If neither is passed, this shows - dependencies of all these - types. - - - - - - - When used in - conjunction with the - dot command (see - above), this selects which relationships - are shown in the dependency graph. - They both require - glob7 - patterns as arguments, which are - matched against left-hand and - right-hand, respectively, nodes of a - relationship. Each of these can be - used more than once, which means a - unit name must match one of the given - values. - - - - timespan - - When used in conjunction - with the critical-chain - command (see above), also show units, which - finished timespan earlier, than the - latest unit in the same level. The unit of - timespan is seconds - unless specified with a different unit, - e.g. "50ms". - - - - - - Do not invoke man to verify the existence - of man pages listen in Documentation=. - - - - - - - - - - - - - - - Exit status - - On success, 0 is returned, a non-zero failure - code otherwise. - - - - Examples for <command>dot</command> - - - Plots all dependencies of any unit whose - name starts with <literal>avahi-daemon</literal> - - $ systemd-analyze dot 'avahi-daemon.*' | dot -Tsvg > avahi.svg - $ eog avahi.svg - - - - Plots the dependencies between all known target units - - systemd-analyze dot --to-pattern='*.target' --from-pattern='*.target' | dot -Tsvg > targets.svg + xmlns:xi="http://www.w3.org/2001/XInclude"> + + + systemd-analyze + systemd + + + + Developer + Lennart + Poettering + lennart@poettering.net + + + Developer + Harald + Hoyer + harald@redhat.com + + + + + + systemd-analyze + 1 + + + + systemd-analyze + Analyze system boot-up performance + + + + + systemd-analyze + OPTIONS + time + + + systemd-analyze + OPTIONS + blame + + + systemd-analyze + OPTIONS + critical-chain + UNIT + + + systemd-analyze + OPTIONS + plot + > file.svg + + + systemd-analyze + OPTIONS + dot + PATTERN + > file.dot + + + systemd-analyze + OPTIONS + dump + + + systemd-analyze + OPTIONS + set-log-level + LEVEL + + + systemd-analyze + OPTIONS + verify + FILES + + + + + Description + + systemd-analyze may be used to determine + system boot-up performance statistics and retrieve other state and + tracing information from the system and service manager, and to + verify the correctness of unit files. + + systemd-analyze time prints the time + spent in the kernel before userspace has been reached, the time + spent in the initial RAM disk (initrd) before normal system + userspace has been reached, and the time normal system userspace + took to initialize. Note that these measurements simply measure + the time passed up to the point where all system services have + been spawned, but not necessarily until they fully finished + initialization or the disk is idle. + + systemd-analyze blame prints a list of + all running units, ordered by the time they took to initialize. + This information may be used to optimize boot-up times. Note that + the output might be misleading as the initialization of one + service might be slow simply because it waits for the + initialization of another service to complete. + + systemd-analyze critical-chain + [UNIT...] prints a tree of + the time-critical chain of units (for each of the specified + UNITs or for the default target + otherwise). The time after the unit is active or started is + printed after the "@" character. The time the unit takes to start + is printed after the "+" character. Note that the output might be + misleading as the initialization of one service might depend on + socket activation and because of the parallel execution of + units. + + systemd-analyze plot prints an SVG + graphic detailing which system services have been started at what + time, highlighting the time they spent on initialization. + + systemd-analyze dot generates textual + dependency graph description in dot format for further processing + with the GraphViz + dot1 + tool. Use a command line like systemd-analyze dot | dot + -Tsvg > systemd.svg to generate a graphical dependency + tree. Unless or + is passed, the generated graph will + show both ordering and requirement dependencies. Optional pattern + globbing style specifications (e.g. *.target) + may be given at the end. A unit dependency is included in the + graph if any of these patterns match either the origin or + destination node. + + systemd-analyze dump outputs a (usually + very long) human-readable serialization of the complete server + state. Its format is subject to change without notice and should + not be parsed by applications. + + systemd-analyze set-log-level + LEVEL changes the current log + level of the systemd daemon to + LEVEL (accepts the same values as + described in + systemd1). + + systemd-analyze verify will load unit + files and print warnings if any errors are detected. Files + specified on the command line will be loaded, but also any other + units referenced by them. This command works by prepending the + directories for all command line arguments at the beginning of the + unit load path, which means that all units files found in those + directories will be used in preference to the unit files found in + the standard locations, even if not listed explicitly. + + If no command is passed, systemd-analyze + time is implied. + + + + + Options + + The following options are understood: + + + + + + Operates on the user systemd + instance. + + + + + + Operates on the system systemd instance. This + is the implied default. + + + + + + + When used in conjunction with the + dot command (see above), selects which + dependencies are shown in the dependency graph. If + is passed, only dependencies of type + After= or Before= are + shown. If is passed, only + dependencies of type Requires=, + RequiresOverridable=, + Requisite=, + RequisiteOverridable=, + Wants= and Conflicts= + are shown. If neither is passed, this shows dependencies of + all these types. + + + + + + + When used in conjunction with the + dot command (see above), this selects which + relationships are shown in the dependency graph. They both + require + glob7 + patterns as arguments, which are matched against left-hand and + right-hand, respectively, nodes of a relationship. Each of + these can be used more than once, which means a unit name must + match one of the given values. + + + + timespan + + When used in conjunction with the + critical-chain command (see above), also + show units, which finished timespan + earlier, than the latest unit in the same level. The unit of + timespan is seconds unless + specified with a different unit, e.g. + "50ms". + + + + + + Do not invoke man to verify the existence of + man pages listen in Documentation=. + + + + + + + + + + + + + + + Exit status + + On success, 0 is returned, a non-zero failure code + otherwise. + + + + Examples for <command>dot</command> + + + Plots all dependencies of any unit whose name starts with + <literal>avahi-daemon</literal> + + $ systemd-analyze dot 'avahi-daemon.*' | dot -Tsvg > avahi.svg + $ eog avahi.svg + + + + Plots the dependencies between all known target units + + systemd-analyze dot --to-pattern='*.target' --from-pattern='*.target' | dot -Tsvg > targets.svg $ eog targets.svg - - + + - - Examples for <command>verify</command> + + Examples for <command>verify</command> - The following errors are currently detected: - - unknown sections and - directives, + The following errors are currently detected: + + unknown sections and directives, + - missing dependencies which are - required to start the given unit, - + missing dependencies which are required to start + the given unit, - man pages listed in - Documentation= which are - not found in the system, + man pages listed in + Documentation= which are not found in the + system, - commands listed in - ExecStart= and similar - which are not found in the system or not - executable. - + commands listed in ExecStart= + and similar which are not found in the system or not + executable. + - - Misspelt directives + + Misspelt directives - $ cat ./user.slice + $ cat ./user.slice [Unit] WhatIsThis=11 Documentation=man:nosuchfile(1) @@ -356,17 +328,17 @@ $ systemd-analyze verify ./user.slice [./user.slice:9] Unknown lvalue 'WhatIsThis' in section 'Unit' [./user.slice:13] Unknown section 'Service'. Ignoring. Error: org.freedesktop.systemd1.LoadFailed: - Unit different.service failed to load: - No such file or directory. + Unit different.service failed to load: + No such file or directory. Failed to create user.slice/start: Invalid argument user.slice: man nosuchfile(1) command failed with code 16 - - + + - - Missing service units + + Missing service units - $ tail ./a.socket ./b.socket + $ tail ./a.socket ./b.socket ==> ./a.socket <== [Socket] ListenStream=100 @@ -379,18 +351,18 @@ Accept=yes $ systemd-analyze verify ./a.socket ./b.socket Service a.service not loaded, a.socket cannot be started. Service b@0.service not loaded, b.socket cannot be started. - - - - - - - - See Also - - systemd1, - systemctl1 - - + + + + + + + + See Also + + systemd1, + systemctl1 + + diff --git a/man/systemd-ask-password-console.service.xml b/man/systemd-ask-password-console.service.xml index 536dad9c67d..479e5f2e5b3 100644 --- a/man/systemd-ask-password-console.service.xml +++ b/man/systemd-ask-password-console.service.xml @@ -21,76 +21,73 @@ --> - - systemd-ask-password-console.service - systemd + + systemd-ask-password-console.service + systemd - - - Developer - Lennart - Poettering - lennart@poettering.net - - - + + + Developer + Lennart + Poettering + lennart@poettering.net + + + - - systemd-ask-password-console.service - 8 - + + systemd-ask-password-console.service + 8 + - - systemd-ask-password-console.service - systemd-ask-password-console.path - systemd-ask-password-wall.service - systemd-ask-password-wall.path - Query the user for system passwords on the - console and via wall - + + systemd-ask-password-console.service + systemd-ask-password-console.path + systemd-ask-password-wall.service + systemd-ask-password-wall.path + Query the user for system passwords on the + console and via wall + - - systemd-ask-password-console.service - systemd-ask-password-console.path - systemd-ask-password-wall.service - systemd-ask-password-wall.path - + + systemd-ask-password-console.service + systemd-ask-password-console.path + systemd-ask-password-wall.service + systemd-ask-password-wall.path + - - Description + + Description - systemd-ask-password-console.service - is a system service that queries the user for system - passwords (such as hard disk encryption keys and SSL - certificate passphrases) on the console. It is - intended to be used during boot to ensure proper - handling of passwords necessary for - boot. systemd-ask-password-wall.service - is a system service that informs all logged in users - for system passwords via - wall1. It - is intended to be used after boot to ensure that users - are properly notified. + systemd-ask-password-console.service is + a system service that queries the user for system passwords (such + as hard disk encryption keys and SSL certificate passphrases) on + the console. It is intended to be used during boot to ensure + proper handling of passwords necessary for boot. + systemd-ask-password-wall.service is a system + service that informs all logged in users for system passwords via + wall1. + It is intended to be used after boot to ensure that users are + properly notified. - See the - developer documentation for more information - about the system password logic. + See the + developer documentation for more information about the + system password logic. - Note that these services invoke - systemd-tty-ask-password-agent1 - with either the --watch --console - or --watch --wall command line - parameters. - + Note that these services invoke + systemd-tty-ask-password-agent1 + with either the --watch --console or + --watch --wall command line parameters. + - - See Also - - systemd1, - systemd-tty-ask-password-agent1, - wall1 - - + + See Also + + systemd1, + systemd-tty-ask-password-agent1, + wall1 + + diff --git a/man/systemd-ask-password.xml b/man/systemd-ask-password.xml index 448df621005..877c71af539 100644 --- a/man/systemd-ask-password.xml +++ b/man/systemd-ask-password.xml @@ -1,6 +1,6 @@ + "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd"> - - - systemd-ask-password - systemd - - - - Developer - Lennart - Poettering - lennart@poettering.net - - - - - - systemd-ask-password - 1 - - - - systemd-ask-password - Query the user for a system password - - - - - systemd-ask-password OPTIONS MESSAGE - - - - - Description - - systemd-ask-password may be - used to query a system password or passphrase from the - user, using a question message specified on the - command line. When run from a TTY it will query a - password on the TTY and print it to standard output. When run - with no TTY or with it will - query the password system-wide and allow active users - to respond via several agents. The latter is - only available to privileged processes. - - The purpose of this tool is to query system-wide - passwords -- that is passwords not attached to a - specific user account. Examples include: unlocking - encrypted hard disks when they are plugged in or at - boot, entering an SSL certificate passphrase for web - and VPN servers. - - Existing agents are: a boot-time password agent - asking the user for passwords using Plymouth; a - boot-time password agent querying the user directly on - the console; an agent requesting password input via a - wall1 - message; an agent suitable for running in a GNOME - session; a command line agent which can be started - temporarily to process queued password requests; a TTY - agent that is temporarily spawned during - systemctl1 - invocations. - - Additional password agents may be implemented - according to the systemd - Password Agent Specification. - - If a password is queried on a TTY, the user may - press TAB to hide the asterisks normally shown for - each character typed. Pressing Backspace as first key - achieves the same effect. - - - - - Options - - The following options are understood: - - - - - - Specify an icon name - alongside the password query, which may - be used in all agents supporting - graphical display. The icon name - should follow the XDG - Icon Naming - Specification. - - - - - - Specify the query - timeout in seconds. Defaults to - 90s. A timeout of 0 waits indefinitely. - - - - - - - Echo the user input - instead of masking it. This is useful - when using - systemd-ask-password - to query for usernames. - - - - - - - Never ask for password - on current TTY even if one is - available. Always use agent - system. - - - - - - If passed, accept - cached passwords, i.e. passwords - previously typed in. - - - - - - When used in - conjunction with - - accept multiple passwords. This will - output one password per - line. - - - - - - - - - Exit status - - On success, 0 is returned, a non-zero failure - code otherwise. - - - - See Also - - systemd1, - systemctl1, - plymouth8, - wall1 - - + xmlns:xi="http://www.w3.org/2001/XInclude"> + + + systemd-ask-password + systemd + + + + Developer + Lennart + Poettering + lennart@poettering.net + + + + + + systemd-ask-password + 1 + + + + systemd-ask-password + Query the user for a system password + + + + + systemd-ask-password OPTIONS MESSAGE + + + + + Description + + systemd-ask-password may be used to query + a system password or passphrase from the user, using a question + message specified on the command line. When run from a TTY it will + query a password on the TTY and print it to standard output. When + run with no TTY or with it will query + the password system-wide and allow active users to respond via + several agents. The latter is only available to privileged + processes. + + The purpose of this tool is to query system-wide passwords + -- that is passwords not attached to a specific user account. + Examples include: unlocking encrypted hard disks when they are + plugged in or at boot, entering an SSL certificate passphrase for + web and VPN servers. + + Existing agents are: a boot-time password agent asking the + user for passwords using Plymouth; a boot-time password agent + querying the user directly on the console; an agent requesting + password input via a + wall1 + message; an agent suitable for running in a GNOME session; a + command line agent which can be started temporarily to process + queued password requests; a TTY agent that is temporarily spawned + during + systemctl1 + invocations. + + Additional password agents may be implemented according to + the systemd + Password Agent Specification. + + If a password is queried on a TTY, the user may press TAB to + hide the asterisks normally shown for each character typed. + Pressing Backspace as first key achieves the same effect. + + + + + Options + + The following options are understood: + + + + + + Specify an icon name alongside the password + query, which may be used in all agents supporting graphical + display. The icon name should follow the XDG + Icon Naming Specification. + + + + + + Specify the query timeout in seconds. Defaults + to 90s. A timeout of 0 waits indefinitely. + + + + + + Echo the user input instead of masking it. + This is useful when using + systemd-ask-password to query for + usernames. + + + + + + Never ask for password on current TTY even if + one is available. Always use agent system. + + + + + + If passed, accept cached passwords, i.e. + passwords previously typed in. + + + + + + When used in conjunction with + accept multiple passwords. + This will output one password per line. + + + + + + + + + Exit status + + On success, 0 is returned, a non-zero failure code + otherwise. + + + + See Also + + systemd1, + systemctl1, + plymouth8, + wall1 + + diff --git a/man/systemd-backlight@.service.xml b/man/systemd-backlight@.service.xml index 21c6437efab..a259f5d583c 100644 --- a/man/systemd-backlight@.service.xml +++ b/man/systemd-backlight@.service.xml @@ -21,79 +21,74 @@ --> - - systemd-backlight@.service - systemd - - - - Developer - Lennart - Poettering - lennart@poettering.net - - - - - - systemd-backlight@.service - 8 - - - - systemd-backlight@.service - systemd-backlight - Load and save the display backlight brightness at boot and shutdown - - - - systemd-backlight@.service - /usr/lib/systemd/systemd-backlight - - - - Description - - systemd-backlight@.service - is a service that restores the display backlight - brightness at early boot and saves it at shutdown. On - disk, the backlight brightness is stored in - /var/lib/systemd/backlight/. During - loading, if udev property - is not set to - false value, the brightness is clamped to a value of - at least 1 or 5% of maximum brightness, whichever is - greater. This restriction will be removed when the - kernel allows user space to reliably set a brightness - value which does not turn off the display. - - - - Kernel Command Line - - systemd-backlight understands - the following kernel command line parameter: - - - - systemd.restore_state= - - Takes a boolean - argument. Defaults to - 1. If - 0, does not restore - the backlight settings on boot. However, - settings will still be stored on shutdown. - - - - - - - See Also - - systemd1 - - + + systemd-backlight@.service + systemd + + + + Developer + Lennart + Poettering + lennart@poettering.net + + + + + + systemd-backlight@.service + 8 + + + + systemd-backlight@.service + systemd-backlight + Load and save the display backlight brightness at boot and shutdown + + + + systemd-backlight@.service + /usr/lib/systemd/systemd-backlight + + + + Description + + systemd-backlight@.service is a service + that restores the display backlight brightness at early boot and + saves it at shutdown. On disk, the backlight brightness is stored + in /var/lib/systemd/backlight/. During + loading, if udev property is + not set to false value, the brightness is clamped to a value of at + least 1 or 5% of maximum brightness, whichever is greater. This + restriction will be removed when the kernel allows user space to + reliably set a brightness value which does not turn off the + display. + + + + Kernel Command Line + + systemd-backlight understands the + following kernel command line parameter: + + + + systemd.restore_state= + + Takes a boolean argument. Defaults to + 1. If 0, does not + restore the backlight settings on boot. However, settings will + still be stored on shutdown. + + + + + + See Also + + systemd1 + + diff --git a/man/systemd-binfmt.service.xml b/man/systemd-binfmt.service.xml index cb96048369e..66d264389e7 100644 --- a/man/systemd-binfmt.service.xml +++ b/man/systemd-binfmt.service.xml @@ -21,56 +21,55 @@ --> - - systemd-binfmt.service - systemd + + systemd-binfmt.service + systemd - - - Developer - Lennart - Poettering - lennart@poettering.net - - - + + + Developer + Lennart + Poettering + lennart@poettering.net + + + - - systemd-binfmt.service - 8 - + + systemd-binfmt.service + 8 + - - systemd-binfmt.service - systemd-binfmt - Configure additional binary formats for executables at boot - + + systemd-binfmt.service + systemd-binfmt + Configure additional binary formats for executables at boot + - - systemd-binfmt.service - /usr/lib/systemd/systemd-binfmt - + + systemd-binfmt.service + /usr/lib/systemd/systemd-binfmt + - - Description + + Description - systemd-binfmt.service is - an early-boot service that registers additional binary - formats for executables in the kernel. + systemd-binfmt.service is an early-boot + service that registers additional binary formats for executables + in the kernel. - See - binfmt.d5 - for information about the configuration of this - service. - + See + binfmt.d5 + for information about the configuration of this service. + - - See Also - - systemd1, - binfmt.d5, - wine8 - - + + See Also + + systemd1, + binfmt.d5, + wine8 + + diff --git a/man/systemd-bootchart.xml b/man/systemd-bootchart.xml index ff86be2ad8b..ab883c262dd 100644 --- a/man/systemd-bootchart.xml +++ b/man/systemd-bootchart.xml @@ -1,7 +1,7 @@ + "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd"> - - - systemd-bootchart - systemd - - - - Developer - Auke - Kok - auke-jan.h.kok@intel.com - - - - - - systemd-bootchart - 1 - - - - systemd-bootchart - Boot performance graphing tool - - - - Description - - systemd-bootchart is a - tool, usually run at system startup, that - collects the CPU load, disk load, memory - usage, as well as per-process information from - a running system. Collected results are output - as an SVG graph. Normally, systemd-bootchart - is invoked by the kernel by passing - - on the kernel command line. systemd-bootchart will then - fork the real init off to resume normal system - startup, while monitoring and logging startup - information in the background. - - - After collecting a certain amount of data - (usually 15-30 seconds, default 20 s) the - logging stops and a graph is generated from - the logged information. This graph contains - vital clues as to which resources are being used, - in which order, and where possible problems - exist in the startup sequence of the system. - It is essentially a more detailed version of - the systemd-analyze plot - function. - - - Of course, bootchart can also be used at any - moment in time to collect and graph some data - for an amount of time. It is - recommended to use the - switch in this case. - - - Bootchart does not require root privileges, - and will happily run as a normal user. - - - Bootchart graphs are by default written - time-stamped in /run/log - and saved to the journal with - MESSAGE_ID=9f26aa562cf440c2b16c773d0479b518. - Journal field BOOTCHART= contains - the bootchart in SVG format. - - - - - - Invocation - - systemd-bootchart can be invoked in several different ways: - - - - - Kernel invocation - The kernel can invoke - systemd-bootchart - instead of the init process. In turn, - systemd-bootchart - will invoke /usr/lib/systemd/systemd. - - - - - Started as a standalone program - One can execute - systemd-bootchart - as normal application from the - command line. In this mode it is highly - recommended to pass the - flag in order to - not graph the time elapsed since boot - and before systemd-bootchart was - started, as it may result in extremely - large graphs. The time elapsed since boot - might also include any time that the system - was suspended. - - - - - - Options - - These options can also be set in the - /etc/systemd/bootchart.conf - file. See - bootchart.conf5. - - - - - - - - - Specify the number of - samples, N, - to record. Samples will be recorded at - intervals defined with . - - - - - - - Specify the sample log - frequency, a positive real f, in Hz. - Most systems can cope with values up to 25-50 without - creating too much overhead. - - - - - - Use relative times instead of absolute - times. This is useful for using bootchart at post-boot - time to profile an already booted system. Without this - option the graph would become extremely large. If set, the - horizontal axis starts at the first recorded sample - instead of time 0.0. - - - - - - Disable filtering of tasks that - did not contribute significantly to the boot. Processes - that are too short-lived (only seen in one sample) or - that do not consume any significant CPU time (less than - 0.001 s) will not be displayed in the output graph. - - - - - - - Display the full command line with arguments of processes, - instead of only the process name. - - - - - - - Display process control group - - - - - - - Specify the output directory for the - graphs. By default, bootchart writes the graphs to - /run/log. - - - - - - Use this init binary. Defaults to - /usr/lib/systemd/systemd. - - - - - - - Enable logging and graphing - of processes' PSS (Proportional Set Size) - memory consumption. See filesystems/proc.txt - in the kernel documentation for an - explanation of this field. - - - - - - - Enable logging and graphing - of the kernel random entropy pool size. - - - - - - Horizontal scaling factor for all variable - graph components. - - - - - - Vertical scaling factor for all variable - graph components. - - - - - - - - - Output - - systemd-bootchart generates SVG graphs. In order to render those - on a graphical display any SVG capable viewer can be used. It should be - noted that the SVG render engines in most browsers (including Chrome - and Firefox) are many times faster than dedicated graphical applications - like Gimp and Inkscape. Just point your browser at ! - - - - - History - - This version of bootchart was implemented from - scratch, but is inspired by former bootchart - incantations: - - - - Original bash - The original bash/shell code implemented - bootchart. This version created a compressed tarball for - processing with external applications. This version did - not graph anything, only generated data. - - - - Ubuntu C Implementation - This version replaced the shell version with - a fast and efficient data logger, but also did not graph - the data. - - - - Java bootchart - This was the original graphing application - for charting the data, written in java. - - - - pybootchartgui.py - pybootchart created a graph from the data - collected by either the bash or C version. - - - - The version of bootchart you are using now combines both the data - collection and the charting into a single application, making it more - efficient and simpler. There are no longer any timing issues with the data - collector and the grapher, as the graphing cannot be run until the data - has been collected. Also, the data kept in memory is reduced to the absolute - minimum needed. - - - - - See Also - - bootchart.conf5 - - - - - Bugs - systemd-bootchart does not get the model information for the hard drive - unless the root device is specified with root=/dev/sdxY. Using - UUIDs or PARTUUIDs will boot fine, but the hard drive model will not be - added to the chart. - For bugs, please contact the author and current maintainer: - - Auke Kok auke-jan.h.kok@intel.com - - + xmlns:xi="http://www.w3.org/2001/XInclude"> + + + systemd-bootchart + systemd + + + + Developer + Auke + Kok + auke-jan.h.kok@intel.com + + + + + + systemd-bootchart + 1 + + + + systemd-bootchart + Boot performance graphing tool + + + + Description + + systemd-bootchart is a tool, usually run at + system startup, that collects the CPU load, disk load, memory + usage, as well as per-process information from a running system. + Collected results are output as an SVG graph. Normally, + systemd-bootchart is invoked by the kernel by passing + + on the kernel command line. systemd-bootchart will then fork the + real init off to resume normal system startup, while monitoring + and logging startup information in the background. + + + After collecting a certain amount of data (usually 15-30 + seconds, default 20 s) the logging stops and a graph is + generated from the logged information. This graph contains vital + clues as to which resources are being used, in which order, and + where possible problems exist in the startup sequence of the + system. It is essentially a more detailed version of the + systemd-analyze plot function. + + + Of course, bootchart can also be used at any moment in time to + collect and graph some data for an amount of time. It is + recommended to use the switch in this + case. + + + Bootchart does not require root privileges, and will happily run + as a normal user. + + + Bootchart graphs are by default written time-stamped in + /run/log and saved to the journal with + MESSAGE_ID=9f26aa562cf440c2b16c773d0479b518. + Journal field BOOTCHART= contains the + bootchart in SVG format. + + + + + + Invocation + + systemd-bootchart can be invoked in several different ways: + + + + + Kernel invocation + The kernel can invoke + systemd-bootchart instead of the init + process. In turn, systemd-bootchart will + invoke /usr/lib/systemd/systemd. + + + + + Started as a standalone program + One can execute + systemd-bootchart as normal application + from the command line. In this mode it is highly recommended + to pass the flag in order to not graph the + time elapsed since boot and before systemd-bootchart was + started, as it may result in extremely large graphs. The time + elapsed since boot might also include any time that the system + was suspended. + + + + + + Options + + These options can also be set in the + /etc/systemd/bootchart.conf file. See + bootchart.conf5. + + + + + + + + + Specify the number of samples, + N, to record. Samples will be + recorded at intervals defined with . + + + + + + + Specify the sample log frequency, a positive + real f, in Hz. Most systems can + cope with values up to 25-50 without creating too much + overhead. + + + + + + Use relative times instead of absolute times. + This is useful for using bootchart at post-boot time to + profile an already booted system. Without this option the + graph would become extremely large. If set, the horizontal + axis starts at the first recorded sample instead of time + 0.0. + + + + + + Disable filtering of tasks that did not + contribute significantly to the boot. Processes that are too + short-lived (only seen in one sample) or that do not consume + any significant CPU time (less than 0.001 s) will not be + displayed in the output graph. + + + + + + Display the full command line with arguments + of processes, instead of only the process name. + + + + + + + Display process control group + + + + + + + Specify the output directory for the graphs. + By default, bootchart writes the graphs to + /run/log. + + + + + + Use this init binary. Defaults to + /usr/lib/systemd/systemd. + + + + + + + Enable logging and graphing of processes' PSS + (Proportional Set Size) memory consumption. See + filesystems/proc.txt in the kernel + documentation for an explanation of this field. + + + + + + + Enable logging and graphing of the kernel + random entropy pool size. + + + + + + Horizontal scaling factor for all variable + graph components. + + + + + + Vertical scaling factor for all variable graph + components. + + + + + + + + + Output + + systemd-bootchart generates SVG graphs. + In order to render those on a graphical display any SVG capable + viewer can be used. It should be noted that the SVG render engines + in most browsers (including Chrome and Firefox) are many times + faster than dedicated graphical applications like Gimp and + Inkscape. Just point your browser at + ! + + + + + History + + This version of bootchart was implemented from scratch, but + is inspired by former bootchart incantations: + + + + Original bash + The original bash/shell code implemented + bootchart. This version created a compressed tarball for + processing with external applications. This version did not + graph anything, only generated data. + + + + Ubuntu C Implementation + This version replaced the shell version with a + fast and efficient data logger, but also did not graph the + data. + + + + Java bootchart + This was the original graphing application for + charting the data, written in java. + + + + pybootchartgui.py + pybootchart created a graph from the data + collected by either the bash or C version. + + + + The version of bootchart you are using now combines both the + data collection and the charting into a single application, making + it more efficient and simpler. There are no longer any timing + issues with the data collector and the grapher, as the graphing + cannot be run until the data has been collected. Also, the data + kept in memory is reduced to the absolute minimum needed. + + + + + See Also + + + bootchart.conf5 + + + + + Bugs + + systemd-bootchart does not get the model information for the + hard drive unless the root device is specified with + root=/dev/sdxY. Using UUIDs or PARTUUIDs will boot + fine, but the hard drive model will not be added to the + chart. + For bugs, please contact the author and current maintainer: + + Auke Kok auke-jan.h.kok@intel.com + + diff --git a/man/systemd-cat.xml b/man/systemd-cat.xml index e5a867be226..38ddf66d272 100644 --- a/man/systemd-cat.xml +++ b/man/systemd-cat.xml @@ -1,6 +1,6 @@ + "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd"> - - - systemd-cat - systemd - - - - Developer - Lennart - Poettering - lennart@poettering.net - - - - - - systemd-cat - 1 - - - - systemd-cat - Connect a pipeline or program's output with the journal - - - - - systemd-cat OPTIONS COMMAND ARGUMENTS - - - systemd-cat OPTIONS - - - - - Description - - systemd-cat may be used to - connect the standard input and output of a process to the - journal, or as a filter tool in a shell pipeline to - pass the output the previous pipeline element - generates to the journal. - - If no parameter is passed, - systemd-cat will write - everything it reads from standard input (stdin) to the journal. - - If parameters are passed, they are executed as - command line with standard output (stdout) and standard - error output (stderr) connected to the journal, so - that all it writes is stored in the journal. - - - - Options - - The following options are understood: - - - - - - - - - - Specify a short string - that is used to identify the logging - tool. If not specified, no identification - string is written to the journal. - - - - - - - Specify the default - priority level for the logged - messages. Pass one of - emerg, - alert, - crit, - err, - warning, - notice, - info, - debug, or a - value between 0 and 7 (corresponding - to the same named levels). These - priority values are the same as - defined by - syslog3. Defaults - to info. Note that - this simply controls the default, - individual lines may be logged with - different levels if they are prefixed - accordingly. For details see - - below. - - - - - - Controls whether lines - read are parsed for syslog priority - level prefixes. If enabled (the - default), a line prefixed with a - priority prefix such as - <5> is logged - at priority 5 - (notice), and - similar for the other priority - levels. Takes a boolean - argument. - - - - - - - - Exit status - - On success, 0 is returned, a non-zero failure - code otherwise. - - - - Examples - - - Invoke a program - - This calls /bin/ls - with standard output and error connected to the - journal: - - # systemd-cat ls - - - - Usage in a shell pipeline - - This builds a shell pipeline also - invoking /bin/ls and - writes the output it generates to the - journal: - - # ls | systemd-cat - - - Even though the two examples have very similar - effects the first is preferable since only one process - is running at a time, and both stdout and stderr are - captured while in the second example, only stdout is - captured. - - - - See Also - - systemd1, - systemctl1, - logger1 - - + xmlns:xi="http://www.w3.org/2001/XInclude"> + + + systemd-cat + systemd + + + + Developer + Lennart + Poettering + lennart@poettering.net + + + + + + systemd-cat + 1 + + + + systemd-cat + Connect a pipeline or program's output with the journal + + + + + systemd-cat OPTIONS COMMAND ARGUMENTS + + + systemd-cat OPTIONS + + + + + Description + + systemd-cat may be used to connect the + standard input and output of a process to the journal, or as a + filter tool in a shell pipeline to pass the output the previous + pipeline element generates to the journal. + + If no parameter is passed, systemd-cat + will write everything it reads from standard input (stdin) to the + journal. + + If parameters are passed, they are executed as command line + with standard output (stdout) and standard error output (stderr) + connected to the journal, so that all it writes is stored in the + journal. + + + + Options + + The following options are understood: + + + + + + + + + + Specify a short string that is used to + identify the logging tool. If not specified, no identification + string is written to the journal. + + + + + + + Specify the default priority level for the + logged messages. Pass one of + emerg, + alert, + crit, + err, + warning, + notice, + info, + debug, or a + value between 0 and 7 (corresponding to the same named + levels). These priority values are the same as defined by + syslog3. + Defaults to info. Note that this simply + controls the default, individual lines may be logged with + different levels if they are prefixed accordingly. For details + see below. + + + + + + Controls whether lines read are parsed for + syslog priority level prefixes. If enabled (the default), a + line prefixed with a priority prefix such as + <5> is logged at priority 5 + (notice), and similar for the other + priority levels. Takes a boolean argument. + + + + + + + + Exit status + + On success, 0 is returned, a non-zero failure code + otherwise. + + + + Examples + + + Invoke a program + + This calls /bin/ls + with standard output and error connected to the journal: + + # systemd-cat ls + + + + Usage in a shell pipeline + + This builds a shell pipeline also invoking + /bin/ls and writes the output it generates + to the journal: + + # ls | systemd-cat + + + Even though the two examples have very similar effects the + first is preferable since only one process is running at a time, + and both stdout and stderr are captured while in the second + example, only stdout is captured. + + + + See Also + + systemd1, + systemctl1, + logger1 + + diff --git a/man/systemd-cgls.xml b/man/systemd-cgls.xml index d8dbe6862e7..e8f0368f48d 100644 --- a/man/systemd-cgls.xml +++ b/man/systemd-cgls.xml @@ -1,6 +1,6 @@ + "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd"> - - - systemd-cgls - systemd - - - - Developer - Lennart - Poettering - lennart@poettering.net - - - - - - systemd-cgls - 1 - - - - systemd-cgls - Recursively show control group contents - - - - - systemd-cgls - OPTIONS - CGROUP - - - - - Description - - systemd-cgls recursively - shows the contents of the selected Linux control group - hierarchy in a tree. If arguments are specified, shows - all member processes of the specified control groups - plus all their subgroups and their members. The - control groups may either be specified by their full - file paths or are assumed in the systemd control group - hierarchy. If no argument is specified and the current - working directory is beneath the control group mount - point /sys/fs/cgroup, shows the contents - of the control group the working directory refers - to. Otherwise, the full systemd control group hierarchy - is shown. - - By default, empty control groups are not - shown. - - - - Options - - The following options are understood: - - - - - - Do not hide empty - control groups in the - output. - - - - - - - Do not ellipsize - process tree members. - - - - - - - Include kernel - threads in output. - - - - - - - Limit control groups shown to - the part corresponding to the - container MACHINE. - - - - - - - - - - - - Exit status - - On success, 0 is returned, a non-zero failure - code otherwise. - - - - See Also - - systemd1, - systemctl1, - systemd-cgtop1, - systemd-nspawn1, - ps1 - - + xmlns:xi="http://www.w3.org/2001/XInclude"> + + + systemd-cgls + systemd + + + + Developer + Lennart + Poettering + lennart@poettering.net + + + + + + systemd-cgls + 1 + + + + systemd-cgls + Recursively show control group contents + + + + + systemd-cgls + OPTIONS + CGROUP + + + + + Description + + systemd-cgls recursively shows the + contents of the selected Linux control group hierarchy in a tree. + If arguments are specified, shows all member processes of the + specified control groups plus all their subgroups and their + members. The control groups may either be specified by their full + file paths or are assumed in the systemd control group hierarchy. + If no argument is specified and the current working directory is + beneath the control group mount point + /sys/fs/cgroup, shows the contents of the + control group the working directory refers to. Otherwise, the full + systemd control group hierarchy is shown. + + By default, empty control groups are not shown. + + + + Options + + The following options are understood: + + + + + + Do not hide empty control groups in the + output. + + + + + + + Do not ellipsize process tree members. + + + + + + + Include kernel threads in output. + + + + + + + + Limit control groups shown to the part + corresponding to the container + MACHINE. + + + + + + + + + + + Exit status + + On success, 0 is returned, a non-zero failure code + otherwise. + + + + See Also + + systemd1, + systemctl1, + systemd-cgtop1, + systemd-nspawn1, + ps1 + + diff --git a/man/systemd-cgtop.xml b/man/systemd-cgtop.xml index 8ee552a012a..f1ff218c391 100644 --- a/man/systemd-cgtop.xml +++ b/man/systemd-cgtop.xml @@ -1,6 +1,6 @@ + "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd"> - - - systemd-cgtop - systemd - - - - Developer - Lennart - Poettering - lennart@poettering.net - - - - - - systemd-cgtop - 1 - - - - systemd-cgtop - Show top control groups by their resource usage - - - - - systemd-cgtop - OPTIONS - - - - - Description - - systemd-cgtop shows the top - control groups of the local Linux control group - hierarchy, ordered by their CPU, memory, or disk I/O load. The - display is refreshed in regular intervals (by default - every 1s), similar in style to - top1. - If systemd-cgtop is not connected - to a tty, only one iteration is performed and no - columns headers are printed. This mode is suitable for - scripting. - - Resource usage is only accounted for control - groups in the relevant hierarchy, i.e. CPU usage is - only accounted for control groups in the - cpuacct hierarchy, memory usage - only for those in memory and disk - I/O usage for those in blkio. If - resource monitoring for these resources is required, - it is recommended to add the - CPUAccounting=1, - MemoryAccounting=1 and - BlockIOAccounting=1 settings in the - unit files in question. See - systemd.resource-control5 - for details. - - To emphasize this: unless - CPUAccounting=1, - MemoryAccounting=1 and - BlockIOAccounting=1 are enabled for - the services in question, no resource accounting will - be available for system services and the data shown by - systemd-cgtop will be - incomplete. - - - - Options - - The following options are understood: - - - - - - Order by control group - path name. - - - - - - Order by number of - tasks in control - group (i.e. threads and processes). - - - - - - Order by CPU load. - - - - - - Order by memory usage. - - - - - - Order by disk I/O load. - - - - - - - Run in "batch" mode: - do not accept input and run until the - iteration limit set with - is - exhausted or until killed. This mode - could be useful for sending output - from systemd-cgtop - to other programs or to a - file. - - - - - - - Perform only this many - iterations. - - - - - - - Specify refresh delay - in seconds (or if one of - ms, - us, - min is specified as - unit in this time - unit). - - - - - - Maximum control group - tree traversal depth. Specifies how - deep systemd-cgtop - shall traverse the control group - hierarchies. If 0 is specified, only - the root group is monitored. For 1, - only the first level of control groups - is monitored, and so on. Defaults to - 3. - - - - - - - - - - - Keys - - systemd-cgtop is an - interactive tool and may be controlled via user input - using the following keys: - - - - h - - Shows a short help text. - - - - SPACE - - Immediately refresh output. - - - - q - - Terminate the program. - - - - - p - t - c - m - i - - Sort the control groups - by path, number of tasks, CPU load, - memory usage, or IO - load, respectively. - - - - % - - Toggle between showing CPU time as - time or percentage. - - - - + - - - - Increase - or decrease refresh - delay, respectively. - - - - - - - Exit status - - On success, 0 is returned, a non-zero failure - code otherwise. - - - - See Also - - systemd1, - systemctl1, - systemd-cgls1, - systemd.resource-control5, - top1 - - + xmlns:xi="http://www.w3.org/2001/XInclude"> + + + systemd-cgtop + systemd + + + + Developer + Lennart + Poettering + lennart@poettering.net + + + + + + systemd-cgtop + 1 + + + + systemd-cgtop + Show top control groups by their resource usage + + + + + systemd-cgtop + OPTIONS + + + + + Description + + systemd-cgtop shows the top control + groups of the local Linux control group hierarchy, ordered by + their CPU, memory, or disk I/O load. The display is refreshed in + regular intervals (by default every 1s), similar in style to + top1. + If systemd-cgtop is not connected to a tty, + only one iteration is performed and no columns headers are + printed. This mode is suitable for scripting. + + Resource usage is only accounted for control groups in the + relevant hierarchy, i.e. CPU usage is only accounted for control + groups in the cpuacct hierarchy, memory usage + only for those in memory and disk I/O usage for + those in blkio. If resource monitoring for + these resources is required, it is recommended to add the + CPUAccounting=1, + MemoryAccounting=1 and + BlockIOAccounting=1 settings in the unit files + in question. See + systemd.resource-control5 + for details. + + To emphasize this: unless + CPUAccounting=1, + MemoryAccounting=1 and + BlockIOAccounting=1 are enabled for the + services in question, no resource accounting will be available for + system services and the data shown by + systemd-cgtop will be incomplete. + + + + Options + + The following options are understood: + + + + + + Order by control group + path name. + + + + + + Order by number of tasks in control group + (i.e. threads and processes). + + + + + + Order by CPU load. + + + + + + Order by memory usage. + + + + + + Order by disk I/O load. + + + + + + + Run in "batch" mode: do not accept input and + run until the iteration limit set with + is exhausted or until killed. + This mode could be useful for sending output from + systemd-cgtop to other programs or to a + file. + + + + + + + Perform only this many iterations. + + + + + + + + Specify refresh delay in seconds (or if one of + ms, + us, + min is specified as unit in this time + unit). + + + + + + Maximum control group tree traversal depth. + Specifies how deep systemd-cgtop shall + traverse the control group hierarchies. If 0 is specified, + only the root group is monitored. For 1, only the first level + of control groups is monitored, and so on. Defaults to + 3. + + + + + + + + + + + Keys + + systemd-cgtop is an interactive tool and + may be controlled via user input using the following keys: + + + + h + + Shows a short help text. + + + + SPACE + + Immediately refresh output. + + + + q + + Terminate the program. + + + + + p + t + c + m + i + + Sort the control groups by path, number of + tasks, CPU load, memory usage, or IO load, respectively. + + + + + % + + Toggle between showing CPU time as time or + percentage. + + + + + + - + + Increase or decrease refresh delay, + respectively. + + + + + + + Exit status + + On success, 0 is returned, a non-zero failure code + otherwise. + + + + See Also + + systemd1, + systemctl1, + systemd-cgls1, + systemd.resource-control5, + top1 + + diff --git a/man/systemd-cryptsetup-generator.xml b/man/systemd-cryptsetup-generator.xml index c8753cef37d..0e48e793464 100644 --- a/man/systemd-cryptsetup-generator.xml +++ b/man/systemd-cryptsetup-generator.xml @@ -21,199 +21,175 @@ --> - - systemd-cryptsetup-generator - systemd - - - - Developer - Lennart - Poettering - lennart@poettering.net - - - - - - systemd-cryptsetup-generator - 8 - - - - systemd-cryptsetup-generator - Unit generator for /etc/crypttab - - - - /usr/lib/systemd/system-generators/systemd-cryptsetup-generator - - - - Description - - systemd-cryptsetup-generator - is a generator that translates - /etc/crypttab into native systemd - units early at boot and when configuration of the - system manager is reloaded. This will create - systemd-cryptsetup@.service8 - units as necessary. - - systemd-cryptsetup-generator - implements the generator - specification. - - - - Kernel Command Line - - systemd-cryptsetup-generator understands - the following kernel command line parameters: - - - - luks= - rd.luks= - - Takes a boolean - argument. Defaults to - yes. If - no, disables the - generator - entirely. rd.luks= - is honored only by initial RAM disk - (initrd) while - luks= is honored - by both the main system and the - initrd. - - - - luks.crypttab= - rd.luks.crypttab= - - Takes a boolean - argument. Defaults to - yes. If - no, causes the - generator to ignore any devices - configured in - /etc/crypttab - (luks.uuid= will - still work - however). rd.luks.crypttab= - is honored only by initial RAM disk - (initrd) while - luks.crypttab= is - honored by both the main system and - the initrd. - - - - luks.uuid= - rd.luks.uuid= - - Takes a LUKS superblock - UUID as argument. This will - activate the specified device as part - of the boot process as if it was - listed in - /etc/crypttab. This - option may be specified more than once - in order to set up multiple - devices. rd.luks.uuid= - is honored only by initial RAM disk - (initrd) while - luks.uuid= is - honored by both the main system and - the initrd. - If /etc/crypttab contains entries with - the same UUID, then the name, keyfile and options - specified there will be used. Otherwise the device - will have the name luks-UUID. - If /etc/crypttab exists, only those UUIDs - specified on the kernel command line - will be activated in the initrd or the real root. - - - - - luks.name= - rd.luks.name= - - Takes a LUKS super - block UUID followed by an '=' and a name. This implies - rd.luks.uuid= or luks.uuid= - and will additionally make the LUKS device given by - the UUID appear under the provided name. - - rd.luks.name= - is honored only by initial RAM disk - (initrd) while - luks.name= is - honored by both the main system and - the initrd. - - - - - luks.options= - rd.luks.options= - - Takes a LUKS super - block UUID followed by an '=' and a string - of options separated by commas as argument. - This will override the options for the given - UUID. - If only a list of options, without an - UUID, is specified, they apply to any UUIDs not - specified elsewhere, and without an entry in - /etc/crypttab. - rd.luks.options= - is honored only by initial RAM disk - (initrd) while - luks.options= is - honored by both the main system and - the initrd. - - - - - luks.key= - rd.luks.key= - - Takes a password file name as argument or - a LUKS super block UUID followed by a '=' and a password - file name. - - For those entries specified with - rd.luks.uuid= or luks.uuid=, - the password file will be set to the one specified by - rd.luks.key= or luks.key= - of the corresponding UUID, or the password file that was specified - without a UUID. - rd.luks.key= - is honored only by initial RAM disk - (initrd) while - luks.key= is - honored by both the main system and - the initrd. - - - - - - - See Also - - systemd1, - crypttab5, - systemd-cryptsetup@.service8, - cryptsetup8, - systemd-fstab-generator8 - - + + systemd-cryptsetup-generator + systemd + + + + Developer + Lennart + Poettering + lennart@poettering.net + + + + + + systemd-cryptsetup-generator + 8 + + + + systemd-cryptsetup-generator + Unit generator for /etc/crypttab + + + + /usr/lib/systemd/system-generators/systemd-cryptsetup-generator + + + + Description + + systemd-cryptsetup-generator is a + generator that translates /etc/crypttab into + native systemd units early at boot and when configuration of the + system manager is reloaded. This will create + systemd-cryptsetup@.service8 + units as necessary. + + systemd-cryptsetup-generator + implements the generator + specification. + + + + Kernel Command Line + + systemd-cryptsetup-generator + understands the following kernel command line parameters: + + + + luks= + rd.luks= + + Takes a boolean argument. Defaults to + yes. If no, disables the + generator entirely. rd.luks= is honored + only by initial RAM disk (initrd) while + luks= is honored by both the main system + and the initrd. + + + + luks.crypttab= + rd.luks.crypttab= + + Takes a boolean argument. Defaults to + yes. If no, causes the + generator to ignore any devices configured in + /etc/crypttab + (luks.uuid= will still work however). + rd.luks.crypttab= is honored only by + initial RAM disk (initrd) while + luks.crypttab= is honored by both the main + system and the initrd. + + + + luks.uuid= + rd.luks.uuid= + + Takes a LUKS superblock UUID as argument. This + will activate the specified device as part of the boot process + as if it was listed in /etc/crypttab. + This option may be specified more than once in order to set up + multiple devices. rd.luks.uuid= is honored + only by initial RAM disk (initrd) while + luks.uuid= is honored by both the main + system and the initrd. + If /etc/crypttab contains entries with the same UUID, + then the name, keyfile and options specified there will be + used. Otherwise the device will have the name + luks-UUID. + If /etc/crypttab exists, only those UUIDs + specified on the kernel command line + will be activated in the initrd or the real root. + + + + + luks.name= + rd.luks.name= + + Takes a LUKS super block UUID followed by an + = and a name. This implies + rd.luks.uuid= or + luks.uuid= and will additionally make the + LUKS device given by the UUID appear under the provided + name. + + rd.luks.name= is honored only by + initial RAM disk (initrd) while luks.name= + is honored by both the main system and the initrd. + + + + + luks.options= + rd.luks.options= + + Takes a LUKS super block UUID followed by an + = and a string of options separated by + commas as argument. This will override the options for the + given UUID. + If only a list of options, without an UUID, is + specified, they apply to any UUIDs not specified elsewhere, + and without an entry in + /etc/crypttab. + rd.luks.options= is honored only by initial + RAM disk (initrd) while luks.options= is + honored by both the main system and the initrd. + + + + + luks.key= + rd.luks.key= + + Takes a password file name as argument or a + LUKS super block UUID followed by a = and a + password file name. + + For those entries specified with + rd.luks.uuid= or + luks.uuid=, the password file will be set + to the one specified by rd.luks.key= or + luks.key= of the corresponding UUID, or the + password file that was specified without a UUID. + rd.luks.key= + is honored only by initial RAM disk + (initrd) while + luks.key= is + honored by both the main system and + the initrd. + + + + + + + See Also + + systemd1, + crypttab5, + systemd-cryptsetup@.service8, + cryptsetup8, + systemd-fstab-generator8 + + diff --git a/man/systemd-cryptsetup@.service.xml b/man/systemd-cryptsetup@.service.xml index 6fa2e0cdd03..bd03637deb2 100644 --- a/man/systemd-cryptsetup@.service.xml +++ b/man/systemd-cryptsetup@.service.xml @@ -21,67 +21,65 @@ --> - - systemd-cryptsetup@.service - systemd + + systemd-cryptsetup@.service + systemd - - - Developer - Lennart - Poettering - lennart@poettering.net - - - + + + Developer + Lennart + Poettering + lennart@poettering.net + + + - - systemd-cryptsetup@.service - 8 - + + systemd-cryptsetup@.service + 8 + - - systemd-cryptsetup@.service - systemd-cryptsetup - Full disk decryption logic - + + systemd-cryptsetup@.service + systemd-cryptsetup + Full disk decryption logic + - - systemd-cryptsetup@.service - /usr/lib/systemd/systemd-cryptsetup - + + systemd-cryptsetup@.service + /usr/lib/systemd/systemd-cryptsetup + - - Description + + Description - systemd-cryptsetup@.service - is a service responsible for setting up encrypted - block devices. It is instantiated for each device that - requires decryption for access. + systemd-cryptsetup@.service is a + service responsible for setting up encrypted block devices. It is + instantiated for each device that requires decryption for + access. - systemd-cryptsetup@.service - will ask for hard disk passwords via the - password agent logic, in order to query the - user for the password using the right mechanism at - boot and during runtime. + systemd-cryptsetup@.service will ask + for hard disk passwords via the + password agent logic, in order to query the user for the + password using the right mechanism at boot and during + runtime. - At early boot and when the system manager - configuration is reloaded this - /etc/crypttab is translated into - systemd-cryptsetup@.service units - by - systemd-cryptsetup-generator8. - + At early boot and when the system manager configuration is + reloaded this /etc/crypttab is translated + into systemd-cryptsetup@.service units by + systemd-cryptsetup-generator8. + - - See Also - - systemd1, - systemd-cryptsetup-generator8, - crypttab5, - cryptsetup8 - - + + See Also + + systemd1, + systemd-cryptsetup-generator8, + crypttab5, + cryptsetup8 + + diff --git a/man/systemd-debug-generator.xml b/man/systemd-debug-generator.xml index a2bef5fe283..74c3b2620e4 100644 --- a/man/systemd-debug-generator.xml +++ b/man/systemd-debug-generator.xml @@ -21,78 +21,77 @@ --> - - systemd-debug-generator - systemd - - - - Developer - Lennart - Poettering - lennart@poettering.net - - - - - - systemd-debug-generator - 8 - - - - systemd-debug-generator - Generator for enabling a runtime debug shell and masking specific units at boot - - - - /usr/lib/systemd/system-generators/systemd-debug-generator - - - - Description - - systemd-debug-generator is - a generator that reads the kernel command line and - understands three options: - - If the option is - specified and followed by a unit name, this unit is - masked for the runtime, similar to the effect of - systemctl1's - mask command. This is useful to - boot with certain units removed from the initial boot - transaction for debugging system startup. May be - specified more than once. - - If the option is - specified and followed by a unit name, a start job for - this unit is added to the initial transaction. This is - useful to start one or more additional units at - boot. May be specified more than once. - - If the - option is specified, the debug shell service - debug-shell.service is pulled into - the boot transaction. It will spawn a debug shell on - tty9 during early system startup. Note that the shell - may also be turned on persistently by enabling it with - systemctl1's - enable command. - - systemd-debug-generator - implements the generator - specification. - - - - See Also - - systemd1, - systemctl1, - kernel-command-line7 - - + + systemd-debug-generator + systemd + + + + Developer + Lennart + Poettering + lennart@poettering.net + + + + + + systemd-debug-generator + 8 + + + + systemd-debug-generator + Generator for enabling a runtime debug shell and + masking specific units at boot + + + + /usr/lib/systemd/system-generators/systemd-debug-generator + + + + Description + + systemd-debug-generator is a generator + that reads the kernel command line and understands three + options: + + If the option is specified + and followed by a unit name, this unit is masked for the runtime, + similar to the effect of + systemctl1's + mask command. This is useful to boot with + certain units removed from the initial boot transaction for + debugging system startup. May be specified more than once. + + If the option is specified + and followed by a unit name, a start job for this unit is added to + the initial transaction. This is useful to start one or more + additional units at boot. May be specified more than once. + + If the option is + specified, the debug shell service + debug-shell.service is pulled into the boot + transaction. It will spawn a debug shell on tty9 during early + system startup. Note that the shell may also be turned on + persistently by enabling it with + systemctl1's + enable command. + + systemd-debug-generator implements the + generator + specification. + + + + See Also + + systemd1, + systemctl1, + kernel-command-line7 + + diff --git a/man/systemd-delta.xml b/man/systemd-delta.xml index 2175f965507..fd81b2c907d 100644 --- a/man/systemd-delta.xml +++ b/man/systemd-delta.xml @@ -1,6 +1,6 @@ + "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd"> - - - systemd-delta - systemd - - - - Developer - Lennart - Poettering - lennart@poettering.net - - - - - - systemd-delta - 1 - - - - systemd-delta - Find overridden configuration files - - - - - systemd-delta - OPTIONS - PREFIX/SUFFIX|SUFFIX - - - - - Description - - systemd-delta may be used to - identify and compare configuration files that override - other configuration files. Files in - /etc have highest priority, files - in /run have the second highest - priority, ..., files in /lib have - lowest priority. Files in a directory with higher - priority override files with the same name in - directories of lower priority. In addition, certain - configuration files can have .d - directories which contain "drop-in" files with - configuration snippets which augment the main - configuration file. "Drop-in" files can be overriden - in the same way by placing files with the same name in - a directory of higher priority (except that in case of - "drop-in" files, both the "drop-in" file name and the - name of the containing directory, which corresponds to - the name of the main configuration file, must match). - For a fuller explanation, see - systemd.unit5. - - - The command line argument will be split into a - prefix and a suffix. Either is optional. The prefix - must be one of the directories containing - configuration files (/etc, - /run, - /usr/lib, ...). If it is given, - only overriding files contained in this directory will - be shown. Otherwise, all overriding files will be - shown. The suffix must be a name of a subdirectory - containing configuration files like - tmpfiles.d, - sysctl.d or - systemd/system. If it is given, - only configuration files in this subdirectory (across - all configuration paths) will be analyzed. Otherwise, - all configuration files will be analyzed. If the - command line argument is not given at all, all - configuration files will be analyzed. See below for - some examples. - - - - Options - - The following options are understood: - - - - - - - When listing the - differences, only list those that are - asked for. The list itself is a - comma-separated list of desired - difference types. - - Recognized types are: - - - - masked - - Show masked files - - - - equivalent - - Show overridden - files that while overridden, do - not differ in content. - - - - redirected - - Show files that - are redirected to another. - - - - overridden - - Show overridden, - and changed files. - - - - extended - - Show *.conf files in drop-in - directories for units. - - - - unchanged - - Show unmodified - files too. - - - - - - - - - When showing modified - files, when a file is overridden show a - diff as well. This option takes a - boolean argument. If omitted, it defaults - to . - - - - - - - - - - Examples - - To see all local configuration: - systemd-delta - - To see all runtime configuration: - systemd-delta /run - - To see all system unit configuration changes: - systemd-delta systemd/system - - To see all runtime "drop-in" changes for system units: - systemd-delta --type=extended /run/systemd/system - + xmlns:xi="http://www.w3.org/2001/XInclude"> + + + systemd-delta + systemd + + + + Developer + Lennart + Poettering + lennart@poettering.net + + + + + + systemd-delta + 1 + + + + systemd-delta + Find overridden configuration files + + + + + systemd-delta + OPTIONS + PREFIX/SUFFIX|SUFFIX + + + + + Description + + systemd-delta may be used to identify and + compare configuration files that override other configuration + files. Files in /etc have highest priority, + files in /run have the second highest + priority, ..., files in /lib have lowest + priority. Files in a directory with higher priority override files + with the same name in directories of lower priority. In addition, + certain configuration files can have .d + directories which contain "drop-in" files with configuration + snippets which augment the main configuration file. "Drop-in" + files can be overriden in the same way by placing files with the + same name in a directory of higher priority (except that in case + of "drop-in" files, both the "drop-in" file name and the name of + the containing directory, which corresponds to the name of the + main configuration file, must match). For a fuller explanation, + see + systemd.unit5. + + + The command line argument will be split into a prefix and a + suffix. Either is optional. The prefix must be one of the + directories containing configuration files + (/etc, /run, + /usr/lib, ...). If it is given, only + overriding files contained in this directory will be shown. + Otherwise, all overriding files will be shown. The suffix must be + a name of a subdirectory containing configuration files like + tmpfiles.d, sysctl.d or + systemd/system. If it is given, only + configuration files in this subdirectory (across all configuration + paths) will be analyzed. Otherwise, all configuration files will + be analyzed. If the command line argument is not given at all, all + configuration files will be analyzed. See below for some + examples. + + + + Options + + The following options are understood: + + + + + + + When listing the differences, only list those + that are asked for. The list itself is a comma-separated list + of desired difference types. + + Recognized types are: + + + + masked + + Show masked files + + + + equivalent + + Show overridden files that while + overridden, do not differ in content. + + + + redirected + + Show files that are redirected to + another. + + + + overridden + + Show overridden, and changed + files. + + + + extended + + Show *.conf files + in drop-in directories for units. + + + + unchanged + + Show unmodified files + too. + + + + + + + + + When showing modified files, when a file is + overridden show a diff as well. This option takes a boolean + argument. If omitted, it defaults to + . + + + + + + + + + + Examples + + To see all local configuration: + systemd-delta + + To see all runtime configuration: + systemd-delta /run + + To see all system unit configuration changes: + systemd-delta systemd/system + + To see all runtime "drop-in" changes for system units: + systemd-delta --type=extended /run/systemd/system + - - Exit status + + Exit status - On success, 0 is returned, a non-zero failure - code otherwise. - + On success, 0 is returned, a non-zero failure code + otherwise. + - - See Also - - systemd1, - systemd.unit5 - - + + See Also + + systemd1, + systemd.unit5 + + diff --git a/man/systemd-detect-virt.xml b/man/systemd-detect-virt.xml index d8e881cf2e8..40755a24d0c 100644 --- a/man/systemd-detect-virt.xml +++ b/man/systemd-detect-virt.xml @@ -1,6 +1,6 @@ + "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd"> - - - systemd-detect-virt - systemd - - - - Developer - Lennart - Poettering - lennart@poettering.net - - - - - - systemd-detect-virt - 1 - - - - systemd-detect-virt - Detect execution in a virtualized environment - - - - - systemd-detect-virt OPTIONS - - - - - Description - - systemd-detect-virt detects - execution in a virtualized environment. It identifies - the virtualization technology and can distinguish full - VM virtualization from container - virtualization. systemd-detect-virt - exits with a return value of 0 (success) if a - virtualization technology is detected, and non-zero - (error) otherwise. By default any type of - virtualization is detected, and the options - and - can be used to limit what types of virtualization are - detected. - - When executed without - will print a short identifier for the detected - virtualization technology. The following technologies - are currently identified: - - - Known virtualization technologies (both - VM, i.e. full hardware virtualization, - and container, i.e. shared kernel virtualization) - - - - - - - Type - ID - Product - - - - - VM - qemu - QEMU software virtualization - - - - kvm - Linux KVM kernel virtual machine - - - - zvm - s390 z/VM - - - - vmware - VMware Workstation or Server, and related products - - - - microsoft - Hyper-V, also known as Viridian or Windows Server Virtualization - - - - oracle - Oracle VM VirtualBox (historically marketed by innotek and Sun Microsystems) - - - - xen - Xen hypervisor (only domU, not dom0) - - - - bochs - Bochs Emulator - - - - uml - User-mode Linux - - - - container - openvz - OpenVZ/Virtuozzo - - - - lxc - Linux container implementation by LXC - - - - lxc-libvirt - Linux container implementation by libvirt - - - - systemd-nspawn - systemd's minimal container implementation, see systemd-nspawn1 - - - - docker - Docker container manager - - - -
- - If multiple virtualization solutions are used, - only the "innermost" is detected and identified. That - means if both VM virtualization and container - virtualization are used in conjunction, only the latter - will be identified (unless is - passed). - - - - Options - - The following options are understood: - - - - - - - Only detects container - virtualization (i.e. shared kernel - virtualization). - - - - - - - Only detects VM - virtualization (i.e. full hardware - virtualization). - - - - - - - Suppress output of the - virtualization technology - identifier. - - - - - - - - - - Exit status - - If a virtualization technology is detected, 0 is - returned, a non-zero code otherwise. - - - - See Also - - systemd1, - systemd-nspawn1 - - + xmlns:xi="http://www.w3.org/2001/XInclude"> + + + systemd-detect-virt + systemd + + + + Developer + Lennart + Poettering + lennart@poettering.net + + + + + + systemd-detect-virt + 1 + + + + systemd-detect-virt + Detect execution in a virtualized environment + + + + + systemd-detect-virt OPTIONS + + + + + Description + + systemd-detect-virt detects execution in + a virtualized environment. It identifies the virtualization + technology and can distinguish full VM virtualization from + container virtualization. systemd-detect-virt + exits with a return value of 0 (success) if a virtualization + technology is detected, and non-zero (error) otherwise. By default + any type of virtualization is detected, and the options + and can be used + to limit what types of virtualization are detected. + + When executed without will print a + short identifier for the detected virtualization technology. The + following technologies are currently identified: + + + Known virtualization technologies (both + VM, i.e. full hardware virtualization, + and container, i.e. shared kernel virtualization) + + + + + + + Type + ID + Product + + + + + VM + qemu + QEMU software virtualization + + + + kvm + Linux KVM kernel virtual machine + + + + zvm + s390 z/VM + + + + vmware + VMware Workstation or Server, and related products + + + + microsoft + Hyper-V, also known as Viridian or Windows Server Virtualization + + + + oracle + Oracle VM VirtualBox (historically marketed by innotek and Sun Microsystems) + + + + xen + Xen hypervisor (only domU, not dom0) + + + + bochs + Bochs Emulator + + + + uml + User-mode Linux + + + + container + openvz + OpenVZ/Virtuozzo + + + + lxc + Linux container implementation by LXC + + + + lxc-libvirt + Linux container implementation by libvirt + + + + systemd-nspawn + systemd's minimal container implementation, see systemd-nspawn1 + + + + docker + Docker container manager + + + +
+ + If multiple virtualization solutions are used, only the + "innermost" is detected and identified. That means if both VM + virtualization and container virtualization are used in + conjunction, only the latter will be identified (unless + is passed). + + + + Options + + The following options are understood: + + + + + + + Only detects container virtualization (i.e. + shared kernel virtualization). + + + + + + + Only detects VM virtualization (i.e. full + hardware virtualization). + + + + + + + Suppress output of the virtualization + technology identifier. + + + + + + + + + + Exit status + + If a virtualization technology is detected, 0 is returned, a + non-zero code otherwise. + + + + See Also + + systemd1, + systemd-nspawn1 + + diff --git a/man/systemd-efi-boot-generator.xml b/man/systemd-efi-boot-generator.xml index 3a79dfb8df0..b2d8d65e3d8 100644 --- a/man/systemd-efi-boot-generator.xml +++ b/man/systemd-efi-boot-generator.xml @@ -21,68 +21,68 @@ --> - - systemd-efi-boot-generator - systemd + + systemd-efi-boot-generator + systemd - - - Developer - Lennart - Poettering - lennart@poettering.net - - - + + + Developer + Lennart + Poettering + lennart@poettering.net + + + - - systemd-efi-boot-generator - 8 - + + systemd-efi-boot-generator + 8 + - - systemd-efi-boot-generator - Generator for automatically mounting the - EFI System Partition used by the current boot to - /boot - + + systemd-efi-boot-generator + Generator for automatically mounting the + EFI System Partition used by the current boot to + /boot + - - /usr/lib/systemd/system-generators/systemd-efi-boot-generator - + + /usr/lib/systemd/system-generators/systemd-efi-boot-generator + - - Description + + Description - systemd-efi-boot-generator - is a generator that automatically creates mount and - automount units for the EFI System Partition (ESP), - mounting it to /boot. Note that - this generator will execute no operation on non-EFI - systems, on systems where the boot loader does not - communicate the used ESP to the OS, on systems where - /boot is an explicitly configured - mount (for example, listed in fstab5) or where the /boot mount - point is non-empty. Since this generator creates an - automount unit, the mount will only be activated - on-demand, when accessed. + systemd-efi-boot-generator is a + generator that automatically creates mount and automount units for + the EFI System Partition (ESP), mounting it to + /boot. Note that this generator will execute + no operation on non-EFI systems, on systems where the boot loader + does not communicate the used ESP to the OS, on systems where + /boot is an explicitly configured mount (for + example, listed in + fstab5) + or where the /boot mount point is non-empty. + Since this generator creates an automount unit, the mount will + only be activated on-demand, when accessed. - systemd-efi-boot-generator - implements the generator - specification. - + systemd-efi-boot-generator implements + the generator + specification. + - - See Also - - systemd1, - systemd.mount5, - systemd.automount5, - systemd-gpt-auto-generator8, - gummiboot8, - fstab5 - - + + See Also + + systemd1, + systemd.mount5, + systemd.automount5, + systemd-gpt-auto-generator8, + gummiboot8, + fstab5 + + diff --git a/man/systemd-escape.xml b/man/systemd-escape.xml index b2a4a9ce8c4..0c3b2305264 100644 --- a/man/systemd-escape.xml +++ b/man/systemd-escape.xml @@ -1,6 +1,6 @@ + "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd"> - - - systemd-escape - systemd - - - - Developer - Lennart - Poettering - lennart@poettering.net - - - - - - systemd-escape - 1 - - - - systemd-escape - Escape strings for usage in system unit names - - - - - systemd-escape OPTIONS STRING - - - - - Description - - systemd-escape may be used to - escape strings for inclusion in systemd unit - names. The command may be used to escape and to undo - escaping of strings. - - The command takes any number of strings on the - command line, and will process them individually, one - after the other. It will output them separated by - spaces to stdout. - - By default this command will escape the strings - passed, unless is passed - which results in the inverse operation being - applied. If a special mode - of escaping is applied instead, which assumes a string - to be already escaped but will escape everything that - appears obviously non-escaped. - - - - Options - - The following options are understood: - - - - - - Appends the specified - unit type suffix to the escaped - string. Takes one of the unit types - supported by systemd, such as - .service or - .mount. May not be - used in conjunction with - , - or - . - - - - - - Inserts the escaped - strings in a unit name template. Takes - a unit name template such as - foobar@.service - May not be used in conjunction with - , - or - . - - - - - - - When escaping or - unescaping a string, assume it refers - to a file system path. This enables - special processing of the initial - / of the - path. - - - - - - Instead of escaping - the specified strings, undo the - escaping, reversing the operation. May - not be used in conjunction with - , - or - . - - - - - - Like - , but only - escape characters that are obviously - not escaped yet, and possibly - automatically append an appropriate - unit type suffix to the string. May - not be used in conjunction with - , - or - . - - - - - - - - - - Examples - - Escape a single string: - $ systemd-escape 'Hallöchen, Meister' + xmlns:xi="http://www.w3.org/2001/XInclude"> + + + systemd-escape + systemd + + + + Developer + Lennart + Poettering + lennart@poettering.net + + + + + + systemd-escape + 1 + + + + systemd-escape + Escape strings for usage in system unit names + + + + + systemd-escape + OPTIONS + STRING + + + + + Description + + systemd-escape may be used to escape + strings for inclusion in systemd unit names. The command may be + used to escape and to undo escaping of strings. + + The command takes any number of strings on the command line, + and will process them individually, one after the other. It will + output them separated by spaces to stdout. + + By default this command will escape the strings passed, + unless is passed which results in the + inverse operation being applied. If a + special mode of escaping is applied instead, which assumes a + string to be already escaped but will escape everything that + appears obviously non-escaped. + + + + Options + + The following options are understood: + + + + + + Appends the specified unit type suffix to the + escaped string. Takes one of the unit types supported by + systemd, such as .service or + .mount. May not be used in conjunction with + , or + . + + + + + + Inserts the escaped strings in a unit name + template. Takes a unit name template such as + foobar@.service May not be used in + conjunction with , + or + . + + + + + + + When escaping or unescaping a string, assume + it refers to a file system path. This enables special + processing of the initial / of the + path. + + + + + + Instead of escaping the specified strings, + undo the escaping, reversing the operation. May not be used in + conjunction with , + or + . + + + + + + Like , but only + escape characters that are obviously not escaped yet, and + possibly automatically append an appropriate unit type suffix + to the string. May not be used in conjunction with + , or + . + + + + + + + + + + Examples + + Escape a single string: + $ systemd-escape 'Hallöchen, Meister' Hall\xc3\xb6chen\x2c\x20Meister - To undo escaping on a single string: - $ systemd-escape -u 'Hall\xc3\xb6chen\x2c\x20Meister' + To undo escaping on a single string: + $ systemd-escape -u 'Hall\xc3\xb6chen\x2c\x20Meister' Hallöchen, Meister - To generate the mount unit for a path: - $ systemd-escape -p --suffix=mount "/tmp//waldi/foobar/" + To generate the mount unit for a path: + $ systemd-escape -p --suffix=mount "/tmp//waldi/foobar/" tmp-waldi-foobar.mount - To generate instance names of three strings - $ systemd-escape --template=systemd-nspawn@.service 'My Container 1' 'containerb' 'container/III' + To generate instance names of three strings + $ systemd-escape --template=systemd-nspawn@.service 'My Container 1' 'containerb' 'container/III' systemd-nspawn@My\x20Container\x201.service systemd-nspawn@containerb.service systemd-nspawn@container-III.service - - - - Exit status - - On success, 0 is returned, a non-zero failure - code otherwise. - - - - See Also - - systemd1, - systemctl1 - - + + + + Exit status + + On success, 0 is returned, a non-zero failure code + otherwise. + + + + See Also + + systemd1, + systemctl1 + + diff --git a/man/systemd-firstboot.xml b/man/systemd-firstboot.xml index 8d973022444..5f19aaf476c 100644 --- a/man/systemd-firstboot.xml +++ b/man/systemd-firstboot.xml @@ -1,6 +1,6 @@ + "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd"> - - - systemd-firstboot - systemd - - - - Developer - Lennart - Poettering - lennart@poettering.net - - - - - - systemd-firstboot - 1 - - - - systemd-firstboot - systemd-firstboot.service - Initialize basic system settings on or before the first boot-up of a system - - - - - systemd-firstboot - OPTIONS - - - systemd-firstboot.service - - - - Description - - systemd-firstboot initializes - the most basic system settings interactively on the - first boot, or optionally non-interactively when a - system image is created. The following settings may be - set up: - - - The system locale, more - specifically the two locale variables - LANG= and - LC_MESSAGES - - The system time zone - - The system host name - - The machine ID of the system - - The root user's password - - - Each of the fields may either be queried - interactively from the users, set non-interactively on - the tool's command line, or be copied from a host - system that is used to set up the system image. - - If a setting is already initialized it will not - be overwritten and the user will not be prompted for - the setting. - - Note that this tool operates directly on the - file system and does not involve any running system - services, unlike - localectl1, - timedatectl1 - or - hostnamectl1. This - allows systemd-firstboot to operate - on mounted but not booted disk images and in early - boot. It is not recommended to use - systemd-firstboot on the running - system while it is up. - - - - Options - - The following options are understood: - - - - - Takes a directory path - as an argument. All paths will be - prefixed with the given alternate - root path, - including config search paths. This is - useful to operate on a system image - mounted to the specified directory - instead of the host system itself. - - - - - - - - Sets the system - locale, more specifically the - LANG= and - LC_MESSAGES - settings. The argument should be a - valid locale identifier, such as - de_DE.UTF-8. This - controls the - locale.conf5 - configuration file. - - - - - - Sets the system time - zone. The argument should be a valid - time zone identifier, such as - Europe/Berlin. This - controls the - localtime5 - symlink. - - - - - - Sets the system - hostname. The argument should be a - host name, compatible with DNS. This - controls the - hostname5 - configuration file. - - - - - - Sets the system's machine ID. This - controls the - machine-id5 - file. - - - - - - - Sets the password of - the system's root user. This creates a - shadow5 - file. This setting exists in two - forms: - - accepts the password to set directly - on the command line, - - reads it from a file. Note that - it is not recommended specifying - passwords on the command line as other - users might be able to see them - simply by invoking - ps1. - - - - - - - - - Prompt the user interactively - for a specific basic setting. Note - that any explicit configuration - settings specified on the command line - take precedence, and the user is not - prompted for it. - - - - - - Query the user for locale, - timezone, hostname and root - password. This is equivalent to - specifying - , - , - , - - in combination. - - - - - - - - Copy a specific basic setting - from the host. This only works in - combination with - (see - above). - - - - - - Copy locale, time zone and root - password from the host. This is - equivalent to specifying - , - , - - in combination. - - - - - - Initialize the system's machine - ID to a random ID. This only works in - combination with - . - - - - - - - - - - Exit status - - On success, 0 is returned, a non-zero failure - code otherwise. - - - - See Also - - systemd1, - locale.conf5, - localtime5, - hostname5, - machine-id5, - shadow5, - systemd-machine-id-setup1, - localectl1, - timedatectl1, - hostnamectl1 - - + xmlns:xi="http://www.w3.org/2001/XInclude"> + + + systemd-firstboot + systemd + + + + Developer + Lennart + Poettering + lennart@poettering.net + + + + + + systemd-firstboot + 1 + + + + systemd-firstboot + systemd-firstboot.service + Initialize basic system settings on or before the first boot-up of a system + + + + + systemd-firstboot + OPTIONS + + + systemd-firstboot.service + + + + Description + + systemd-firstboot initializes the most + basic system settings interactively on the first boot, or + optionally non-interactively when a system image is created. The + following settings may be set up: + + + The system locale, more specifically the two + locale variables LANG= and + LC_MESSAGES + + The system time zone + + The system host name + + The machine ID of the system + + The root user's password + + + Each of the fields may either be queried interactively from + the users, set non-interactively on the tool's command line, or be + copied from a host system that is used to set up the system + image. + + If a setting is already initialized it will not be + overwritten and the user will not be prompted for the + setting. + + Note that this tool operates directly on the file system and + does not involve any running system services, unlike + localectl1, + timedatectl1 + or + hostnamectl1. + This allows systemd-firstboot to operate on + mounted but not booted disk images and in early boot. It is not + recommended to use systemd-firstboot on the + running system while it is up. + + + + Options + + The following options are understood: + + + + + Takes a directory path as an argument. All + paths will be prefixed with the given alternate + root path, including config search + paths. This is useful to operate on a system image mounted to + the specified directory instead of the host system itself. + + + + + + + + Sets the system locale, more specifically the + LANG= and LC_MESSAGES + settings. The argument should be a valid locale identifier, + such as de_DE.UTF-8. This controls the + locale.conf5 + configuration file. + + + + + + Sets the system time zone. The argument should + be a valid time zone identifier, such as + Europe/Berlin. This controls the + localtime5 + symlink. + + + + + + Sets the system hostname. The argument should + be a host name, compatible with DNS. This controls the + hostname5 + configuration file. + + + + + + Sets the system's machine ID. This controls + the + machine-id5 + file. + + + + + + + Sets the password of the system's root user. + This creates a + shadow5 + file. This setting exists in two forms: + accepts the password to set + directly on the command line, + reads it from a file. + Note that it is not recommended specifying passwords on the + command line as other users might be able to see them simply + by invoking + ps1. + + + + + + + + + Prompt the user interactively for a specific + basic setting. Note that any explicit configuration settings + specified on the command line take precedence, and the user is + not prompted for it. + + + + + + Query the user for locale, timezone, hostname + and root password. This is equivalent to specifying + , + , + , + in combination. + + + + + + + + + Copy a specific basic setting from the host. + This only works in combination with + (see above). + + + + + + Copy locale, time zone and root password from + the host. This is equivalent to specifying + , + , + in combination. + + + + + + + Initialize the system's machine ID to a random + ID. This only works in combination with + . + + + + + + + + + + Exit status + + On success, 0 is returned, a non-zero failure code + otherwise. + + + + See Also + + systemd1, + locale.conf5, + localtime5, + hostname5, + machine-id5, + shadow5, + systemd-machine-id-setup1, + localectl1, + timedatectl1, + hostnamectl1 + + diff --git a/man/systemd-fsck@.service.xml b/man/systemd-fsck@.service.xml index ee66f3712d3..88e11e89d4c 100644 --- a/man/systemd-fsck@.service.xml +++ b/man/systemd-fsck@.service.xml @@ -21,137 +21,121 @@ --> - - systemd-fsck@.service - systemd - - - - Developer - Lennart - Poettering - lennart@poettering.net - - - - - - systemd-fsck@.service - 8 - - - - systemd-fsck@.service - systemd-fsck-root.service - systemd-fsck - File system checker logic - - - - systemd-fsck@.service - systemd-fsck-root.service - /usr/lib/systemd/systemd-fsck - - - - Description - - systemd-fsck@.service and - systemd-fsck-root.service are - services responsible for file system checks. They are - instantiated for each device that is configured for - file system checking. - systemd-fsck-root.service is - responsible for file system checks on the root file - system, but in only if the root filesystem wasn't - checked in the initramfs. - systemd-fsck@.service is used for - all other file systems and for the root file system in - the initramfs. - - Those services are started at boot if - in - /etc/fstab for the file system is - set to a value greater than zero. The file system - check for root is performed before the other file - systems. Other file systems may be checked in - parallel, except when they are one the same rotating - disk. - - systemd-fsck does not know - any details about specific filesystems, and simply - executes file system checkers specific to each - filesystem type (/sbin/fsck.*). - This helper will decide if the filesystem should - actually be checked based on the time since last - check, number of mounts, unclean unmount, etc. - - systemd-fsck will forward - file system checking progress to the console. If a - file system check fails for a service without - , emergency mode is activated, - by isolating to - emergency.target. - - - - Kernel Command Line - - systemd-fsck understands - one kernel command line parameter: - - - - fsck.mode= - - One of - auto, - force, - skip. Controls the - mode of operation. The default is - auto, and ensures - that file system checks are done when - the file system checker deems them - necessary. force - unconditionally results in full file - system checks. skip - skips any file system - checks. - - - - fsck.repair= - - One of - preen, - yes, - no. Controls the - mode of operation. The default is - preen, and will automatically repair - problems that can be safely fixed. yes - will answer yes to all questions by - fsck and no will answer no to - all questions. - - - - - - - See Also - - systemd1, - fsck8, - systemd-quotacheck.service8, - fsck.btrfs8, - fsck.cramfs8, - fsck.ext48, - fsck.fat8, - fsck.hfsplus8, - fsck.minix8, - fsck.ntfs8, - fsck.xfs8 - - + + systemd-fsck@.service + systemd + + + + Developer + Lennart + Poettering + lennart@poettering.net + + + + + + systemd-fsck@.service + 8 + + + + systemd-fsck@.service + systemd-fsck-root.service + systemd-fsck + File system checker logic + + + + systemd-fsck@.service + systemd-fsck-root.service + /usr/lib/systemd/systemd-fsck + + + + Description + + systemd-fsck@.service and + systemd-fsck-root.service are services + responsible for file system checks. They are instantiated for each + device that is configured for file system checking. + systemd-fsck-root.service is responsible for + file system checks on the root file system, but in only if the + root filesystem wasn't checked in the initramfs. + systemd-fsck@.service is used for all other + file systems and for the root file system in the initramfs. + + Those services are started at boot if + in /etc/fstab for the + file system is set to a value greater than zero. The file system + check for root is performed before the other file systems. Other + file systems may be checked in parallel, except when they are one + the same rotating disk. + + systemd-fsck does not know any details + about specific filesystems, and simply executes file system + checkers specific to each filesystem type + (/sbin/fsck.*). This helper will decide if + the filesystem should actually be checked based on the time since + last check, number of mounts, unclean unmount, etc. + + systemd-fsck will forward file system + checking progress to the console. If a file system check fails for + a service without , emergency mode is + activated, by isolating to + emergency.target. + + + + Kernel Command Line + + systemd-fsck understands one kernel + command line parameter: + + + + fsck.mode= + + One of auto, + force, skip. Controls + the mode of operation. The default is auto, + and ensures that file system checks are done when the file + system checker deems them necessary. force + unconditionally results in full file system checks. + skip skips any file system + checks. + + + + fsck.repair= + + One of preen, + yes, no. Controls the + mode of operation. The default is preen, + and will automatically repair problems that can be safely + fixed. yes will answer yes to all + questions by fsck and no will answer no to + all questions. + + + + + + See Also + + systemd1, + fsck8, + systemd-quotacheck.service8, + fsck.btrfs8, + fsck.cramfs8, + fsck.ext48, + fsck.fat8, + fsck.hfsplus8, + fsck.minix8, + fsck.ntfs8, + fsck.xfs8 + + diff --git a/man/systemd-fstab-generator.xml b/man/systemd-fstab-generator.xml index 65b48eea078..8f82e333040 100644 --- a/man/systemd-fstab-generator.xml +++ b/man/systemd-fstab-generator.xml @@ -21,178 +21,165 @@ --> - - systemd-fstab-generator - systemd - - - - Developer - Lennart - Poettering - lennart@poettering.net - - - - - - systemd-fstab-generator - 8 - - - - systemd-fstab-generator - Unit generator for /etc/fstab - - - - /usr/lib/systemd/system-generators/systemd-fstab-generator - - - - Description - - systemd-fstab-generator is - a generator that translates - /etc/fstab (see - fstab5 - for details) into native systemd units early at boot - and when configuration of the system manager is - reloaded. This will instantiate mount and swap units - as necessary. - - The passno field is treated - like a simple boolean, and the ordering information is - discarded. However, if the root file system is - checked, it is checked before all the other - file systems. - - See - systemd.mount5 - and - systemd.swap5 - for more information about special - /etc/fstab mount options this - generator understands. - - systemd-fstab-generator - implements the generator - specification. - - - - Kernel Command Line - - systemd-fstab-generator understands - the following kernel command line parameters: - - - - - fstab= - rd.fstab= - - Takes a boolean - argument. Defaults to - yes. If - no, causes the - generator to ignore any mounts or swaps - configured in - /etc/fstab. rd.fstab= - is honored only by initial RAM disk - (initrd) while - fstab= is - honored by both the main system and - the initrd. - - - root= - - Takes the root filesystem to mount - in the initrd. - root= is - honored by the initrd. - - - rootfstype= - - Takes the root filesystem type that - will be passed to the mount command. - rootfstype= is - honored by the initrd. - - - rootflags= - - Takes the root filesystem mount options - to use. rootflags= is - honored by the initrd. - - - mount.usr= - - Takes the /usr - filesystem to be mounted by the initrd. If - mount.usrfstype= or - mount.usrflags= is set, then - mount.usr= will default to the value set in - root=. - - Otherwise this parameter defaults to the - /usr entry - found in /etc/fstab on the root - filesystem. - - mount.usr= is honored by the initrd. - - - - mount.usrfstype= - - Takes the /usr - filesystem type that will be passed to the mount - command. If mount.usr= or - mount.usrflags= is set, then - mount.usrfstype= will default to the value set in - rootfstype=. - - Otherwise this value will be read from the - /usr entry in - /etc/fstab on the root filesystem. - - mount.usrfstype= is - honored by the initrd. - - - mount.usrflags= - - Takes the /usr - filesystem mount options to use. If - mount.usr= or - mount.usrfstype= is set, then - mount.usrflages= will default to the value set in - rootflags=. - - Otherwise this value will be read from the - /usr entry in - /etc/fstab on the root filesystem. - - mount.usrflags= is - honored by the initrd. - - - - - - See Also - - systemd1, - fstab5, - systemd.mount5, - systemd.swap5, - systemd-cryptsetup-generator8 - - + + systemd-fstab-generator + systemd + + + + Developer + Lennart + Poettering + lennart@poettering.net + + + + + + systemd-fstab-generator + 8 + + + + systemd-fstab-generator + Unit generator for /etc/fstab + + + + /usr/lib/systemd/system-generators/systemd-fstab-generator + + + + Description + + systemd-fstab-generator is a generator + that translates /etc/fstab (see + fstab5 + for details) into native systemd units early at boot and when + configuration of the system manager is reloaded. This will + instantiate mount and swap units as necessary. + + The passno field is treated like a simple + boolean, and the ordering information is discarded. However, if + the root file system is checked, it is checked before all the + other file systems. + + See + systemd.mount5 + and + systemd.swap5 + for more information about special /etc/fstab + mount options this generator understands. + + systemd-fstab-generator implements the + generator + specification. + + + + Kernel Command Line + + systemd-fstab-generator understands the + following kernel command line parameters: + + + + + fstab= + rd.fstab= + + Takes a boolean argument. Defaults to + yes. If no, causes the + generator to ignore any mounts or swaps configured in + /etc/fstab. rd.fstab= + is honored only by initial RAM disk (initrd) while + fstab= is honored by both the main system + and the initrd. + + + root= + + Takes the root filesystem to mount in the + initrd. root= is honored by the + initrd. + + + rootfstype= + + Takes the root filesystem type that will be + passed to the mount command. rootfstype= is + honored by the initrd. + + + rootflags= + + Takes the root filesystem mount options to + use. rootflags= is honored by the + initrd. + + + mount.usr= + + Takes the /usr filesystem + to be mounted by the initrd. If + mount.usrfstype= or + mount.usrflags= is set, then + mount.usr= will default to the value set in + root=. + + Otherwise this parameter defaults to the + /usr entry found in + /etc/fstab on the root filesystem. + + mount.usr= is honored by the initrd. + + + + mount.usrfstype= + + Takes the /usr filesystem + type that will be passed to the mount command. If + mount.usr= or + mount.usrflags= is set, then + mount.usrfstype= will default to the value + set in rootfstype=. + + Otherwise this value will be read from the + /usr entry in + /etc/fstab on the root filesystem. + + mount.usrfstype= is honored by the + initrd. + + + mount.usrflags= + + Takes the /usr filesystem + mount options to use. If mount.usr= or + mount.usrfstype= is set, then + mount.usrflages= will default to the value + set in rootflags=. + + Otherwise this value will be read from the + /usr entry in + /etc/fstab on the root filesystem. + + mount.usrflags= is honored by the + initrd. + + + + + + See Also + + systemd1, + fstab5, + systemd.mount5, + systemd.swap5, + systemd-cryptsetup-generator8 + + diff --git a/man/systemd-getty-generator.xml b/man/systemd-getty-generator.xml index f6a66896dfd..0b5b2f2a714 100644 --- a/man/systemd-getty-generator.xml +++ b/man/systemd-getty-generator.xml @@ -21,81 +21,77 @@ --> - - systemd-getty-generator - systemd + + systemd-getty-generator + systemd - - - Developer - Lennart - Poettering - lennart@poettering.net - - - + + + Developer + Lennart + Poettering + lennart@poettering.net + + + - - systemd-getty-generator - 8 - + + systemd-getty-generator + 8 + - - systemd-getty-generator - Generator for enabling getty instances on - the console - + + systemd-getty-generator + Generator for enabling getty instances on the + console + - - /usr/lib/systemd/system-generators/systemd-getty-generator - + + /usr/lib/systemd/system-generators/systemd-getty-generator + - - Description + + Description - systemd-getty-generator is - a generator that automatically instantiates - serial-getty@.service on the - kernel console /dev/console if - that is not directed to the virtual console - subsystem. It will also instantiate - serial-getty@.service instances - for virtualizer consoles, if execution in a - virtualized environment is detected. Finally, it will - instantiate - container-getty@.service - instances for additional container pseudo TTYs as - requested by the container manager (see Container Interface). This - should ensure that the user is shown a login prompt at - the right place, regardless of which environment the - system is started in. For example, it is sufficient to - redirect the kernel console with a kernel command line - argument such as console= to get - both kernel messages and a getty prompt on a serial - TTY. See kernel-parameters.txt - for more information on the - console= kernel parameter. + systemd-getty-generator is a generator + that automatically instantiates + serial-getty@.service on the kernel console + /dev/console if that is not directed to the + virtual console subsystem. It will also instantiate + serial-getty@.service instances for + virtualizer consoles, if execution in a virtualized environment is + detected. Finally, it will instantiate + container-getty@.service instances for + additional container pseudo TTYs as requested by the container + manager (see Container + Interface). This should ensure that the user is + shown a login prompt at the right place, regardless of which + environment the system is started in. For example, it is + sufficient to redirect the kernel console with a kernel command + line argument such as console= to get both + kernel messages and a getty prompt on a serial TTY. See kernel-parameters.txt + for more information on the console= kernel + parameter. - systemd-getty-generator - implements the generator - specification. + systemd-getty-generator implements the + generator + specification. - Further information about configuration of - gettys you may find in systemd - for Administrators, Part XVI: Gettys on Serial - Consoles (and Elsewhere). - + Further information about configuration of gettys you may + find in + systemd + for Administrators, Part XVI: Gettys on Serial Consoles (and + Elsewhere). + - - See Also - - systemd1, - agetty8 - - + + See Also + + systemd1, + agetty8 + + diff --git a/man/systemd-gpt-auto-generator.xml b/man/systemd-gpt-auto-generator.xml index 68fe2705fa3..9c706df2463 100644 --- a/man/systemd-gpt-auto-generator.xml +++ b/man/systemd-gpt-auto-generator.xml @@ -21,166 +21,160 @@ --> - - systemd-gpt-auto-generator - systemd - - - - Developer - Lennart - Poettering - lennart@poettering.net - - - - - - systemd-gpt-auto-generator - 8 - - - - systemd-gpt-auto-generator - Generator for automatically discovering - and mounting root, /home and - /srv partitions, as well as - discovering and enabling swap partitions, based on GPT - partition type GUIDs. - - - - /usr/lib/systemd/system-generators/systemd-gpt-auto-generator - - - - Description - - systemd-gpt-auto-generator - is a unit generator that automatically discovers root, - /home, /srv - and swap partitions and creates mount and swap units - for them, based on the partition type GUIDs of - GUID partition tables (GPT). It implements the Discoverable - Partitions Specification. Note that this - generator has no effect on non-GPT systems, on systems - where the units are explicitly configured (for - example, listed in - fstab5), - or where the mount points are non-empty. - - This generator will only look for root - partitions on the same physical disk the EFI System - Partition (ESP) is located on. It will only look for - the other partitions on the same physical disk the - root file system is located on. These partitions will - not be searched on systems where the root file system is - distributed on multiple disks, for example via btrfs - RAID. - - systemd-gpt-auto-generator - is useful for centralizing file system configuration - in the partition table and making manual configuration - in /etc/fstab or suchlike - unnecessary. - - This generator looks for the partitions based on - their partition type GUID. The following partition - type GUIDs are identified: - - - Partition Type GUIDs - - - - - - - Partition Type GUID - Name - Explanation - - - - - 44479540-f297-41b2-9af7-d131d5f0458a - Root Partition (x86) - On 32-bit x86 systems, the first x86 root partition on the disk the EFI ESP is located on is mounted to the root directory /. - - - 4f68bce3-e8cd-4db1-96e7-fbcaf984b709 - Root Partition (x86-64) - On 64-bit x86 systems, the first x86-64 root partition on the disk the EFI ESP is located on is mounted to the root directory /. - - - 69dad710-2ce4-4e3c-b16c-21a1d49abed3 - Root Partition (32-bit ARM) - On 32-bit ARM systems, the first ARM root partition on the disk the EFI ESP is located on is mounted to the root directory /. - - - b921b045-1df0-41c3-af44-4c6f280d3fae - Root Partition (64-bit ARM) - On 64-bit ARM systems, the first ARM root partition on the disk the EFI ESP is located on is mounted to the root directory /. - - - 933ac7e1-2eb4-4f13-b844-0e14e2aef915 - Home Partition - The first home partition on the disk the root partition is located on is mounted to /home. - - - 3b8f8425-20e0-4f3b-907f-1a25a76f98e8 - Server Data Partition - The first server data partition on the disk the root partition is located on is mounted to /srv. - - - 0657fd6d-a4ab-43c4-84e5-0933c84b4f4f - Swap - All swap partitions located on the disk the root partition is located on are enabled. - - - -
- - The /home and - /srv partitions may be encrypted - in LUKS format. In this case a device mapper device is - set up under the names - /dev/mapper/home and - /dev/mapper/srv. Note that this - might create conflicts if the same partition is listed - in /etc/crypttab with a different - device mapper device name. - - Also note that - systemd-efi-boot-generator8 - will mount the EFI System Partition (ESP) to - /boot if not otherwise mounted. - - When using this generator in conjunction with - btrfs file systems, make sure to set the correct - default subvolumes on them, using btrfs - subvolume set-default. - - systemd-gpt-auto-generator - implements the Generator - Specification. - - - - See Also - - systemd1, - systemd.mount5, - systemd.swap5, - systemd-fstab-generator8, - systemd-efi-boot-generator8, - systemd-cryptsetup@.service8, - cryptsetup8, - fstab5, - btrfs8 - - + + systemd-gpt-auto-generator + systemd + + + + Developer + Lennart + Poettering + lennart@poettering.net + + + + + + systemd-gpt-auto-generator + 8 + + + + systemd-gpt-auto-generator + Generator for automatically discovering + and mounting root, /home and + /srv partitions, as well as + discovering and enabling swap partitions, based on GPT + partition type GUIDs. + + + + /usr/lib/systemd/system-generators/systemd-gpt-auto-generator + + + + Description + + systemd-gpt-auto-generator is a unit + generator that automatically discovers root, + /home, /srv and swap + partitions and creates mount and swap units for them, based on the + partition type GUIDs of GUID partition tables (GPT). It implements + the + Discoverable + Partitions Specification. Note that this generator has no + effect on non-GPT systems, on systems where the units are + explicitly configured (for example, listed in + fstab5), + or where the mount points are non-empty. + + This generator will only look for root partitions on the + same physical disk the EFI System Partition (ESP) is located on. + It will only look for the other partitions on the same physical + disk the root file system is located on. These partitions will not + be searched on systems where the root file system is distributed + on multiple disks, for example via btrfs RAID. + + systemd-gpt-auto-generator is useful + for centralizing file system configuration in the partition table + and making manual configuration in /etc/fstab + or suchlike unnecessary. + + This generator looks for the partitions based on their + partition type GUID. The following partition type GUIDs are + identified: + + + Partition Type GUIDs + + + + + + + Partition Type GUID + Name + Explanation + + + + + 44479540-f297-41b2-9af7-d131d5f0458a + Root Partition (x86) + On 32-bit x86 systems, the first x86 root partition on the disk the EFI ESP is located on is mounted to the root directory /. + + + 4f68bce3-e8cd-4db1-96e7-fbcaf984b709 + Root Partition (x86-64) + On 64-bit x86 systems, the first x86-64 root partition on the disk the EFI ESP is located on is mounted to the root directory /. + + + 69dad710-2ce4-4e3c-b16c-21a1d49abed3 + Root Partition (32-bit ARM) + On 32-bit ARM systems, the first ARM root partition on the disk the EFI ESP is located on is mounted to the root directory /. + + + b921b045-1df0-41c3-af44-4c6f280d3fae + Root Partition (64-bit ARM) + On 64-bit ARM systems, the first ARM root partition on the disk the EFI ESP is located on is mounted to the root directory /. + + + 933ac7e1-2eb4-4f13-b844-0e14e2aef915 + Home Partition + The first home partition on the disk the root partition is located on is mounted to /home. + + + 3b8f8425-20e0-4f3b-907f-1a25a76f98e8 + Server Data Partition + The first server data partition on the disk the root partition is located on is mounted to /srv. + + + 0657fd6d-a4ab-43c4-84e5-0933c84b4f4f + Swap + All swap partitions located on the disk the root partition is located on are enabled. + + + +
+ + The /home and /srv + partitions may be encrypted in LUKS format. In this case a device + mapper device is set up under the names + /dev/mapper/home and + /dev/mapper/srv. Note that this might create + conflicts if the same partition is listed in + /etc/crypttab with a different device mapper + device name. + + Also note that + systemd-efi-boot-generator8 + will mount the EFI System Partition (ESP) to + /boot if not otherwise mounted. + + When using this generator in conjunction with btrfs file + systems, make sure to set the correct default subvolumes on them, + using btrfs subvolume set-default. + + systemd-gpt-auto-generator implements + the + Generator + Specification. + + + + See Also + + systemd1, + systemd.mount5, + systemd.swap5, + systemd-fstab-generator8, + systemd-efi-boot-generator8, + systemd-cryptsetup@.service8, + cryptsetup8, + fstab5, + btrfs8 + + diff --git a/man/systemd-halt.service.xml b/man/systemd-halt.service.xml index 552dbdf687a..c94e2a18208 100644 --- a/man/systemd-halt.service.xml +++ b/man/systemd-halt.service.xml @@ -1,6 +1,6 @@ + "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd"> - - systemd-hibernate-resume-generator - systemd - - - - Developer - Ivan - Shapovalov - intelfx100@gmail.com - - - - - - systemd-hibernate-resume-generator - 8 - - - - systemd-hibernate-resume-generator - Unit generator for resume= kernel parameter - - - - /usr/lib/systemd/system-generators/systemd-hibernate-resume-generator - - - - Description - - systemd-hibernate-resume-generator is - a generator that instantiates - systemd-hibernate-resume@.service8 - unit according to the value of - parameter specified on the kernel command line. - - - - Kernel Command Line - - systemd-hibernate-resume-generator understands - the following kernel command line parameters: - - - - - resume= - - Takes a path to the resume - device. Both persistent block device paths like - /dev/disk/by-foo/bar and - fstab5-style - specifiers like FOO=bar - are supported. - - - - - - - See Also - - systemd1, - systemd-hibernate-resume@.service8, - kernel-command-line7 - - + + systemd-hibernate-resume-generator + systemd + + + + Developer + Ivan + Shapovalov + intelfx100@gmail.com + + + + + + systemd-hibernate-resume-generator + 8 + + + + systemd-hibernate-resume-generator + Unit generator for resume= kernel parameter + + + + /usr/lib/systemd/system-generators/systemd-hibernate-resume-generator + + + + Description + + systemd-hibernate-resume-generator is a + generator that instantiates + systemd-hibernate-resume@.service8 + unit according to the value of parameter + specified on the kernel command line. + + + + Kernel Command Line + + systemd-hibernate-resume-generator + understands the following kernel command line parameters: + + + + + resume= + + Takes a path to the resume device. Both + persistent block device paths like + /dev/disk/by-foo/bar and + fstab5-style + specifiers like FOO=bar are + supported. + + + + + + + See Also + + systemd1, + systemd-hibernate-resume@.service8, + kernel-command-line7 + + diff --git a/man/systemd-hibernate-resume@.service.xml b/man/systemd-hibernate-resume@.service.xml index 30bfd881015..7d008274478 100644 --- a/man/systemd-hibernate-resume@.service.xml +++ b/man/systemd-hibernate-resume@.service.xml @@ -21,62 +21,61 @@ --> - - systemd-hibernate-resume@.service - systemd + + systemd-hibernate-resume@.service + systemd - - - Developer - Ivan - Shapovalov - intelfx100@gmail.com - - - + + + Developer + Ivan + Shapovalov + intelfx100@gmail.com + + + - - systemd-hibernate-resume@.service - 8 - + + systemd-hibernate-resume@.service + 8 + - - systemd-hibernate-resume@.service - systemd-hibernate-resume - Resume from hibernation - + + systemd-hibernate-resume@.service + systemd-hibernate-resume + Resume from hibernation + - - systemd-hibernate-resume@.service - /usr/lib/systemd/systemd-hibernate-resume - + + systemd-hibernate-resume@.service + /usr/lib/systemd/systemd-hibernate-resume + - - Description + + Description - systemd-hibernate-resume@.service - initiates the resume from hibernation. It is - instantiated with the device to resume from as the - template argument. + systemd-hibernate-resume@.service + initiates the resume from hibernation. It is instantiated with the + device to resume from as the template argument. - systemd-hibernate-resume only supports - the in-kernel hibernation implementation, known as - swsusp. - Internally, it works by writing the major:minor of specified - device node to /sys/power/resume. + systemd-hibernate-resume only supports + the in-kernel hibernation implementation, known as + swsusp. + Internally, it works by writing the major:minor of specified + device node to /sys/power/resume. - Failing to initiate a resume is not an error condition. - It may mean that there was no resume image (e. g. if the - system has been simply powered off and not hibernated). In - such case, the boot is ordinarily continued. - + Failing to initiate a resume is not an error condition. It + may mean that there was no resume image (e. g. if the system has + been simply powered off and not hibernated). In such case, the + boot is ordinarily continued. + - - See Also - - systemd1, - systemd-hibernate-resume-generator8 - - + + See Also + + systemd1, + systemd-hibernate-resume-generator8 + + diff --git a/man/systemd-hostnamed.service.xml b/man/systemd-hostnamed.service.xml index 7952d8a6cb0..6990d41b020 100644 --- a/man/systemd-hostnamed.service.xml +++ b/man/systemd-hostnamed.service.xml @@ -1,6 +1,6 @@ + "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd"> + "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd"> - - - systemd-inhibit - systemd - - - - Developer - Lennart - Poettering - lennart@poettering.net - - - - - - systemd-inhibit - 1 - - - - systemd-inhibit - Execute a program with an inhibition lock taken - - - - - systemd-inhibit OPTIONS COMMAND ARGUMENTS - - - systemd-inhibit OPTIONS --list - - - - - Description - - systemd-inhibit may be used - to execute a program with a shutdown, sleep or idle - inhibitor lock taken. The lock will be acquired before - the specified command line is executed and released - afterwards. - - Inhibitor locks may be used to block or delay - system sleep and shutdown requests from the user, as well - as automatic idle handling of the OS. This is useful - to avoid system suspends while an optical disc is - being recorded, or similar operations that should not - be interrupted. - - For more information see the Inhibitor - Lock Developer Documentation. - - - - Options - - The following options are understood: - - - - - - Takes a colon-separated - list of one or more - operations to inhibit: - shutdown, - sleep, - idle, - handle-power-key, - handle-suspend-key, - handle-hibernate-key, - handle-lid-switch, - for inhibiting - reboot/power-off/halt/kexec, - suspending/hibernating, the automatic - idle detection, or the low-level - handling of the power/sleep key and - the lid switch, respectively. If omitted, - defaults to - idle:sleep:shutdown. - - - - - - Takes a short, - human-readable descriptive string for the - program taking the lock. If not passed, - defaults to the command line - string. - - - - - - Takes a short, - human-readable descriptive string for the - reason for taking the lock. Defaults - to "Unknown reason". - - - - - - Takes either - block or - delay and describes - how the lock is applied. If - block is used (the - default), the lock prohibits any of - the requested operations without time - limit, and only privileged users may - override it. If - delay is used, the - lock can only delay the requested - operations for a limited time. If the - time elapses, the lock is ignored and - the operation executed. The time limit - may be specified in - logind.conf5. Note - that delay is only - available for sleep - and - shutdown. - - - - - - Lists all active - inhibition locks instead of acquiring - one. - - - - - - - - - - Exit status - - Returns the exit status of the executed program. - - - - Example - - # systemd-inhibit wodim foobar.iso - - This burns the ISO image - foobar.iso on a CD using - wodim1, - and inhibits system sleeping, shutdown and idle while - doing so. - - - - See Also - - systemd1, - logind.conf5 - - + xmlns:xi="http://www.w3.org/2001/XInclude"> + + + systemd-inhibit + systemd + + + + Developer + Lennart + Poettering + lennart@poettering.net + + + + + + systemd-inhibit + 1 + + + + systemd-inhibit + Execute a program with an inhibition lock taken + + + + + systemd-inhibit OPTIONS COMMAND ARGUMENTS + + + systemd-inhibit OPTIONS --list + + + + + Description + + systemd-inhibit may be used to execute a + program with a shutdown, sleep or idle inhibitor lock taken. The + lock will be acquired before the specified command line is + executed and released afterwards. + + Inhibitor locks may be used to block or delay system sleep + and shutdown requests from the user, as well as automatic idle + handling of the OS. This is useful to avoid system suspends while + an optical disc is being recorded, or similar operations that + should not be interrupted. + + For more information see the Inhibitor + Lock Developer Documentation. + + + + Options + + The following options are understood: + + + + + + Takes a colon-separated list of one or more + operations to inhibit: + shutdown, + sleep, + idle, + handle-power-key, + handle-suspend-key, + handle-hibernate-key, + handle-lid-switch, + for inhibiting reboot/power-off/halt/kexec, + suspending/hibernating, the automatic idle detection, or the + low-level handling of the power/sleep key and the lid switch, + respectively. If omitted, defaults to + idle:sleep:shutdown. + + + + + + Takes a short, human-readable descriptive + string for the program taking the lock. If not passed, + defaults to the command line string. + + + + + + Takes a short, human-readable descriptive + string for the reason for taking the lock. Defaults to + "Unknown reason". + + + + + + Takes either block or + delay and describes how the lock is + applied. If block is used (the default), + the lock prohibits any of the requested operations without + time limit, and only privileged users may override it. If + delay is used, the lock can only delay the + requested operations for a limited time. If the time elapses, + the lock is ignored and the operation executed. The time limit + may be specified in + logind.conf5. + Note that delay is only available for + sleep and + shutdown. + + + + + + Lists all active inhibition locks instead of + acquiring one. + + + + + + + + + + Exit status + + Returns the exit status of the executed program. + + + + Example + + # systemd-inhibit wodim foobar.iso + + This burns the ISO image + foobar.iso on a CD using + wodim1, + and inhibits system sleeping, shutdown and idle while + doing so. + + + + See Also + + systemd1, + logind.conf5 + + diff --git a/man/systemd-initctl.service.xml b/man/systemd-initctl.service.xml index eda6459b508..5c7f9a4a163 100644 --- a/man/systemd-initctl.service.xml +++ b/man/systemd-initctl.service.xml @@ -1,6 +1,6 @@ + "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd"> + "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd"> + "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd"> + "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd"> - - systemd-machine-id-commit.service - systemd - - - - Developer - Didier - Roche - didrocks@ubuntu.com - - - - - - systemd-machine-id-commit.service - 8 - - - - systemd-machine-id-commit.service - Commit transient machine-id to disk - - - - systemd-machine-id-commit.service - /usr/lib/systemd/systemd-machine-id-commit - - - - Description - - systemd-machine-id-commit.service is - a service responsible for committing any transient - /etc/machine-id file to a writable file - system. See - machine-id5 - for more information about this file. - - This service is started shortly after - local-fs.target if - /etc/machine-id is an independent mount - point (probably a tmpfs one) and /etc is writable. - systemd-machine-id-commit will then - write current machine ID to disk and unmount the transient - /etc/machine-id file in a race-free - manner to ensure that file is always valid for other - processes. - - Note that the traditional way to initialize the machine - ID in /etc/machine-id is to use - systemd-machine-id-setup by system - installer tools. You can also use - systemd-firstboot1 - to initialize the machine ID on mounted (but not - booted) system images. The main use case for that service is - /etc/machine-id being an empty file at - boot and initrd chaining to systemd giving it a read only file - system that will be turned read-write later during the boot - process. - - There is no consequence if that service fails other than - a newer machine-id will be generated during next system boot. - - - - - See Also - - systemd1, - systemd-machine-id-commit1, - systemd-machine-id-setup1, - machine-id5, - systemd-firstboot1 - - + + systemd-machine-id-commit.service + systemd + + + + Developer + Didier + Roche + didrocks@ubuntu.com + + + + + + systemd-machine-id-commit.service + 8 + + + + systemd-machine-id-commit.service + Commit transient machine-id to disk + + + + systemd-machine-id-commit.service + /usr/lib/systemd/systemd-machine-id-commit + + + + Description + + systemd-machine-id-commit.service is a + service responsible for committing any transient + /etc/machine-id file to a writable file + system. See + machine-id5 + for more information about this file. + + This service is started shortly after + local-fs.target if + /etc/machine-id is an independent mount point + (probably a tmpfs one) and /etc is writable. + systemd-machine-id-commit will then write + current machine ID to disk and unmount the transient + /etc/machine-id file in a race-free manner to + ensure that file is always valid for other processes. + + Note that the traditional way to initialize the machine ID + in /etc/machine-id is to use + systemd-machine-id-setup by system installer + tools. You can also use + systemd-firstboot1 + to initialize the machine ID on mounted (but not booted) system + images. The main use case for that service is + /etc/machine-id being an empty file at boot + and initrd chaining to systemd giving it a read only file system + that will be turned read-write later during the boot + process. + + There is no consequence if that service fails other than a + newer machine-id will be generated during next system boot. + + + + + See Also + + systemd1, + systemd-machine-id-commit1, + systemd-machine-id-setup1, + machine-id5, + systemd-firstboot1 + + diff --git a/man/systemd-machine-id-commit.xml b/man/systemd-machine-id-commit.xml index ed2a6d0bd7e..cfb1722063d 100644 --- a/man/systemd-machine-id-commit.xml +++ b/man/systemd-machine-id-commit.xml @@ -1,6 +1,6 @@ + "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd"> - - - systemd-machine-id-commit - systemd - - - - Developer - Didier - Roche - didrocks@ubuntu.com - - - - - - systemd-machine-id-commit - 1 - - - - systemd-machine-id-commit - Commit transient machine ID to /etc/machine-id - - - - - systemd-machine-id-commit - - - - - Description - - systemd-machine-id-commit may - be used to write on disk any transient machine ID - mounted as a temporary file system in - /etc/machine-id at boot time. See - machine-id5 - for more information about this file. - - This tool will execute no operation if - /etc/machine-id doesn't contain any - valid machine ID, isn't mounted as an independent temporary - file system, of /etc is read-only. If - those conditions are met, it will then write current machine ID - to disk and unmount the transient - /etc/machine-id file in a race-free - manner to ensure that this file is always valid for other - processes. - - Note that the traditional way to initialize the machine - ID in /etc/machine-id is to use - systemd-machine-id-setup by system - installer tools. You can also use - systemd-firstboot1 - to initialize the machine ID on mounted (but not - booted) system images. - - - - Options - - The following options are understood: - - - - - Takes a directory path - as an argument. All paths will be - prefixed with the given alternate - root path, - including config search paths. - - - - - - - - - - Exit status - - On success, 0 is returned, a non-zero failure - code otherwise. - - - - See Also - - systemd1, - systemd-machine-id-commit.service8, - systemd-machine-id-setup1, - machine-id5, - systemd-firstboot1 - - + xmlns:xi="http://www.w3.org/2001/XInclude"> + + + systemd-machine-id-commit + systemd + + + + Developer + Didier + Roche + didrocks@ubuntu.com + + + + + + systemd-machine-id-commit + 1 + + + + systemd-machine-id-commit + Commit transient machine ID to /etc/machine-id + + + + + systemd-machine-id-commit + + + + + Description + + systemd-machine-id-commit may be used to + write on disk any transient machine ID mounted as a temporary file + system in /etc/machine-id at boot time. See + machine-id5 + for more information about this file. + + This tool will execute no operation if + /etc/machine-id doesn't contain any valid + machine ID, isn't mounted as an independent temporary file system, + of /etc is read-only. If those conditions are + met, it will then write current machine ID to disk and unmount the + transient /etc/machine-id file in a race-free + manner to ensure that this file is always valid for other + processes. + + Note that the traditional way to initialize the machine ID + in /etc/machine-id is to use + systemd-machine-id-setup by system installer + tools. You can also use + systemd-firstboot1 + to initialize the machine ID on mounted (but not booted) system + images. + + + + Options + + The following options are understood: + + + + + Takes a directory path + as an argument. All paths will be + prefixed with the given alternate + root path, + including config search paths. + + + + + + + + + + Exit status + + On success, 0 is returned, a non-zero failure code + otherwise. + + + + See Also + + systemd1, + systemd-machine-id-commit.service8, + systemd-machine-id-setup1, + machine-id5, + systemd-firstboot1 + + diff --git a/man/systemd-machine-id-setup.xml b/man/systemd-machine-id-setup.xml index 28352e357f9..22bad3e5f4b 100644 --- a/man/systemd-machine-id-setup.xml +++ b/man/systemd-machine-id-setup.xml @@ -1,6 +1,6 @@ + "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd"> - - - systemd-machine-id-setup - systemd - - - - Developer - Lennart - Poettering - lennart@poettering.net - - - - - - systemd-machine-id-setup - 1 - - - - systemd-machine-id-setup - Initialize the machine ID in /etc/machine-id - - - - - systemd-machine-id-setup - - - - - Description - - systemd-machine-id-setup may - be used by system installer tools to initialize the - machine ID stored in - /etc/machine-id at install time - with a randomly generated ID. See - machine-id5 - for more information about this file. - - This tool will execute no operation if - /etc/machine-id is already - initialized. - - If a valid D-Bus machine ID is already - configured for the system, the D-Bus machine ID is - copied and used to initialize the machine ID in - /etc/machine-id. - - If run inside a KVM virtual machine and a UUID - is passed via the option, this - UUID is used to initialize the machine ID instead of a - randomly generated one. The caller must ensure that the - UUID passed is sufficiently unique and is different - for every booted instanced of the VM. - - Similar, if run inside a Linux container - environment and a UUID is set for the container this - is used to initialize the machine ID. For details see - the documentation of the Container - Interface. - - Use - systemd-firstboot1 - to initialize the machine ID on mounted (but not - booted) system images. - - - - - Options - - The following options are understood: - - - - - Takes a directory path - as an argument. All paths will be - prefixed with the given alternate - root path, - including config search paths. - - - - - - - - - - Exit status - - On success, 0 is returned, a non-zero failure - code otherwise. - - - - See Also - - systemd1, - machine-id5, - dbus-uuidgen1, - systemd-firstboot1 - - + xmlns:xi="http://www.w3.org/2001/XInclude"> + + + systemd-machine-id-setup + systemd + + + + Developer + Lennart + Poettering + lennart@poettering.net + + + + + + systemd-machine-id-setup + 1 + + + + systemd-machine-id-setup + Initialize the machine ID in /etc/machine-id + + + + + systemd-machine-id-setup + + + + + Description + + systemd-machine-id-setup may be used by + system installer tools to initialize the machine ID stored in + /etc/machine-id at install time with a + randomly generated ID. See + machine-id5 + for more information about this file. + + This tool will execute no operation if + /etc/machine-id is already + initialized. + + If a valid D-Bus machine ID is already configured for the + system, the D-Bus machine ID is copied and used to initialize the + machine ID in /etc/machine-id. + + If run inside a KVM virtual machine and a UUID is passed via + the option, this UUID is used to initialize + the machine ID instead of a randomly generated one. The caller + must ensure that the UUID passed is sufficiently unique and is + different for every booted instanced of the VM. + + Similar, if run inside a Linux container environment and a + UUID is set for the container this is used to initialize the + machine ID. For details see the documentation of the Container + Interface. + + Use + systemd-firstboot1 + to initialize the machine ID on mounted (but not booted) system + images. + + + + + Options + + The following options are understood: + + + + + Takes a directory path as an argument. All + paths will be prefixed with the given alternate + root path, including config search + paths. + + + + + + + + + Exit status + + On success, 0 is returned, a non-zero failure code + otherwise. + + + + See Also + + systemd1, + machine-id5, + dbus-uuidgen1, + systemd-firstboot1 + + diff --git a/man/systemd-machined.service.xml b/man/systemd-machined.service.xml index 475b53a86e6..999aeee1c6d 100644 --- a/man/systemd-machined.service.xml +++ b/man/systemd-machined.service.xml @@ -1,6 +1,6 @@ + "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd"> - - systemd-modules-load.service - systemd - - - - Developer - Lennart - Poettering - lennart@poettering.net - - - - - - systemd-modules-load.service - 8 - - - - systemd-modules-load.service - systemd-modules-load - Load kernel modules at boot - - - - systemd-modules-load.service - /usr/lib/systemd/systemd-modules-load - - - - Description - - systemd-modules-load.service - is an early-boot service that loads kernel modules - based on static configuration. - - See - modules-load.d5 - for information about the configuration of this - service. - - - - - Kernel Command Line - - systemd-modules-load.service understands - the following kernel command line parameters: - - - - - modules-load= - rd.modules-load= - - Takes a comma-separated - list of kernel modules to - statically load during early boot. The - option prefixed with - rd. is read by the - initial RAM disk - only. - - - - - - - See Also - - systemd1, - modules-load.d5, - - + + systemd-modules-load.service + systemd + + + + Developer + Lennart + Poettering + lennart@poettering.net + + + + + + systemd-modules-load.service + 8 + + + + systemd-modules-load.service + systemd-modules-load + Load kernel modules at boot + + + + systemd-modules-load.service + /usr/lib/systemd/systemd-modules-load + + + + Description + + systemd-modules-load.service is an + early-boot service that loads kernel modules based on static + configuration. + + See + modules-load.d5 + for information about the configuration of this service. + + + + + Kernel Command Line + + systemd-modules-load.service + understands the following kernel command line parameters: + + + + + modules-load= + rd.modules-load= + + Takes a comma-separated list of kernel modules + to statically load during early boot. The option prefixed with + rd. is read by the initial RAM disk + only. + + + + + + + See Also + + systemd1, + modules-load.d5, + + diff --git a/man/systemd-networkd-wait-online.service.xml b/man/systemd-networkd-wait-online.service.xml index 4f039fedc7b..f53b337daab 100644 --- a/man/systemd-networkd-wait-online.service.xml +++ b/man/systemd-networkd-wait-online.service.xml @@ -1,6 +1,6 @@ + "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd"> + "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd"> + "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd"> - - - systemd-notify - systemd - - - - Developer - Lennart - Poettering - lennart@poettering.net - - - - - - systemd-notify - 1 - - - - systemd-notify - Notify service manager about start-up completion and other daemon status changes - - - - - systemd-notify OPTIONS VARIABLE=VALUE - - - - - Description - - systemd-notify may be - called by daemon scripts to notify the init system - about status changes. It can be used to send arbitrary - information, encoded in an environment-block-like list - of strings. Most importantly it can be used for - start-up completion notification. - - This is mostly just a wrapper around - sd_notify() and makes this - functionality available to shell scripts. For details - see - sd_notify3. - - The command line may carry a list of - environment variables to send as part of the status - update. - - Note that systemd will refuse reception of - status updates from this command unless - NotifyAccess=all is set for the - service unit this command is called from. - - - - - Options - - The following options are understood: - - - - - - Inform the init system - about service start-up - completion. This is equivalent to - systemd-notify - READY=1. For details about - the semantics of this option see - sd_notify3. - - - - - - Inform the init system - about the main PID of the - daemon. Takes a PID as argument. If - the argument is omitted, the PID of the - process that invoked - systemd-notify is - used. This is equivalent to - systemd-notify - MAINPID=$PID. For details - about the semantics of this option see - sd_notify3. - - - - - - Send a free-form - status string for the daemon to the - init systemd. This option takes the - status string as argument. This is - equivalent to systemd-notify - STATUS=.... For details - about the semantics of this option see - sd_notify3. - - - - - - Returns 0 if the - system was booted up with systemd, - non-zero otherwise. If this option is - passed, no message is sent. This option - is hence unrelated to the other - options. For details about the - semantics of this option, see - sd_booted3. - - - - - - - - - - Exit status - - On success, 0 is returned, a non-zero failure - code otherwise. - - - - Example - - - Start-up Notification and Status Updates - - A simple shell daemon that sends - start-up notifications after having set up its - communication channel. During runtime it sends - further status updates to the init - system: - - #!/bin/bash + xmlns:xi="http://www.w3.org/2001/XInclude"> + + + systemd-notify + systemd + + + + Developer + Lennart + Poettering + lennart@poettering.net + + + + + + systemd-notify + 1 + + + + systemd-notify + Notify service manager about start-up completion and other daemon status changes + + + + + systemd-notify OPTIONS VARIABLE=VALUE + + + + + Description + + systemd-notify may be called by daemon + scripts to notify the init system about status changes. It can be + used to send arbitrary information, encoded in an + environment-block-like list of strings. Most importantly it can be + used for start-up completion notification. + + This is mostly just a wrapper around + sd_notify() and makes this functionality + available to shell scripts. For details see + sd_notify3. + + + The command line may carry a list of environment variables + to send as part of the status update. + + Note that systemd will refuse reception of status updates + from this command unless NotifyAccess=all is + set for the service unit this command is called from. + + + + + Options + + The following options are understood: + + + + + + Inform the init system about service start-up + completion. This is equivalent to systemd-notify + READY=1. For details about the semantics of this + option see + sd_notify3. + + + + + + Inform the init system about the main PID of + the daemon. Takes a PID as argument. If the argument is + omitted, the PID of the process that invoked + systemd-notify is used. This is equivalent + to systemd-notify MAINPID=$PID. For details + about the semantics of this option see + sd_notify3. + + + + + + Send a free-form status string for the daemon + to the init systemd. This option takes the status string as + argument. This is equivalent to systemd-notify + STATUS=.... For details about the semantics of this + option see + sd_notify3. + + + + + + Returns 0 if the system was booted up with + systemd, non-zero otherwise. If this option is passed, no + message is sent. This option is hence unrelated to the other + options. For details about the semantics of this option, see + sd_booted3. + + + + + + + + + + Exit status + + On success, 0 is returned, a non-zero failure code + otherwise. + + + + Example + + + Start-up Notification and Status Updates + + A simple shell daemon that sends start-up notifications + after having set up its communication channel. During runtime it + sends further status updates to the init system: + + #!/bin/bash mkfifo /tmp/waldo systemd-notify --ready --status="Waiting for data..." while : ; do - read a < /tmp/waldo - systemd-notify --status="Processing $a" + read a < /tmp/waldo + systemd-notify --status="Processing $a" - # Do something with $a ... + # Do something with $a ... - systemd-notify --status="Waiting for data..." + systemd-notify --status="Waiting for data..." done - - - - - See Also - - systemd1, - systemctl1, - systemd.unit5, - sd_notify3, - sd_booted3 - - + + + + + See Also + + systemd1, + systemctl1, + systemd.unit5, + sd_notify3, + sd_booted3 + + diff --git a/man/systemd-nspawn.xml b/man/systemd-nspawn.xml index 4b7ec1d3911..4a936d326f9 100644 --- a/man/systemd-nspawn.xml +++ b/man/systemd-nspawn.xml @@ -1,6 +1,6 @@ + "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd"> - - - systemd-nspawn - systemd - - - - Developer - Lennart - Poettering - lennart@poettering.net - - - - - - systemd-nspawn - 1 - - - - systemd-nspawn - Spawn a namespace container for debugging, testing and building - - - - - systemd-nspawn - OPTIONS - COMMAND - ARGS - - - - systemd-nspawn - -b - OPTIONS - ARGS - - - - - Description - - systemd-nspawn may be used to - run a command or OS in a light-weight namespace - container. In many ways it is similar to - chroot1, - but more powerful since it fully virtualizes the file - system hierarchy, as well as the process tree, the - various IPC subsystems and the host and domain - name. - - systemd-nspawn limits access - to various kernel interfaces in the container to - read-only, such as /sys, - /proc/sys or - /sys/fs/selinux. Network - interfaces and the system clock may not be changed - from within the container. Device nodes may not be - created. The host system cannot be rebooted and kernel - modules may not be loaded from within the - container. - - Note that even though these security precautions - are taken systemd-nspawn is not - suitable for secure container setups. Many of the - security features may be circumvented and are hence - primarily useful to avoid accidental changes to the - host system from the container. The intended use of - this program is debugging and testing as well as - building of packages, distributions and software - involved with boot and systems management. - - In contrast to - chroot1 systemd-nspawn - may be used to boot full Linux-based operating systems - in a container. - - Use a tool like - dnf8, - yum8, - debootstrap8, - or - pacman8 - to set up an OS directory tree suitable as file system - hierarchy for systemd-nspawn - containers. - - Note that systemd-nspawn will - mount file systems private to the container to - /dev, - /run and similar. These will - not be visible outside of the container, and their - contents will be lost when the container exits. - - Note that running two - systemd-nspawn containers from the - same directory tree will not make processes in them - see each other. The PID namespace separation of the - two containers is complete and the containers will - share very few runtime objects except for the - underlying file system. Use - machinectl1's - login command to request an - additional login prompt in a running container. - - systemd-nspawn implements the - Container - Interface specification. - - As a safety check - systemd-nspawn will verify the - existence of /usr/lib/os-release - or /etc/os-release in the - container tree before starting the container (see - os-release5). It - might be necessary to add this file to the container - tree manually if the OS of the container is too old to - contain this file out-of-the-box. - - - - Options - - If option is specified, the - arguments are used as arguments for the init - binary. Otherwise, COMMAND - specifies the program to launch in the container, and - the remaining arguments are used as arguments for this - program. If is not used and no - arguments are specifed, a shell is launched in the - container. - - The following options are understood: - - - - - - - Directory to use as - file system root for the container. - - If neither - , nor - is specified - the directory is determined as - /var/lib/machines/ - suffixed by the machine name as - specified with - . If - neither , - , nor - are - specified, the current directory will - be used. May not be specified together - with - . - - - - - - Directory or - btrfs subvolume to - use as template for the container's - root directory. If this is specified - and the container's root directory (as - configured by - ) does - not yet exist it is created as - btrfs subvolume and - populated from this template - tree. Ideally, the specified template - path refers to the root of a - btrfs subvolume, in - which case a simple copy-on-write - snapshot is taken, and populating the - root directory is instant. If the - specified template path does not refer - to the root of a - btrfs subvolume (or - not even to a btrfs - file system at all), the tree is - copied, which can be substantially - more time-consuming. Note that if this - option is used the container's root - directory (in contrast to the template - directory!) must be located on a - btrfs file system, - so that the btrfs - subvolume may be created. May not be - specified together with - or - . - - - - - - - If specified, the - container is run with a temporary - btrfs snapshot of - its root directory (as configured with - ), that - is removed immediately when the - container terminates. This option is - only supported if the root file system - is btrfs. May not - be specified together with - or - . - - - - - - - Disk image to mount - the root directory for the container - from. Takes a path to a regular file - or to a block device node. The file or - block device must contain either: - - - An MBR - partition table with a single - partition of type 0x83 that is - marked - bootable. - - A GUID - partition table (GPT) with a single - partition of type - 0fc63daf-8483-4772-8e79-3d69d8477de4. - - A GUID - partition table (GPT) with a - marked root partition which is - mounted as the root directory - of the container. Optionally, - GPT images may contain a home - and/or a server data partition - which are mounted to the - appropriate places in the - container. All these - partitions must be identified - by the partition types defined - by the Discoverable - Partitions - Specification. - - - Any other partitions, such as - foreign partitions, swap partitions or - EFI system partitions are not - mounted. May not be specified together - with , - or - . - - - - - - - Automatically search - for an init binary and invoke it - instead of a shell or a user supplied - program. If this option is used, - arguments specified on the command - line are used as arguments for the - init binary. This option may not be - combined with - . - - - - - - - - After transitioning - into the container, change to the - specified user-defined in the - container's user database. Like all - other systemd-nspawn features, this is - not a security feature and provides - protection against accidental - destructive operations - only. - - - - - - - Sets the machine name - for this container. This name may be - used to identify this container during - its runtime (for example in tools like - machinectl1 - and similar), and is used to - initialize the container's hostname - (which the container can choose to - override, however). If not specified, - the last component of the root - directory path of the container is - used, possibly suffixed with a random - identifier in case - mode is - selected. If the root directory - selected is the host's root directory - the host's hostname is used as default - instead. - - - - - - Set the specified UUID - for the container. The init system - will initialize - /etc/machine-id - from this if this file is not set yet. - - - - - - - Make the container - part of the specified slice, instead - of the default - machine.slice. - - - - - - - Disconnect networking - of the container from the host. This - makes all network interfaces - unavailable in the container, with the - exception of the loopback device and - those specified with - - and configured with - . If - this option is specified, the - CAP_NET_ADMIN capability will be added - to the set of capabilities the - container retains. The latter may be - disabled by using - . - - - - - - Assign the specified - network interface to the - container. This will remove the - specified interface from the calling - namespace and place it in the - container. When the container - terminates, it is moved back to the - host namespace. Note that - - implies - . This - option may be used more than once to - add multiple network interfaces to the - container. - - - - - - Create a - macvlan interface - of the specified Ethernet network - interface and add it to the - container. A - macvlan interface - is a virtual interface that adds a - second MAC address to an existing - physical Ethernet link. The interface - in the container will be named after - the interface on the host, prefixed - with mv-. Note that - - implies - . This - option may be used more than once to - add multiple network interfaces to the - container. - - - - - - Create an - ipvlan interface - of the specified Ethernet network - interface and add it to the - container. An - ipvlan interface - is a virtual interface, similar to a - macvlan interface, which - uses the same MAC address as the underlying - interface. The interface - in the container will be named after - the interface on the host, prefixed - with iv-. Note that - - implies - . This - option may be used more than once to - add multiple network interfaces to the - container. - - - - - - - Create a virtual - Ethernet link - (veth) between host - and container. The host side of the - Ethernet link will be available as a - network interface named after the - container's name (as specified with - ), prefixed - with ve-. The - container side of the Ethernet - link will be named - host0. Note that - - implies - . - - - - - - Adds the host side of - the Ethernet link created with - to the - specified bridge. Note that - - implies - . If - this option is used, the host side of - the Ethernet link will use the - vb- prefix instead - of ve-. - - - - - - - If private networking - is enabled, maps an IP port on the - host onto an IP port on the - container. Takes a protocol specifier - (either tcp or - udp), separated by - a colon from a host port number in the - range 1 to 65535, separated by a colon - from a container port number in the - range from 1 to 65535. The protocol - specifier and its separating colon may - be omitted, in which case - tcp is assumed. - The container port number and its - colon may be ommitted, in which case - the same port as the host port is - implied. This option is only supported - if private networking is used, such as - or - . - - - - - - - Sets the SELinux - security context to be used to label - processes in the container. - - - - - - - - Sets the SELinux security - context to be used to label files in - the virtual API file systems in the - container. - - - - - - - List one or more - additional capabilities to grant the - container. Takes a comma-separated - list of capability names, see - capabilities7 - for more information. Note that the - following capabilities will be granted - in any way: CAP_CHOWN, - CAP_DAC_OVERRIDE, CAP_DAC_READ_SEARCH, - CAP_FOWNER, CAP_FSETID, CAP_IPC_OWNER, - CAP_KILL, CAP_LEASE, - CAP_LINUX_IMMUTABLE, - CAP_NET_BIND_SERVICE, - CAP_NET_BROADCAST, CAP_NET_RAW, - CAP_SETGID, CAP_SETFCAP, CAP_SETPCAP, - CAP_SETUID, CAP_SYS_ADMIN, - CAP_SYS_CHROOT, CAP_SYS_NICE, - CAP_SYS_PTRACE, CAP_SYS_TTY_CONFIG, - CAP_SYS_RESOURCE, CAP_SYS_BOOT, - CAP_AUDIT_WRITE, - CAP_AUDIT_CONTROL. Also CAP_NET_ADMIN - is retained if - is - specified. If the special value - all is passed, all - capabilities are - retained. - - - - - - Specify one or more - additional capabilities to drop for - the container. This allows running the - container with fewer capabilities than - the default (see above). - - - - - - Control whether the - container's journal shall be made - visible to the host system. If enabled, - allows viewing the container's journal - files from the host (but not vice - versa). Takes one of - no, - host, - try-host, - guest, - try-guest, - auto. If - no, the journal is - not linked. If host, - the journal files are stored on the - host file system (beneath - /var/log/journal/machine-id) - and the subdirectory is bind-mounted - into the container at the same - location. If guest, - the journal files are stored on the - guest file system (beneath - /var/log/journal/machine-id) - and the subdirectory is symlinked into the host - at the same location. try-host - and try-guest do the same - but do not fail if the host does not have - persistent journalling enabled. - If auto (the default), - and the right subdirectory of - /var/log/journal - exists, it will be bind mounted - into the container. If the - subdirectory does not exist, no - linking is performed. Effectively, - booting a container once with - guest or - host will link the - journal persistently if further on - the default of auto - is used. - - - - - - Equivalent to - . - - - - - - Mount the root file - system read-only for the - container. - - - - - - - Bind mount a file or - directory from the host into the - container. Either takes a path - argument -- in which case the - specified path will be mounted from - the host to the same path in the - container --, or a colon-separated - pair of paths -- in which case the - first specified path is the source in - the host, and the second path is the - destination in the container. The - option - creates read-only bind - mounts. - - - - - - Mount a tmpfs file - system into the container. Takes a - single absolute path argument that - specifies where to mount the tmpfs - instance to (in which case the - directory access mode will be chosen - as 0755, owned by root/root), or - optionally a colon-separated pair of - path and mount option string, that is - used for mounting (in which case the - kernel default for access mode and - owner will be chosen, unless otherwise - specified). This option is - particularly useful for mounting - directories such as - /var as tmpfs, to - allow state-less systems, in - particular when combined with - . - - - - - - Specifies an - environment variable assignment to - pass to the init process in the - container, in the format - NAME=VALUE. This - may be used to override the default - variables or to set additional - variables. This parameter may be used - more than once. - - - - - - Allows the container - to share certain system facilities - with the host. More specifically, this - turns off PID namespacing, UTS - namespacing and IPC namespacing, and - thus allows the guest to see and - interact more easily with processes - outside of the container. Note that - using this option makes it impossible - to start up a full Operating System in - the container, as an init system - cannot operate in this mode. It is - only useful to run specific programs - or applications this way, without - involving an init system in the - container. This option implies - . This - option may not be combined with - . - - - - - - Controls whether the - container is registered with - systemd-machined8. Takes - a boolean argument, defaults to - yes. This option - should be enabled when the container - runs a full Operating System (more - specifically: an init system), and is - useful to ensure that the container is - accessible via - machinectl1 - and shown by tools such as - ps1. If - the container does not run an init - system, it is recommended to set this - option to no. Note - that - implies - . - - - - - - - Instead of creating a - transient scope unit to run the - container in, simply register the - service or scope unit - systemd-nspawn has - been invoked in with - systemd-machined8. This - has no effect if - is - used. This switch should be used if - systemd-nspawn is - invoked from within a service unit, - and the service unit's sole purpose - is to run a single - systemd-nspawn - container. This option is not - available if run from a user - session. - - - - - - Control the - architecture ("personality") reported - by - uname2 - in the container. Currently, only - x86 and - x86-64 are - supported. This is useful when running - a 32-bit container on a 64-bit - host. If this setting is not used, - the personality reported in the - container is the same as the one - reported on the - host. - - - - - - - Turns off any status - output by the tool itself. When this - switch is used, the only output - from nspawn will be the console output - of the container OS itself. - - - - =MODE - - Boots the container in - volatile mode. When no mode parameter - is passed or when mode is specified as - yes full volatile - mode is enabled. This means the root - directory is mounted as mostly - unpopulated tmpfs - instance, and - /usr from the OS - tree is mounted into it, read-only - (the system thus starts up with - read-only OS resources, but pristine - state and configuration, any changes - to the either are lost on - shutdown). When the mode parameter is - specified as state - the OS tree is mounted read-only, but - /var is mounted - as tmpfs instance - into it (the system thus starts up - with read-only OS resources and - configuration, but pristine state, any - changes to the latter are lost on - shutdown). When the mode parameter is - specified as no - (the default) the whole OS tree is - made available writable. - - Note that setting this to - yes or - state will only - work correctly with operating systems - in the container that can boot up with - only /usr - mounted, and are able to populate - /var - automatically, as - needed. - - - - - - - - - - Examples - - - Download a Fedora image and start a shell in it - - # machinectl pull-raw --verify=no http://ftp.halifax.rwth-aachen.de/fedora/linux/releases/21/Cloud/Images/x86_64/Fedora-Cloud-Base-20141203-21.x86_64.raw.xz + xmlns:xi="http://www.w3.org/2001/XInclude"> + + + systemd-nspawn + systemd + + + + Developer + Lennart + Poettering + lennart@poettering.net + + + + + + systemd-nspawn + 1 + + + + systemd-nspawn + Spawn a namespace container for debugging, testing and building + + + + + systemd-nspawn + OPTIONS + COMMAND + ARGS + + + + systemd-nspawn + -b + OPTIONS + ARGS + + + + + Description + + systemd-nspawn may be used to run a + command or OS in a light-weight namespace container. In many ways + it is similar to + chroot1, + but more powerful since it fully virtualizes the file system + hierarchy, as well as the process tree, the various IPC subsystems + and the host and domain name. + + systemd-nspawn limits access to various + kernel interfaces in the container to read-only, such as + /sys, /proc/sys or + /sys/fs/selinux. Network interfaces and the + system clock may not be changed from within the container. Device + nodes may not be created. The host system cannot be rebooted and + kernel modules may not be loaded from within the container. + + Note that even though these security precautions are taken + systemd-nspawn is not suitable for secure + container setups. Many of the security features may be + circumvented and are hence primarily useful to avoid accidental + changes to the host system from the container. The intended use of + this program is debugging and testing as well as building of + packages, distributions and software involved with boot and + systems management. + + In contrast to + chroot1 systemd-nspawn + may be used to boot full Linux-based operating systems in a + container. + + Use a tool like + dnf8, + yum8, + debootstrap8, + or + pacman8 + to set up an OS directory tree suitable as file system hierarchy + for systemd-nspawn containers. + + Note that systemd-nspawn will mount file + systems private to the container to /dev, + /run and similar. These will not be visible + outside of the container, and their contents will be lost when the + container exits. + + Note that running two systemd-nspawn + containers from the same directory tree will not make processes in + them see each other. The PID namespace separation of the two + containers is complete and the containers will share very few + runtime objects except for the underlying file system. Use + machinectl1's + login command to request an additional login + prompt in a running container. + + systemd-nspawn implements the + Container + Interface specification. + + As a safety check systemd-nspawn will + verify the existence of /usr/lib/os-release + or /etc/os-release in the container tree + before starting the container (see + os-release5). + It might be necessary to add this file to the container tree + manually if the OS of the container is too old to contain this + file out-of-the-box. + + + + Options + + If option is specified, the arguments + are used as arguments for the init binary. Otherwise, + COMMAND specifies the program to launch + in the container, and the remaining arguments are used as + arguments for this program. If is not used and + no arguments are specifed, a shell is launched in the + container. + + The following options are understood: + + + + + + + Directory to use as file system root for the + container. + + If neither , nor + is specified the directory is + determined as /var/lib/machines/ suffixed + by the machine name as specified with + . If neither + , , nor + are specified, the current + directory will be used. May not be specified together with + . + + + + + + Directory or btrfs + subvolume to use as template for the container's root + directory. If this is specified and the container's root + directory (as configured by ) + does not yet exist it is created as btrfs + subvolume and populated from this template tree. Ideally, the + specified template path refers to the root of a + btrfs subvolume, in which case a simple + copy-on-write snapshot is taken, and populating the root + directory is instant. If the specified template path does not + refer to the root of a btrfs subvolume (or + not even to a btrfs file system at all), + the tree is copied, which can be substantially more + time-consuming. Note that if this option is used the + container's root directory (in contrast to the template + directory!) must be located on a btrfs file + system, so that the btrfs subvolume may be + created. May not be specified together with + or + . + + + + + + + If specified, the container is run with a + temporary btrfs snapshot of its root + directory (as configured with ), + that is removed immediately when the container terminates. + This option is only supported if the root file system is + btrfs. May not be specified together with + or + . + + + + + + + Disk image to mount the root directory for the + container from. Takes a path to a regular file or to a block + device node. The file or block device must contain + either: + + + An MBR partition table with a single + partition of type 0x83 that is marked + bootable. + + A GUID partition table (GPT) with a single + partition of type + 0fc63daf-8483-4772-8e79-3d69d8477de4. + + A GUID partition table (GPT) with a marked + root partition which is mounted as the root directory of the + container. Optionally, GPT images may contain a home and/or + a server data partition which are mounted to the appropriate + places in the container. All these partitions must be + identified by the partition types defined by the Discoverable + Partitions Specification. + + + Any other partitions, such as foreign partitions, swap + partitions or EFI system partitions are not mounted. May not + be specified together with , + or + . + + + + + + + Automatically search for an init binary and + invoke it instead of a shell or a user supplied program. If + this option is used, arguments specified on the command line + are used as arguments for the init binary. This option may not + be combined with . + + + + + + + + After transitioning into the container, change + to the specified user-defined in the container's user + database. Like all other systemd-nspawn features, this is not + a security feature and provides protection against accidental + destructive operations only. + + + + + + + Sets the machine name for this container. This + name may be used to identify this container during its runtime + (for example in tools like + machinectl1 + and similar), and is used to initialize the container's + hostname (which the container can choose to override, + however). If not specified, the last component of the root + directory path of the container is used, possibly suffixed + with a random identifier in case + mode is selected. If the root directory selected is the host's + root directory the host's hostname is used as default + instead. + + + + + + Set the specified UUID for the container. The + init system will initialize + /etc/machine-id from this if this file is + not set yet. + + + + + + Make the container part of the specified + slice, instead of the default + machine.slice. + + + + + + + Disconnect networking of the container from + the host. This makes all network interfaces unavailable in the + container, with the exception of the loopback device and those + specified with and + configured with . If this + option is specified, the CAP_NET_ADMIN capability will be + added to the set of capabilities the container retains. The + latter may be disabled by using + . + + + + + + Assign the specified network interface to the + container. This will remove the specified interface from the + calling namespace and place it in the container. When the + container terminates, it is moved back to the host namespace. + Note that implies + . This option may be used + more than once to add multiple network interfaces to the + container. + + + + + + Create a macvlan interface + of the specified Ethernet network interface and add it to the + container. A macvlan interface is a virtual + interface that adds a second MAC address to an existing + physical Ethernet link. The interface in the container will be + named after the interface on the host, prefixed with + mv-. Note that + implies + . This option may be used + more than once to add multiple network interfaces to the + container. + + + + + + Create an ipvlan interface + of the specified Ethernet network interface and add it to the + container. An ipvlan interface is a virtual + interface, similar to a macvlan interface, + which uses the same MAC address as the underlying interface. + The interface in the container will be named after the + interface on the host, prefixed with iv-. + Note that implies + . This option may be used + more than once to add multiple network interfaces to the + container. + + + + + + + Create a virtual Ethernet link + (veth) between host and container. The host + side of the Ethernet link will be available as a network + interface named after the container's name (as specified with + ), prefixed with + ve-. The container side of the Ethernet + link will be named host0. Note that + implies + . + + + + + + Adds the host side of the Ethernet link + created with to the specified + bridge. Note that implies + . If this option is used, the + host side of the Ethernet link will use the + vb- prefix instead of + ve-. + + + + + + + If private networking is enabled, maps an IP + port on the host onto an IP port on the container. Takes a + protocol specifier (either tcp or + udp), separated by a colon from a host port + number in the range 1 to 65535, separated by a colon from a + container port number in the range from 1 to 65535. The + protocol specifier and its separating colon may be omitted, in + which case tcp is assumed. The container + port number and its colon may be ommitted, in which case the + same port as the host port is implied. This option is only + supported if private networking is used, such as + or + . + + + + + + + Sets the SELinux security context to be used + to label processes in the container. + + + + + + + + Sets the SELinux security context to be used + to label files in the virtual API file systems in the + container. + + + + + + + List one or more additional capabilities to + grant the container. Takes a comma-separated list of + capability names, see + capabilities7 + for more information. Note that the following capabilities + will be granted in any way: CAP_CHOWN, CAP_DAC_OVERRIDE, + CAP_DAC_READ_SEARCH, CAP_FOWNER, CAP_FSETID, CAP_IPC_OWNER, + CAP_KILL, CAP_LEASE, CAP_LINUX_IMMUTABLE, + CAP_NET_BIND_SERVICE, CAP_NET_BROADCAST, CAP_NET_RAW, + CAP_SETGID, CAP_SETFCAP, CAP_SETPCAP, CAP_SETUID, + CAP_SYS_ADMIN, CAP_SYS_CHROOT, CAP_SYS_NICE, CAP_SYS_PTRACE, + CAP_SYS_TTY_CONFIG, CAP_SYS_RESOURCE, CAP_SYS_BOOT, + CAP_AUDIT_WRITE, CAP_AUDIT_CONTROL. Also CAP_NET_ADMIN is + retained if is specified. + If the special value all is passed, all + capabilities are retained. + + + + + + Specify one or more additional capabilities to + drop for the container. This allows running the container with + fewer capabilities than the default (see + above). + + + + + + Control whether the container's journal shall + be made visible to the host system. If enabled, allows viewing + the container's journal files from the host (but not vice + versa). Takes one of no, + host, try-host, + guest, try-guest, + auto. If no, the journal + is not linked. If host, the journal files + are stored on the host file system (beneath + /var/log/journal/machine-id) + and the subdirectory is bind-mounted into the container at the + same location. If guest, the journal files + are stored on the guest file system (beneath + /var/log/journal/machine-id) + and the subdirectory is symlinked into the host at the same + location. try-host and + try-guest do the same but do not fail if + the host does not have persistent journalling enabled. If + auto (the default), and the right + subdirectory of /var/log/journal exists, + it will be bind mounted into the container. If the + subdirectory does not exist, no linking is performed. + Effectively, booting a container once with + guest or host will link + the journal persistently if further on the default of + auto is used. + + + + + + Equivalent to + . + + + + + + Mount the root file system read-only for the + container. + + + + + + + Bind mount a file or directory from the host + into the container. Either takes a path argument -- in which + case the specified path will be mounted from the host to the + same path in the container --, or a colon-separated pair of + paths -- in which case the first specified path is the source + in the host, and the second path is the destination in the + container. The option creates + read-only bind mounts. + + + + + + Mount a tmpfs file system into the container. + Takes a single absolute path argument that specifies where to + mount the tmpfs instance to (in which case the directory + access mode will be chosen as 0755, owned by root/root), or + optionally a colon-separated pair of path and mount option + string, that is used for mounting (in which case the kernel + default for access mode and owner will be chosen, unless + otherwise specified). This option is particularly useful for + mounting directories such as /var as + tmpfs, to allow state-less systems, in particular when + combined with . + + + + + + Specifies an environment variable assignment + to pass to the init process in the container, in the format + NAME=VALUE. This may be used to override + the default variables or to set additional variables. This + parameter may be used more than once. + + + + + + Allows the container to share certain system + facilities with the host. More specifically, this turns off + PID namespacing, UTS namespacing and IPC namespacing, and thus + allows the guest to see and interact more easily with + processes outside of the container. Note that using this + option makes it impossible to start up a full Operating System + in the container, as an init system cannot operate in this + mode. It is only useful to run specific programs or + applications this way, without involving an init system in the + container. This option implies . + This option may not be combined with + . + + + + + + Controls whether the container is registered + with + systemd-machined8. + Takes a boolean argument, defaults to yes. + This option should be enabled when the container runs a full + Operating System (more specifically: an init system), and is + useful to ensure that the container is accessible via + machinectl1 + and shown by tools such as + ps1. + If the container does not run an init system, it is + recommended to set this option to no. Note + that implies + . + + + + + + Instead of creating a transient scope unit to + run the container in, simply register the service or scope + unit systemd-nspawn has been invoked in + with + systemd-machined8. + This has no effect if is used. + This switch should be used if + systemd-nspawn is invoked from within a + service unit, and the service unit's sole purpose is to run a + single systemd-nspawn container. This + option is not available if run from a user + session. + + + + + + Control the architecture ("personality") + reported by + uname2 + in the container. Currently, only x86 and + x86-64 are supported. This is useful when + running a 32-bit container on a 64-bit host. If this setting + is not used, the personality reported in the container is the + same as the one reported on the host. + + + + + + + Turns off any status output by the tool + itself. When this switch is used, the only output from nspawn + will be the console output of the container OS + itself. + + + + =MODE + + Boots the container in volatile mode. When no + mode parameter is passed or when mode is specified as + yes full volatile mode is enabled. This + means the root directory is mounted as mostly unpopulated + tmpfs instance, and + /usr from the OS tree is mounted into it, + read-only (the system thus starts up with read-only OS + resources, but pristine state and configuration, any changes + to the either are lost on shutdown). When the mode parameter + is specified as state the OS tree is + mounted read-only, but /var is mounted as + tmpfs instance into it (the system thus + starts up with read-only OS resources and configuration, but + pristine state, any changes to the latter are lost on + shutdown). When the mode parameter is specified as + no (the default) the whole OS tree is made + available writable. + + Note that setting this to yes or + state will only work correctly with + operating systems in the container that can boot up with only + /usr mounted, and are able to populate + /var automatically, as + needed. + + + + + + + + + + Examples + + + Download a Fedora image and start a shell in it + + # machinectl pull-raw --verify=no http://ftp.halifax.rwth-aachen.de/fedora/linux/releases/21/Cloud/Images/x86_64/Fedora-Cloud-Base-20141203-21.x86_64.raw.xz # systemd-nspawn -M Fedora-Cloud-Base-20141203-21 -This downloads an image using machinectl1 and opens a shell in it. - + This downloads an image using + machinectl1 + and opens a shell in it. + - - Build and boot a minimal Fedora distribution in a container + + Build and boot a minimal Fedora distribution in a container - # dnf -y --releasever=21 --nogpg --installroot=/srv/mycontainer --disablerepo='*' --enablerepo=fedora install systemd passwd dnf fedora-release vim-minimal + # dnf -y --releasever=21 --nogpg --installroot=/srv/mycontainer --disablerepo='*' --enablerepo=fedora install systemd passwd dnf fedora-release vim-minimal # systemd-nspawn -bD /srv/mycontainer - This installs a minimal Fedora distribution into - the directory /srv/mycontainer/ and - then boots an OS in a namespace container in - it. - + This installs a minimal Fedora distribution into the + directory /srv/mycontainer/ + and then boots an OS in a namespace container in it. + - - Spawn a shell in a container of a minimal Debian unstable distribution + + Spawn a shell in a container of a minimal Debian unstable distribution - # debootstrap --arch=amd64 unstable ~/debian-tree/ + # debootstrap --arch=amd64 unstable ~/debian-tree/ # systemd-nspawn -D ~/debian-tree/ - This installs a minimal Debian unstable - distribution into the directory - ~/debian-tree/ and then spawns a - shell in a namespace container in it. - + This installs a minimal Debian unstable distribution into + the directory ~/debian-tree/ and then + spawns a shell in a namespace container in it. + - - Boot a minimal Arch Linux distribution in a container + + Boot a minimal Arch Linux distribution in a container - # pacstrap -c -d ~/arch-tree/ base + # pacstrap -c -d ~/arch-tree/ base # systemd-nspawn -bD ~/arch-tree/ - This installs a mimimal Arch Linux distribution into - the directory ~/arch-tree/ and then - boots an OS in a namespace container in it. - + This installs a mimimal Arch Linux distribution into the + directory ~/arch-tree/ and then boots an OS + in a namespace container in it. + - - Boot into an ephemeral <literal>btrfs</literal> snapshot of the host system + + Boot into an ephemeral <literal>btrfs</literal> snapshot of the host system - # systemd-nspawn -D / -xb + # systemd-nspawn -D / -xb - This runs a copy of the host system in a - btrfs snapshot which is - removed immediately when the container - exits. All file system changes made during - runtime will be lost on shutdown, - hence. - + This runs a copy of the host system in a + btrfs snapshot which is removed immediately + when the container exits. All file system changes made during + runtime will be lost on shutdown, hence. + - - Run a container with SELinux sandbox security contexts + + Run a container with SELinux sandbox security contexts - # chcon system_u:object_r:svirt_sandbox_file_t:s0:c0,c1 -R /srv/container + # chcon system_u:object_r:svirt_sandbox_file_t:s0:c0,c1 -R /srv/container # systemd-nspawn -L system_u:object_r:svirt_sandbox_file_t:s0:c0,c1 -Z system_u:system_r:svirt_lxc_net_t:s0:c0,c1 -D /srv/container /bin/sh - - - - - Exit status - - The exit code of the program executed in the - container is returned. - - - - See Also - - systemd1, - chroot1, - dnf8, - yum8, - debootstrap8, - pacman8, - systemd.slice5, - machinectl1, - btrfs8 - - + + + + + Exit status + + The exit code of the program executed in the container is + returned. + + + + See Also + + systemd1, + chroot1, + dnf8, + yum8, + debootstrap8, + pacman8, + systemd.slice5, + machinectl1, + btrfs8 + + diff --git a/man/systemd-path.xml b/man/systemd-path.xml index fc01d5edd4a..dfc75ee0ff4 100644 --- a/man/systemd-path.xml +++ b/man/systemd-path.xml @@ -1,6 +1,6 @@ + "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd"> - - - systemd-path - systemd - - - - Developer - Lennart - Poettering - lennart@poettering.net - - - - - - systemd-path - 1 - - - - systemd-path - List and query system and user paths - - - - - systemd-path OPTIONS NAME - - - - - Description - - systemd-path may be used to - query system and user paths. The tool makes many of - the paths described in - file-hierarchy7 - queriable. - - When invoked without arguments a list of known - paths and their current values is shown. When at least - one argument is passed the path with this is name is - queried and its value shown. The variables whose name - begins with search- don't refer to - individual paths, but instead a to a list of - colon-separated search paths, in their order of - precedence. - - - - Options - - The following options are understood: - - - - - - The printed paths are - suffixed by the specified - string. - - - - - - - - - - Exit status - - On success, 0 is returned, a non-zero failure - code otherwise. - - - - See Also - - systemd1, - file-hierarchy7 - - + xmlns:xi="http://www.w3.org/2001/XInclude"> + + + systemd-path + systemd + + + + Developer + Lennart + Poettering + lennart@poettering.net + + + + + + systemd-path + 1 + + + + systemd-path + List and query system and user paths + + + + + systemd-path OPTIONS NAME + + + + + Description + + systemd-path may be used to query system + and user paths. The tool makes many of the paths described in + file-hierarchy7 + queriable. + + When invoked without arguments a list of known paths and + their current values is shown. When at least one argument is + passed the path with this is name is queried and its value shown. + The variables whose name begins with search- + don't refer to individual paths, but instead a to a list of + colon-separated search paths, in their order of precedence. + + + + Options + + The following options are understood: + + + + + + The printed paths are suffixed by the + specified string. + + + + + + + + + + Exit status + + On success, 0 is returned, a non-zero failure code + otherwise. + + + + See Also + + systemd1, + file-hierarchy7 + + diff --git a/man/systemd-quotacheck.service.xml b/man/systemd-quotacheck.service.xml index ff04e582de5..2179f11e95f 100644 --- a/man/systemd-quotacheck.service.xml +++ b/man/systemd-quotacheck.service.xml @@ -21,82 +21,74 @@ --> - - systemd-quotacheck.service - systemd - - - - Developer - Lennart - Poettering - lennart@poettering.net - - - - - - systemd-quotacheck.service - 8 - - - - systemd-quotacheck.service - systemd-quotacheck - File system quota checker logic - - - - systemd-quotacheck.service - /usr/lib/systemd/systemd-quotacheck - - - - Description - - systemd-quotacheck.service - is a service responsible for file system quota - checks. It is run once at boot after all necessary - file systems are mounted. It is pulled in only if at - least one file system has quotas enabled. - - - - Kernel Command Line - - systemd-quotacheck understands - one kernel command line parameter: - - - - quotacheck.mode= - - One of - auto, - force, - skip. Controls the - mode of operation. The default is - auto, and ensures - that file system quota checks are done - when the file system quota checker - deems them - necessary. force - unconditionally results in full file - system quota - checks. skip skips - any file system quota - checks. - - - - - - See Also - - systemd1, - quotacheck8, - systemd-fsck@.service8 - - + + systemd-quotacheck.service + systemd + + + + Developer + Lennart + Poettering + lennart@poettering.net + + + + + + systemd-quotacheck.service + 8 + + + + systemd-quotacheck.service + systemd-quotacheck + File system quota checker logic + + + + systemd-quotacheck.service + /usr/lib/systemd/systemd-quotacheck + + + + Description + + systemd-quotacheck.service is a service + responsible for file system quota checks. It is run once at boot + after all necessary file systems are mounted. It is pulled in only + if at least one file system has quotas enabled. + + + + Kernel Command Line + + systemd-quotacheck understands one + kernel command line parameter: + + + + quotacheck.mode= + + One of auto, + force, skip. Controls + the mode of operation. The default is auto, + and ensures that file system quota checks are done when the + file system quota checker deems them necessary. + force unconditionally results in full file + system quota checks. skip skips any file + system quota checks. + + + + + + See Also + + systemd1, + quotacheck8, + systemd-fsck@.service8 + + diff --git a/man/systemd-random-seed.service.xml b/man/systemd-random-seed.service.xml index e5cd03719f3..8c836688fec 100644 --- a/man/systemd-random-seed.service.xml +++ b/man/systemd-random-seed.service.xml @@ -21,55 +21,55 @@ --> - - systemd-random-seed.service - systemd + + systemd-random-seed.service + systemd - - - Developer - Lennart - Poettering - lennart@poettering.net - - - + + + Developer + Lennart + Poettering + lennart@poettering.net + + + - - systemd-random-seed.service - 8 - + + systemd-random-seed.service + 8 + - - systemd-random-seed.service - systemd-random-seed - Load and save the system random seed at boot and shutdown - + + systemd-random-seed.service + systemd-random-seed + Load and save the system random seed at boot and shutdown + - - systemd-random-seed.service - /usr/lib/systemd/systemd-random-seed - + + systemd-random-seed.service + /usr/lib/systemd/systemd-random-seed + - - Description + + Description - systemd-random-seed.service - is a service that restores the random seed of the - system at early-boot and saves it at shutdown. See - random4 - for details. Saving/restoring the random seed across - boots increases the amount of available entropy early - at boot. On disk the random seed is stored in - /var/lib/systemd/random-seed. - + systemd-random-seed.service is a + service that restores the random seed of the system at early-boot + and saves it at shutdown. See + random4 + for details. Saving/restoring the random seed across boots + increases the amount of available entropy early at boot. On disk + the random seed is stored in + /var/lib/systemd/random-seed. + - - See Also - - systemd1, - random4 - - + + See Also + + systemd1, + random4 + + diff --git a/man/systemd-remount-fs.service.xml b/man/systemd-remount-fs.service.xml index cf04713a006..7b88ac3f3c7 100644 --- a/man/systemd-remount-fs.service.xml +++ b/man/systemd-remount-fs.service.xml @@ -21,73 +21,68 @@ --> - - systemd-remount-fs.service - systemd + + systemd-remount-fs.service + systemd - - - Developer - Lennart - Poettering - lennart@poettering.net - - - + + + Developer + Lennart + Poettering + lennart@poettering.net + + + - - systemd-remount-fs.service - 8 - + + systemd-remount-fs.service + 8 + - - systemd-remount-fs.service - systemd-remount-fs - Remount root and kernel file systems - + + systemd-remount-fs.service + systemd-remount-fs + Remount root and kernel file systems + - - systemd-remount-fs.service - /usr/lib/systemd/systemd-remount-fs - + + systemd-remount-fs.service + /usr/lib/systemd/systemd-remount-fs + - - Description + + Description - systemd-remount-fs.service - is an early-boot service that applies mount options - listed in - fstab5 - to the root file system, the /usr - file system and the kernel API file systems. This is - required so that the mount options of these file - systems -- which are pre-mounted by the kernel, the - initial RAM disk, container environments or system - manager code -- are updated to those listed in - /etc/fstab. This service ignores - normal file systems and only changes the root file - system (i.e. /), - /usr and the virtual kernel API - file systems such as /proc, - /sys or - /dev. This service executes no - operation if /etc/fstab does not - exist or lists no entries for the mentioned file - systems. + systemd-remount-fs.service is an + early-boot service that applies mount options listed in + fstab5 + to the root file system, the /usr file system + and the kernel API file systems. This is required so that the + mount options of these file systems -- which are pre-mounted by + the kernel, the initial RAM disk, container environments or system + manager code -- are updated to those listed in + /etc/fstab. This service ignores normal file + systems and only changes the root file system (i.e. + /), /usr and the virtual + kernel API file systems such as /proc, + /sys or /dev. This + service executes no operation if /etc/fstab + does not exist or lists no entries for the mentioned file + systems. - For a longer discussion of kernel API file - systems see API - File Systems. - + For a longer discussion of kernel API file systems see + API + File Systems. + - - See Also - - systemd1, - fstab5, - mount8 - - + + See Also + + systemd1, + fstab5, + mount8 + + diff --git a/man/systemd-resolved.service.xml b/man/systemd-resolved.service.xml index c44b10c4722..89ec5f8b197 100644 --- a/man/systemd-resolved.service.xml +++ b/man/systemd-resolved.service.xml @@ -1,6 +1,6 @@ + "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd"> - - systemd-rfkill@.service - systemd - - - - Developer - Lennart - Poettering - lennart@poettering.net - - - - - - systemd-rfkill@.service - 8 - - - - systemd-rfkill@.service - systemd-rfkill - Load and save the RF kill switch state at boot and shutdown - - - - systemd-rfkill@.service - /usr/lib/systemd/systemd-rfkill - - - - Description - - systemd-rfkill@.service is - a service that restores the RF kill switch state at - early boot and saves it at shutdown. On disk, the RF - kill switch state is stored in - /var/lib/systemd/rfkill/. - - - - Kernel Command Line - - systemd-rfkill understands - the following kernel command line parameter: - - - - systemd.restore_state= - - Takes a boolean - argument. Defaults to - 1. If - 0, does not restore - the rfkill settings on boot. However, - settings will still be stored on shutdown. - - - - - - - See Also - - systemd1 - - + + systemd-rfkill@.service + systemd + + + + Developer + Lennart + Poettering + lennart@poettering.net + + + + + + systemd-rfkill@.service + 8 + + + + systemd-rfkill@.service + systemd-rfkill + Load and save the RF kill switch state at boot and shutdown + + + + systemd-rfkill@.service + /usr/lib/systemd/systemd-rfkill + + + + Description + + systemd-rfkill@.service is a service + that restores the RF kill switch state at early boot and saves it + at shutdown. On disk, the RF kill switch state is stored in + /var/lib/systemd/rfkill/. + + + + Kernel Command Line + + systemd-rfkill understands the + following kernel command line parameter: + + + + systemd.restore_state= + + Takes a boolean argument. Defaults to + 1. If 0, does not + restore the rfkill settings on boot. However, settings will + still be stored on shutdown. + + + + + + See Also + + systemd1 + + diff --git a/man/systemd-shutdownd.service.xml b/man/systemd-shutdownd.service.xml index c1b8ef7a495..756949ce558 100644 --- a/man/systemd-shutdownd.service.xml +++ b/man/systemd-shutdownd.service.xml @@ -1,6 +1,6 @@ + "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd"> + xmlns:xi="http://www.w3.org/2001/XInclude"> - - systemd-socket-proxyd - systemd - - - Developer - David - Strauss - david@davidstrauss.net - - - - - systemd-socket-proxyd - 8 - - - systemd-socket-proxyd - Bidirectionally proxy local sockets to another (possibly remote) socket. - - - - systemd-socket-proxyd - OPTIONS - HOST:PORT - - - systemd-socket-proxyd - OPTIONS - UNIX-DOMAIN-SOCKET-PATH - - - - - Description - - systemd-socket-proxyd is a generic - socket-activated network socket forwarder proxy daemon - for IPv4, IPv6 and UNIX stream sockets. It may be used - to bi-directionally forward traffic from a local listening socket to a - local or remote destination socket. + + systemd-socket-proxyd + systemd + + + Developer + David + Strauss + david@davidstrauss.net + + + + + systemd-socket-proxyd + 8 + + + systemd-socket-proxyd + Bidirectionally proxy local sockets to another (possibly remote) socket. + + + + systemd-socket-proxyd + OPTIONS + HOST:PORT + + + systemd-socket-proxyd + OPTIONS + UNIX-DOMAIN-SOCKET-PATH + + + + + Description + + systemd-socket-proxyd is a generic + socket-activated network socket forwarder proxy daemon for IPv4, + IPv6 and UNIX stream sockets. It may be used to bi-directionally + forward traffic from a local listening socket to a local or remote + destination socket. - One use of this tool is to provide - socket activation support for services that do not - natively support socket activation. On behalf of the - service to activate, the proxy inherits the socket - from systemd, accepts each client connection, opens a - connection to a configured server for each client, and - then bidirectionally forwards data between the - two. - This utility's behavior is similar to - socat1. - The main differences for systemd-socket-proxyd - are support for socket activation with - Accept=false and an event-driven - design that scales better with the number of - connections. - - - Options - The following options are understood: - - - - - - - Exit status - On success, 0 is returned, a non-zero failure - code otherwise. - - - Examples - - Simple Example - Use two services with a dependency - and no namespace isolation. - - proxy-to-nginx.socket - One use of this tool is to provide socket activation support + for services that do not natively support socket activation. On + behalf of the service to activate, the proxy inherits the socket + from systemd, accepts each client connection, opens a connection + to a configured server for each client, and then bidirectionally + forwards data between the two. + This utility's behavior is similar to + socat1. + The main differences for systemd-socket-proxyd + are support for socket activation with + Accept=false and an event-driven + design that scales better with the number of + connections. + + + Options + The following options are understood: + + + + + + + Exit status + On success, 0 is returned, a non-zero failure + code otherwise. + + + Examples + + Simple Example + Use two services with a dependency and no namespace + isolation. + + proxy-to-nginx.socket + - - - proxy-to-nginx.service - + + proxy-to-nginx.service + - - - nginx.conf - + + + nginx.conf + - - - Enabling the proxy - + + Enabling the proxy + - - - - Namespace Example - Similar as above, but runs the socket - proxy and the main service in the same private - namespace, assuming that - nginx.service has - PrivateTmp= and - PrivateNetwork= set, - too. - - proxy-to-nginx.socket - + + + Namespace Example + Similar as above, but runs the socket proxy and the main + service in the same private namespace, assuming that + nginx.service has + PrivateTmp= and + PrivateNetwork= set, too. + + proxy-to-nginx.socket + - - - proxy-to-nginx.service - + + proxy-to-nginx.service + - - - nginx.conf - + + nginx.conf + - - - Enabling the proxy - + + Enabling the proxy + - - - - - See Also - - systemd1, - systemd.socket5, - systemd.service5, - systemctl1, - socat1, - nginx1, - curl1 - - + + + + + See Also + + systemd1, + systemd.socket5, + systemd.service5, + systemctl1, + socat1, + nginx1, + curl1 + + diff --git a/man/systemd-suspend.service.xml b/man/systemd-suspend.service.xml index 375c25576d5..a8beb86f4da 100644 --- a/man/systemd-suspend.service.xml +++ b/man/systemd-suspend.service.xml @@ -1,6 +1,6 @@ + "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd"> - - - systemd-suspend.service - systemd - - - - Developer - Lennart - Poettering - lennart@poettering.net - - - - - - systemd-suspend.service - 8 - - - - systemd-suspend.service - systemd-hibernate.service - systemd-hybrid-sleep.service - systemd-sleep - System sleep state logic - - - - systemd-suspend.service - systemd-hibernate.service - systemd-hybrid-sleep.service - /usr/lib/systemd/system-sleep - - - - Description - - systemd-suspend.service is - a system service that is pulled in by - suspend.target and is responsible - for the actual system suspend. Similarly, - systemd-hibernate.service is - pulled in by hibernate.target to - execute the actual hibernation. Finally, - systemd-hybrid-sleep.service is - pulled in by hybrid-sleep.target - to execute hybrid hibernation with system - suspend. - - Immediately before entering system suspend - and/or hibernation - systemd-suspend.service (and the - other mentioned units, respectively) will run all - executables in - /usr/lib/systemd/system-sleep/ - and pass two arguments to them. The first argument - will be pre, the second either - suspend, - hibernate, or - hybrid-sleep depending on the - chosen action. Immediately after leaving system - suspend and/or hibernation the same executables are run, - but the first argument is now - post. All executables in this - directory are executed in parallel, and execution of - the action is not continued until all executables - have finished. - - Note that scripts or binaries dropped in - /usr/lib/systemd/system-sleep/ - are intended for local use only and should be - considered hacks. If applications want to be notified - of system suspend/hibernation and resume, there are - much nicer interfaces available. - - Note that - systemd-suspend.service, - systemd-hibernate.service, and - systemd-hybrid-sleep.service - should never be executed directly. Instead, trigger - system sleep states with a command such as - systemctl suspend or - similar. - - Internally, this service will echo a string like - mem into - /sys/power/state, to trigger the - actual system suspend. What exactly is written - where can be configured in the [Sleep] - section of /etc/systemd/sleep.conf or a - sleep.conf.d file. - See systemd-sleep.conf5. - - - - - Options - - systemd-sleep understands the - following commands: - - - - - - - - - - - Suspend, hibernate, or - put the system to hybrid sleep. - - - - - - - See Also - - systemd-sleep.conf5, - systemd1, - systemctl1, - systemd.special7, - systemd-halt.service8 - - + xmlns:xi="http://www.w3.org/2001/XInclude"> + + + systemd-suspend.service + systemd + + + + Developer + Lennart + Poettering + lennart@poettering.net + + + + + + systemd-suspend.service + 8 + + + + systemd-suspend.service + systemd-hibernate.service + systemd-hybrid-sleep.service + systemd-sleep + System sleep state logic + + + + systemd-suspend.service + systemd-hibernate.service + systemd-hybrid-sleep.service + /usr/lib/systemd/system-sleep + + + + Description + + systemd-suspend.service is a system + service that is pulled in by suspend.target + and is responsible for the actual system suspend. Similarly, + systemd-hibernate.service is pulled in by + hibernate.target to execute the actual + hibernation. Finally, + systemd-hybrid-sleep.service is pulled in by + hybrid-sleep.target to execute hybrid + hibernation with system suspend. + + Immediately before entering system suspend and/or + hibernation systemd-suspend.service (and the + other mentioned units, respectively) will run all executables in + /usr/lib/systemd/system-sleep/ and pass two + arguments to them. The first argument will be + pre, the second either + suspend, hibernate, or + hybrid-sleep depending on the chosen action. + Immediately after leaving system suspend and/or hibernation the + same executables are run, but the first argument is now + post. All executables in this directory are + executed in parallel, and execution of the action is not continued + until all executables have finished. + + Note that scripts or binaries dropped in + /usr/lib/systemd/system-sleep/ are intended + for local use only and should be considered hacks. If applications + want to be notified of system suspend/hibernation and resume, + there are much nicer interfaces available. + + Note that + systemd-suspend.service, + systemd-hibernate.service, and + systemd-hybrid-sleep.service + should never be executed directly. Instead, trigger system sleep + states with a command such as systemctl suspend + or similar. + + Internally, this service will echo a string like + mem into /sys/power/state, + to trigger the actual system suspend. What exactly is written + where can be configured in the [Sleep] section + of /etc/systemd/sleep.conf or a + sleep.conf.d file. See + systemd-sleep.conf5. + + + + + Options + + systemd-sleep understands the + following commands: + + + + + + + + + + + Suspend, hibernate, or put the system to + hybrid sleep. + + + + + + + See Also + + systemd-sleep.conf5, + systemd1, + systemctl1, + systemd.special7, + systemd-halt.service8 + + diff --git a/man/systemd-sysctl.service.xml b/man/systemd-sysctl.service.xml index a9a4765630c..f35a18a4d48 100644 --- a/man/systemd-sysctl.service.xml +++ b/man/systemd-sysctl.service.xml @@ -21,57 +21,56 @@ --> - - systemd-sysctl.service - systemd + + systemd-sysctl.service + systemd - - - Developer - Lennart - Poettering - lennart@poettering.net - - - + + + Developer + Lennart + Poettering + lennart@poettering.net + + + - - systemd-sysctl.service - 8 - + + systemd-sysctl.service + 8 + - - systemd-sysctl.service - systemd-sysctl - Configure kernel parameters at boot - + + systemd-sysctl.service + systemd-sysctl + Configure kernel parameters at boot + - - systemd-sysctl.service - /usr/lib/systemd/systemd-sysctl - + + systemd-sysctl.service + /usr/lib/systemd/systemd-sysctl + - - Description + + Description - systemd-sysctl.service is - an early-boot service that configures - sysctl8 - kernel parameters. + systemd-sysctl.service is an early-boot + service that configures + sysctl8 + kernel parameters. - See - sysctl.d5 - for information about the configuration of this - service. - + See + sysctl.d5 + for information about the configuration of this service. + - - See Also - - systemd1, - sysctl.d5, - sysctl8, - - + + See Also + + systemd1, + sysctl.d5, + sysctl8, + + diff --git a/man/systemd-system-update-generator.xml b/man/systemd-system-update-generator.xml index 18a23ed7fc0..3eec1d7b933 100644 --- a/man/systemd-system-update-generator.xml +++ b/man/systemd-system-update-generator.xml @@ -21,59 +21,58 @@ --> - - systemd-system-update-generator - systemd + + systemd-system-update-generator + systemd - - - Developer - Lennart - Poettering - lennart@poettering.net - - - + + + Developer + Lennart + Poettering + lennart@poettering.net + + + - - systemd-system-update-generator - 8 - + + systemd-system-update-generator + 8 + - - systemd-system-update-generator - Generator for redirecting boot to offline update mode - + + systemd-system-update-generator + Generator for redirecting boot to offline update mode + - - /usr/lib/systemd/system-generators/systemd-system-update-generator - + + /usr/lib/systemd/system-generators/systemd-system-update-generator + - - Description + + Description - systemd-system-update-generator - is a generator that automatically redirects the boot - process to system-update.target - if /system-update exists. This is - required to implement the logic explained in the - System - Updates Specification. - + systemd-system-update-generator is a + generator that automatically redirects the boot process to + system-update.target if + /system-update exists. This is required to + implement the logic explained in the System + Updates Specification. + - systemd-system-update-generator - implements the generator - specification. - + systemd-system-update-generator + implements the + generator + specification. + - - See Also - - systemd1, - systemd.special7 - - + + See Also + + systemd1, + systemd.special7 + + diff --git a/man/systemd-system.conf.xml b/man/systemd-system.conf.xml index dfb180cc54c..7137fdb07df 100644 --- a/man/systemd-system.conf.xml +++ b/man/systemd-system.conf.xml @@ -1,7 +1,7 @@ + "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd"> - - systemd-system.conf - systemd - - - - Developer - Lennart - Poettering - lennart@poettering.net - - - - - - systemd-system.conf - 5 - - - - systemd-system.conf - system.conf.d - systemd-user.conf - user.conf.d - System and session service manager configuration files - - - - /etc/systemd/system.conf - /etc/systemd/system.conf.d/*.conf - /run/systemd/system.conf.d/*.conf - /usr/lib/systemd/system.conf.d/*.conf - /etc/systemd/user.conf - /etc/systemd/user.conf.d/*.conf - /run/systemd/user.conf.d/*.conf - /usr/lib/systemd/user.conf.d/*.conf - - - - Description - - When run as a system instance, systemd interprets the - configuration file system.conf and the - files in system.conf.d directories; when - run as a user instance, systemd interprets the configuration - file user.conf and the files in - user.conf.d directories. These - configuration files contain a few settings controlling - basic manager operations. - - - - - - - Options - - All options are configured in the - [Manager] section: - - - - - LogLevel= - LogTarget= - LogColor= - LogLocation= - DumpCore=yes - CrashShell=no - ShowStatus=yes - CrashChVT=1 - DefaultStandardOutput=journal - DefaultStandardError=inherit - - Configures various - parameters of basic manager - operation. These options may be - overridden by the respective command - line arguments. See - systemd1 - for details about these command line - arguments. - - - - CPUAffinity= - - Configures the initial - CPU affinity for the init - process. Takes a space-separated list - of CPU indices. - - - - JoinControllers=cpu,cpuacct net_cls,netprio - - Configures controllers - that shall be mounted in a single - hierarchy. By default, systemd will - mount all controllers which are - enabled in the kernel in individual - hierarchies, with the exception of - those listed in this setting. Takes a - space-separated list of comma-separated - controller names, in order - to allow multiple joined - hierarchies. Defaults to - 'cpu,cpuacct'. Pass an empty string to - ensure that systemd mounts all - controllers in separate - hierarchies. - - Note that this option is only - applied once, at very early boot. If - you use an initial RAM disk (initrd) - that uses systemd, it might hence be - necessary to rebuild the initrd if - this option is changed, and make sure - the new configuration file is included - in it. Otherwise, the initrd might - mount the controller hierarchies in a - different configuration than intended, - and the main system cannot remount - them anymore. - - - - RuntimeWatchdogSec= - ShutdownWatchdogSec= - - Configure the hardware - watchdog at runtime and at - reboot. Takes a timeout value in - seconds (or in other time units if - suffixed with ms, - min, - h, - d, - w). If - RuntimeWatchdogSec= - is set to a non-zero value, the - watchdog hardware - (/dev/watchdog) - will be programmed to automatically - reboot the system if it is not - contacted within the specified timeout - interval. The system manager will - ensure to contact it at least once in - half the specified timeout - interval. This feature requires a - hardware watchdog device to be - present, as it is commonly the case in - embedded and server systems. Not all - hardware watchdogs allow configuration - of the reboot timeout, in which case - the closest available timeout is - picked. ShutdownWatchdogSec= - may be used to configure the hardware - watchdog when the system is asked to - reboot. It works as a safety net to - ensure that the reboot takes place - even if a clean reboot attempt times - out. By default - RuntimeWatchdogSec= - defaults to 0 (off), and - ShutdownWatchdogSec= - to 10min. These settings have no - effect if a hardware watchdog is not - available. - - - - CapabilityBoundingSet= - - Controls which - capabilities to include in the - capability bounding set for PID 1 and - its children. See - capabilities7 - for details. Takes a whitespace-separated - list of capability names as read by - cap_from_name3. - Capabilities listed will be included - in the bounding set, all others are - removed. If the list of capabilities - is prefixed with ~, all but the listed - capabilities will be included, the - effect of the assignment - inverted. Note that this option also - affects the respective capabilities in - the effective, permitted and - inheritable capability sets. The - capability bounding set may also be - individually configured for units - using the - CapabilityBoundingSet= - directive for units, but note that - capabilities dropped for PID 1 cannot - be regained in individual units, they - are lost for good. - - - - SystemCallArchitectures= - - Takes a - space-separated list of architecture - identifiers. Selects from which - architectures system calls may be - invoked on this system. This may be - used as an effective way to disable - invocation of non-native binaries - system-wide, for example to prohibit - execution of 32-bit x86 binaries on - 64-bit x86-64 systems. This option - operates system-wide, and acts - similar to the - SystemCallArchitectures= - setting of unit files, see - systemd.exec5 - for details. This setting defaults to - the empty list, in which case no - filtering of system calls based on - architecture is applied. Known - architecture identifiers are - x86, - x86-64, - x32, - arm and the special - identifier - native. The latter - implicitly maps to the native - architecture of the system (or more - specifically, the architecture the - system manager was compiled for). Set - this setting to - native to prohibit - execution of any non-native - binaries. When a binary executes a - system call of an architecture that is - not listed in this setting, it will be - immediately terminated with the SIGSYS - signal. - - - - TimerSlackNSec= - - Sets the timer slack - in nanoseconds for PID 1, which is - inherited by all executed processes, - unless overridden individually, for - example with the - TimerSlackNSec= - setting in service units (for details - see - systemd.exec5). The - timer slack controls the accuracy of - wake-ups triggered by system - timers. See - prctl2 - for more information. Note that in - contrast to most other time span - definitions this parameter takes an - integer value in nano-seconds if no - unit is specified. The usual time - units are understood - too. - - - - DefaultTimerAccuracySec= - - Sets the default - accuracy of timer units. This controls - the global default for the - AccuracySec= - setting of timer units, see - systemd.timer5 - for - details. AccuracySec= - set in individual units override the - global default for the specific - unit. Defaults to 1min. Note that the - accuracy of timer units is also - affected by the configured timer slack - for PID 1, see - TimerSlackNSec= - above. - - - - DefaultTimeoutStartSec= - DefaultTimeoutStopSec= - DefaultRestartSec= - - Configures the default - timeouts for starting and stopping of - units, as well as the default time to - sleep between automatic restarts of - units, as configured per-unit in - TimeoutStartSec=, - TimeoutStopSec= and - RestartSec= (for - services, see - systemd.service5 - for details on the per-unit - settings). For non-service units, - DefaultTimeoutStartSec= - sets the default - TimeoutSec= value. - - - - - DefaultStartLimitInterval= - DefaultStartLimitBurst= - - Configure the default - unit start rate limiting, as - configured per-service by - StartLimitInterval= - and - StartLimitBurst=. See - systemd.service5 - for details on the per-service - settings. - - - - DefaultEnvironment= - - Sets manager - environment variables passed to all - executed processes. Takes a - space-separated list of variable - assignments. See - environ7 - for details about environment - variables. - - Example: - - DefaultEnvironment="VAR1=word1 word2" VAR2=word3 "VAR3=word 5 6" - - Sets three variables - VAR1, - VAR2, - VAR3. - - - - DefaultCPUAccounting= - DefaultBlockIOAccounting= - DefaultMemoryAccounting= - - Configure the default - resource accounting settings, as - configured per-unit by - CPUAccounting=, - BlockIOAccounting= - and - MemoryAccounting=. See - systemd.resource-control5 - for details on the per-unit - settings. - - - - DefaultLimitCPU= - DefaultLimitFSIZE= - DefaultLimitDATA= - DefaultLimitSTACK= - DefaultLimitCORE= - DefaultLimitRSS= - DefaultLimitNOFILE= - DefaultLimitAS= - DefaultLimitNPROC= - DefaultLimitMEMLOCK= - DefaultLimitLOCKS= - DefaultLimitSIGPENDING= - DefaultLimitMSGQUEUE= - DefaultLimitNICE= - DefaultLimitRTPRIO= - DefaultLimitRTTIME= - - These settings control - various default resource limits for - units. See - setrlimit2 - for details. Use the string - infinity to - configure no limit on a specific - resource. These settings may be - overridden in individual units - using the corresponding LimitXXX= - directives. Note that these resource - limits are only defaults for units, - they are not applied to PID 1 - itself. - - - - - - See Also - - systemd1, - systemd.directives7, - systemd.exec5, - systemd.service5, - environ7, - capabilities7 - - + xmlns:xi="http://www.w3.org/2001/XInclude"> + + systemd-system.conf + systemd + + + + Developer + Lennart + Poettering + lennart@poettering.net + + + + + + systemd-system.conf + 5 + + + + systemd-system.conf + system.conf.d + systemd-user.conf + user.conf.d + System and session service manager configuration files + + + + /etc/systemd/system.conf + /etc/systemd/system.conf.d/*.conf + /run/systemd/system.conf.d/*.conf + /usr/lib/systemd/system.conf.d/*.conf + /etc/systemd/user.conf + /etc/systemd/user.conf.d/*.conf + /run/systemd/user.conf.d/*.conf + /usr/lib/systemd/user.conf.d/*.conf + + + + Description + + When run as a system instance, systemd interprets the + configuration file system.conf and the files + in system.conf.d directories; when run as a + user instance, systemd interprets the configuration file + user.conf and the files in + user.conf.d directories. These configuration + files contain a few settings controlling basic manager + operations. + + + + + + + Options + + All options are configured in the + [Manager] section: + + + + + LogLevel= + LogTarget= + LogColor= + LogLocation= + DumpCore=yes + CrashShell=no + ShowStatus=yes + CrashChVT=1 + DefaultStandardOutput=journal + DefaultStandardError=inherit + + Configures various parameters of basic manager + operation. These options may be overridden by the respective + command line arguments. See + systemd1 + for details about these command line + arguments. + + + + CPUAffinity= + + Configures the initial CPU affinity for the + init process. Takes a space-separated list of CPU + indices. + + + + JoinControllers=cpu,cpuacct net_cls,netprio + + Configures controllers that shall be mounted + in a single hierarchy. By default, systemd will mount all + controllers which are enabled in the kernel in individual + hierarchies, with the exception of those listed in this + setting. Takes a space-separated list of comma-separated + controller names, in order to allow multiple joined + hierarchies. Defaults to 'cpu,cpuacct'. Pass an empty string + to ensure that systemd mounts all controllers in separate + hierarchies. + + Note that this option is only applied once, at very + early boot. If you use an initial RAM disk (initrd) that uses + systemd, it might hence be necessary to rebuild the initrd if + this option is changed, and make sure the new configuration + file is included in it. Otherwise, the initrd might mount the + controller hierarchies in a different configuration than + intended, and the main system cannot remount them + anymore. + + + + RuntimeWatchdogSec= + ShutdownWatchdogSec= + + Configure the hardware watchdog at runtime and + at reboot. Takes a timeout value in seconds (or in other time + units if suffixed with ms, + min, h, + d, w). If + RuntimeWatchdogSec= is set to a non-zero + value, the watchdog hardware + (/dev/watchdog) will be programmed to + automatically reboot the system if it is not contacted within + the specified timeout interval. The system manager will ensure + to contact it at least once in half the specified timeout + interval. This feature requires a hardware watchdog device to + be present, as it is commonly the case in embedded and server + systems. Not all hardware watchdogs allow configuration of the + reboot timeout, in which case the closest available timeout is + picked. ShutdownWatchdogSec= may be used to + configure the hardware watchdog when the system is asked to + reboot. It works as a safety net to ensure that the reboot + takes place even if a clean reboot attempt times out. By + default RuntimeWatchdogSec= defaults to 0 + (off), and ShutdownWatchdogSec= to 10min. + These settings have no effect if a hardware watchdog is not + available. + + + + CapabilityBoundingSet= + + Controls which capabilities to include in the + capability bounding set for PID 1 and its children. See + capabilities7 + for details. Takes a whitespace-separated list of capability + names as read by + cap_from_name3. + Capabilities listed will be included in the bounding set, all + others are removed. If the list of capabilities is prefixed + with ~, all but the listed capabilities will be included, the + effect of the assignment inverted. Note that this option also + affects the respective capabilities in the effective, + permitted and inheritable capability sets. The capability + bounding set may also be individually configured for units + using the CapabilityBoundingSet= directive + for units, but note that capabilities dropped for PID 1 cannot + be regained in individual units, they are lost for + good. + + + + SystemCallArchitectures= + + Takes a space-separated list of architecture + identifiers. Selects from which architectures system calls may + be invoked on this system. This may be used as an effective + way to disable invocation of non-native binaries system-wide, + for example to prohibit execution of 32-bit x86 binaries on + 64-bit x86-64 systems. This option operates system-wide, and + acts similar to the + SystemCallArchitectures= setting of unit + files, see + systemd.exec5 + for details. This setting defaults to the empty list, in which + case no filtering of system calls based on architecture is + applied. Known architecture identifiers are + x86, x86-64, + x32, arm and the special + identifier native. The latter implicitly + maps to the native architecture of the system (or more + specifically, the architecture the system manager was compiled + for). Set this setting to native to + prohibit execution of any non-native binaries. When a binary + executes a system call of an architecture that is not listed + in this setting, it will be immediately terminated with the + SIGSYS signal. + + + + TimerSlackNSec= + + Sets the timer slack in nanoseconds for PID 1, + which is inherited by all executed processes, unless + overridden individually, for example with the + TimerSlackNSec= setting in service units + (for details see + systemd.exec5). + The timer slack controls the accuracy of wake-ups triggered by + system timers. See + prctl2 + for more information. Note that in contrast to most other time + span definitions this parameter takes an integer value in + nano-seconds if no unit is specified. The usual time units are + understood too. + + + + DefaultTimerAccuracySec= + + Sets the default accuracy of timer units. This + controls the global default for the + AccuracySec= setting of timer units, see + systemd.timer5 + for details. AccuracySec= set in individual + units override the global default for the specific unit. + Defaults to 1min. Note that the accuracy of timer units is + also affected by the configured timer slack for PID 1, see + TimerSlackNSec= above. + + + + DefaultTimeoutStartSec= + DefaultTimeoutStopSec= + DefaultRestartSec= + + Configures the default timeouts for starting + and stopping of units, as well as the default time to sleep + between automatic restarts of units, as configured per-unit in + TimeoutStartSec=, + TimeoutStopSec= and + RestartSec= (for services, see + systemd.service5 + for details on the per-unit settings). For non-service units, + DefaultTimeoutStartSec= sets the default + TimeoutSec= value. + + + + DefaultStartLimitInterval= + DefaultStartLimitBurst= + + Configure the default unit start rate + limiting, as configured per-service by + StartLimitInterval= and + StartLimitBurst=. See + systemd.service5 + for details on the per-service settings. + + + + DefaultEnvironment= + + Sets manager environment variables passed to + all executed processes. Takes a space-separated list of + variable assignments. See + environ7 + for details about environment variables. + + Example: + + DefaultEnvironment="VAR1=word1 word2" VAR2=word3 "VAR3=word 5 6" + + Sets three variables + VAR1, + VAR2, + VAR3. + + + + DefaultCPUAccounting= + DefaultBlockIOAccounting= + DefaultMemoryAccounting= + + Configure the default resource accounting + settings, as configured per-unit by + CPUAccounting=, + BlockIOAccounting= and + MemoryAccounting=. See + systemd.resource-control5 + for details on the per-unit settings. + + + + DefaultLimitCPU= + DefaultLimitFSIZE= + DefaultLimitDATA= + DefaultLimitSTACK= + DefaultLimitCORE= + DefaultLimitRSS= + DefaultLimitNOFILE= + DefaultLimitAS= + DefaultLimitNPROC= + DefaultLimitMEMLOCK= + DefaultLimitLOCKS= + DefaultLimitSIGPENDING= + DefaultLimitMSGQUEUE= + DefaultLimitNICE= + DefaultLimitRTPRIO= + DefaultLimitRTTIME= + + These settings control various default + resource limits for units. See + setrlimit2 + for details. Use the string infinity to + configure no limit on a specific resource. These settings may + be overridden in individual units using the corresponding + LimitXXX= directives. Note that these resource limits are only + defaults for units, they are not applied to PID 1 + itself. + + + + + + See Also + + systemd1, + systemd.directives7, + systemd.exec5, + systemd.service5, + environ7, + capabilities7 + + diff --git a/man/systemd-sysusers.xml b/man/systemd-sysusers.xml index 68710603ad2..a0c0f996ac0 100644 --- a/man/systemd-sysusers.xml +++ b/man/systemd-sysusers.xml @@ -1,6 +1,6 @@ + "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd"> - - - systemd-sysusers - systemd - - - - Developer - Lennart - Poettering - lennart@poettering.net - - - - - - systemd-sysusers - 8 - - - - systemd-sysusers - systemd-sysusers.service - Allocate system users and groups - - - - - systemd-sysusers - OPTIONS - CONFIGFILE - - - systemd-sysusers.service - - - - Description - - systemd-sysusers creates - system users and groups, based on the file format and - location specified in - sysusers.d5. - - - If invoked with no arguments, it applies all - directives from all files found. If one or more - filenames are passed on the command line, only the - directives in these files are applied. If only the - basename of a file is specified, all directories as - specified in - sysusers.d5 - are searched for a matching file. If the string - - is specified as filenames - entries from the standard input of the process are - read. - - - - Options - - The following options are understood: - - - - - Takes a directory path - as an argument. All paths will be - prefixed with the given alternate root - path, including config search paths. - - - - - - - - - - - Exit status - - On success, 0 is returned, a non-zero failure - code otherwise. - - - - See Also - - systemd1, - sysusers.d5 - - + xmlns:xi="http://www.w3.org/2001/XInclude"> + + + systemd-sysusers + systemd + + + + Developer + Lennart + Poettering + lennart@poettering.net + + + + + + systemd-sysusers + 8 + + + + systemd-sysusers + systemd-sysusers.service + Allocate system users and groups + + + + + systemd-sysusers + OPTIONS + CONFIGFILE + + + systemd-sysusers.service + + + + Description + + systemd-sysusers creates system users and + groups, based on the file format and location specified in + sysusers.d5. + + + If invoked with no arguments, it applies all directives from + all files found. If one or more filenames are passed on the + command line, only the directives in these files are applied. If + only the basename of a file is specified, all directories as + specified in + sysusers.d5 + are searched for a matching file. If the string + - is specified as filenames entries from the + standard input of the process are read. + + + + Options + + The following options are understood: + + + + + Takes a directory path as an argument. All + paths will be prefixed with the given alternate + root path, including config search + paths. + + + + + + + + + + Exit status + + On success, 0 is returned, a non-zero failure code + otherwise. + + + + See Also + + systemd1, + sysusers.d5 + + diff --git a/man/systemd-timedated.service.xml b/man/systemd-timedated.service.xml index aee37db46ec..e44163aefba 100644 --- a/man/systemd-timedated.service.xml +++ b/man/systemd-timedated.service.xml @@ -1,6 +1,6 @@ + "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd"> + "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd"> + "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd"> - - - systemd-tmpfiles - systemd - - - - Developer - Lennart - Poettering - lennart@poettering.net - - - - - - systemd-tmpfiles - 8 - - - - systemd-tmpfiles - systemd-tmpfiles-setup.service - systemd-tmpfiles-setup-dev.service - systemd-tmpfiles-clean.service - systemd-tmpfiles-clean.timer - Creates, deletes and cleans up volatile - and temporary files and directories - - - - - systemd-tmpfiles - OPTIONS - CONFIGFILE - - - systemd-tmpfiles-setup.service - systemd-tmpfiles-setup-dev.service - systemd-tmpfiles-clean.service - systemd-tmpfiles-clean.timer - - - - Description - - systemd-tmpfiles creates, - deletes, and cleans up volatile and temporary files and - directories, based on the configuration file format and - location specified in - tmpfiles.d5. - - - If invoked with no arguments, it applies all - directives from all configuration files. If one or - more filenames are passed on the command line, only - the directives in these files are applied. If only - the basename of a configuration file is specified, - all configuration directories as specified in - tmpfiles.d5 - are searched for a matching file. - - - - Options - - The following options are understood: - - - - - If this option is - passed, all files and directories - marked with f, - F, - w, - d, - D, - v, - p, - L, - c, - b, - m in the - configuration files are created or - written to. Files and directories - marked with z, - Z, - t, - T, - a, and - A have their - ownership, access mode and security - labels set. - - - - - If this option is - passed, all files and directories with - an age parameter configured will be - cleaned up. - - - - - If this option is - passed, the contents of - directories marked with - D or - R, and files or - directories themselves marked with - r or - R are - removed. - - - - Also execute lines - with an exclamation mark. - - - - - Only apply rules with - paths that start with the specified - prefix. This option can be specified - multiple times. - - - - Ignore rules with - paths that start with the specified - prefix. This option can be specified - multiple times. - - - - Takes a directory path - as an argument. All paths will be - prefixed with the given alternate root - path, including config search paths. - - - - - - - - It is possible to combine - , , - and in one invocation. For - example, during boot the following command line is - executed to ensure that all temporary and volatile - directories are removed and created according to the - configuration file: - - systemd-tmpfiles --remove --create - - - - - Unprivileged --cleanup operation - - systemd-tmpfiles tries to - avoid changing the access and modification times on - the directories it accesses, which requires - CAP_ADMIN privileges. When - running as non-root, directories which are checked for - files to clean up will have their access time bumped, - which might prevent their cleanup. - - - - - Exit status - - On success, 0 is returned, a non-zero failure - code otherwise. - - - - See Also - - systemd1, - tmpfiles.d5 - - + xmlns:xi="http://www.w3.org/2001/XInclude"> + + + systemd-tmpfiles + systemd + + + + Developer + Lennart + Poettering + lennart@poettering.net + + + + + + systemd-tmpfiles + 8 + + + + systemd-tmpfiles + systemd-tmpfiles-setup.service + systemd-tmpfiles-setup-dev.service + systemd-tmpfiles-clean.service + systemd-tmpfiles-clean.timer + Creates, deletes and cleans up volatile + and temporary files and directories + + + + + systemd-tmpfiles + OPTIONS + CONFIGFILE + + + systemd-tmpfiles-setup.service + systemd-tmpfiles-setup-dev.service + systemd-tmpfiles-clean.service + systemd-tmpfiles-clean.timer + + + + Description + + systemd-tmpfiles creates, deletes, and + cleans up volatile and temporary files and directories, based on + the configuration file format and location specified in + tmpfiles.d5. + + + If invoked with no arguments, it applies all directives from + all configuration files. If one or more filenames are passed on + the command line, only the directives in these files are applied. + If only the basename of a configuration file is specified, all + configuration directories as specified in + tmpfiles.d5 + are searched for a matching file. + + + + Options + + The following options are understood: + + + + + If this option is passed, all files and + directories marked with + f, + F, + w, + d, + D, + v, + p, + L, + c, + b, + m + in the configuration files are created or written to. Files + and directories marked with + z, + Z, + t, + T, + a, and + A have their ownership, access mode and + security labels set. + + + + + If this option is passed, all files and + directories with an age parameter configured will be cleaned + up. + + + + + If this option is passed, the contents of + directories marked with D or + R, and files or directories themselves + marked with r or R are + removed. + + + + Also execute lines with an exclamation mark. + + + + + Only apply rules with paths that start with + the specified prefix. This option can be specified multiple + times. + + + + Ignore rules with paths that start with the + specified prefix. This option can be specified multiple + times. + + + + Takes a directory path as an argument. All + paths will be prefixed with the given alternate + root path, including config search + paths. + + + + + + + It is possible to combine , + , and in one + invocation. For example, during boot the following command line is + executed to ensure that all temporary and volatile directories are + removed and created according to the configuration file: + + systemd-tmpfiles --remove --create + + + + + Unprivileged --cleanup operation + + systemd-tmpfiles tries to avoid changing + the access and modification times on the directories it accesses, + which requires CAP_ADMIN privileges. When + running as non-root, directories which are checked for files to + clean up will have their access time bumped, which might prevent + their cleanup. + + + + + Exit status + + On success, 0 is returned, a non-zero failure code + otherwise. + + + + See Also + + systemd1, + tmpfiles.d5 + + diff --git a/man/systemd-tty-ask-password-agent.xml b/man/systemd-tty-ask-password-agent.xml index 53bd3aa840e..2876fab6441 100644 --- a/man/systemd-tty-ask-password-agent.xml +++ b/man/systemd-tty-ask-password-agent.xml @@ -1,6 +1,6 @@ + "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd"> - - - systemd-tty-ask-password-agent - systemd - - - - Developer - Lennart - Poettering - lennart@poettering.net - - - - - - systemd-tty-ask-password-agent - 1 - - - - systemd-tty-ask-password-agent - List or process pending systemd password requests - - - - - systemd-tty-ask-password-agent OPTIONS VARIABLE=VALUE - - - - - Description - - systemd-tty-ask-password-agent - is a password agent that handles password - requests of the system, for example for hard disk - encryption passwords or SSL certificate passwords that - need to be queried at boot-time or during - runtime. - - systemd-tty-ask-password-agent - implements the Password - Agents Specification. - - - - - Options - - The following options are understood: - - - - - - Lists all currently pending system password requests. - - - - - - Process all currently - pending system password requests by - querying the user on the calling - TTY. - - - - - - Continuously process - password requests. - - - - - - Forward password - requests to - wall1 - instead of querying the user on the - calling TTY. - - - - - - Ask question with - plymouth8 - instead of querying the user on the - calling TTY. - - - - - - Ask question on - /dev/console - instead of querying the user on the - calling TTY. - - - - - - - - - - Exit status - - On success, 0 is returned, a non-zero failure - code otherwise. - - - - See Also - - systemd1, - systemctl1, - systemd-ask-password-console.service8, - wall1, - plymouth8 - - + xmlns:xi="http://www.w3.org/2001/XInclude"> + + + systemd-tty-ask-password-agent + systemd + + + + Developer + Lennart + Poettering + lennart@poettering.net + + + + + + systemd-tty-ask-password-agent + 1 + + + + systemd-tty-ask-password-agent + List or process pending systemd password requests + + + + + systemd-tty-ask-password-agent OPTIONS VARIABLE=VALUE + + + + + Description + + systemd-tty-ask-password-agent is a + password agent that handles password requests of the system, for + example for hard disk encryption passwords or SSL certificate + passwords that need to be queried at boot-time or during + runtime. + + systemd-tty-ask-password-agent implements + the Password + Agents Specification. + + + + + Options + + The following options are understood: + + + + + + Lists all currently pending system password requests. + + + + + + Process all currently pending system password + requests by querying the user on the calling + TTY. + + + + + + Continuously process password + requests. + + + + + + Forward password requests to + wall1 + instead of querying the user on the calling + TTY. + + + + + + Ask question with + plymouth8 + instead of querying the user on the calling + TTY. + + + + + + Ask question on + /dev/console instead of querying the user + on the calling TTY. + + + + + + + + + + Exit status + + On success, 0 is returned, a non-zero failure + code otherwise. + + + + See Also + + systemd1, + systemctl1, + systemd-ask-password-console.service8, + wall1, + plymouth8 + + diff --git a/man/systemd-update-done.service.xml b/man/systemd-update-done.service.xml index c3b402b601a..d65f1754183 100644 --- a/man/systemd-update-done.service.xml +++ b/man/systemd-update-done.service.xml @@ -21,81 +21,77 @@ --> - - systemd-update-done.service - systemd - - - - Developer - Lennart - Poettering - lennart@poettering.net - - - - - - systemd-update-done.service - 8 - - - - systemd-update-done.service - systemd-update-done - Mark /etc and /var fully updated - - - - systemd-update-done.service - /usr/lib/systemd/systemd-update-done - - - - Description - - systemd-update-done.service - is a service that is invoked as part of the first boot - after the vendor operating system resources in - /usr have been updated. This is - useful to implement offline updates of - /usr which might requires updates - to /etc or - /var on the following boot. - - systemd-update-done.service - updates the file modification time (mtime) of the - stamp files /etc/.updated and - /var/.updated to the modification - time of the /usr directory, - unless the stamp files are already newer. - - Services that shall run after offline upgrades - of /usr should order themselves - before - systemd-update-done.service, and - use the ConditionNeedsUpdate= (see - systemd.unit5) - condition to make sure to run when - /etc or /var - are older than /usr according to - the modification times of the files described - above. This requires that updates to - /usr are always followed by an - update of the modification time of - /usr, for example by invoking - touch1 - on it. - - - - - See Also - - systemd1, - systemd.unit5, - touch1 - - + + systemd-update-done.service + systemd + + + + Developer + Lennart + Poettering + lennart@poettering.net + + + + + + systemd-update-done.service + 8 + + + + systemd-update-done.service + systemd-update-done + Mark /etc and /var fully updated + + + + systemd-update-done.service + /usr/lib/systemd/systemd-update-done + + + + Description + + systemd-update-done.service is a + service that is invoked as part of the first boot after the vendor + operating system resources in /usr have been + updated. This is useful to implement offline updates of + /usr which might requires updates to + /etc or /var on the + following boot. + + systemd-update-done.service updates the + file modification time (mtime) of the stamp files + /etc/.updated and + /var/.updated to the modification time of the + /usr directory, unless the stamp files are + already newer. + + Services that shall run after offline upgrades of + /usr should order themselves before + systemd-update-done.service, and use the + ConditionNeedsUpdate= (see + systemd.unit5) + condition to make sure to run when /etc or + /var are older than /usr + according to the modification times of the files described above. + This requires that updates to /usr are always + followed by an update of the modification time of + /usr, for example by invoking + touch1 + on it. + + + + + See Also + + systemd1, + systemd.unit5, + touch1 + + diff --git a/man/systemd-update-utmp.service.xml b/man/systemd-update-utmp.service.xml index caa1d8f568f..b842d297217 100644 --- a/man/systemd-update-utmp.service.xml +++ b/man/systemd-update-utmp.service.xml @@ -21,56 +21,56 @@ --> - - systemd-update-utmp.service - systemd + + systemd-update-utmp.service + systemd - - - Developer - Lennart - Poettering - lennart@poettering.net - - - + + + Developer + Lennart + Poettering + lennart@poettering.net + + + - - systemd-update-utmp.service - 8 - + + systemd-update-utmp.service + 8 + - - systemd-update-utmp.service - systemd-update-utmp-runlevel.service - systemd-update-utmp - Write audit and utmp updates at bootup, runlevel - changes and shutdown - + + systemd-update-utmp.service + systemd-update-utmp-runlevel.service + systemd-update-utmp + Write audit and utmp updates at bootup, runlevel + changes and shutdown + - - systemd-update-utmp.service - systemd-update-utmp-runlevel.service - /usr/lib/systemd/systemd-update-utmp - + + systemd-update-utmp.service + systemd-update-utmp-runlevel.service + /usr/lib/systemd/systemd-update-utmp + - - Description + + Description - systemd-update-utmp-runlevel.service - is a service that writes SysV runlevel changes to utmp - and wtmp, as well as the audit logs, as they - occur. systemd-update-utmp.service - does the same for system reboots and shutdown requests. - + systemd-update-utmp-runlevel.service is + a service that writes SysV runlevel changes to utmp and wtmp, as + well as the audit logs, as they occur. + systemd-update-utmp.service does the same for + system reboots and shutdown requests. + - - See Also - - systemd1, - utmp5, - auditd8 - - + + See Also + + systemd1, + utmp5, + auditd8 + + diff --git a/man/systemd-user-sessions.service.xml b/man/systemd-user-sessions.service.xml index 767cbc714a4..9d796b1ae1a 100644 --- a/man/systemd-user-sessions.service.xml +++ b/man/systemd-user-sessions.service.xml @@ -21,57 +21,56 @@ --> - - systemd-user-sessions.service - systemd + + systemd-user-sessions.service + systemd - - - Developer - Lennart - Poettering - lennart@poettering.net - - - + + + Developer + Lennart + Poettering + lennart@poettering.net + + + - - systemd-user-sessions.service - 8 - + + systemd-user-sessions.service + 8 + - - systemd-user-sessions.service - systemd-user-sessions - Permit user logins after boot, prohibit user logins at shutdown - + + systemd-user-sessions.service + systemd-user-sessions + Permit user logins after boot, prohibit user logins at shutdown + - - systemd-user-sessions.service - /usr/lib/systemd/systemd-user-sessions - + + systemd-user-sessions.service + /usr/lib/systemd/systemd-user-sessions + - - Description + + Description - systemd-user-sessions.service - is a service that controls user logins. After basic - system initialization is complete it removes - /run/nologin, thus permitting - logins. Before system shutdown it creates - /run/nologin, thus prohibiting - further logins. At the same time it also kills all - user processes, so that system shutdown may proceed - without any remaining user processes around. - + systemd-user-sessions.service is a + service that controls user logins. After basic system + initialization is complete it removes + /run/nologin, thus permitting logins. Before + system shutdown it creates /run/nologin, thus + prohibiting further logins. At the same time it also kills all + user processes, so that system shutdown may proceed without any + remaining user processes around. + - - See Also - - systemd1, - systemd-logind.service8, - pam_nologin8 - - + + See Also + + systemd1, + systemd-logind.service8, + pam_nologin8 + + diff --git a/man/systemd-vconsole-setup.service.xml b/man/systemd-vconsole-setup.service.xml index 3c50799cbd2..59bb5e4e8cb 100644 --- a/man/systemd-vconsole-setup.service.xml +++ b/man/systemd-vconsole-setup.service.xml @@ -21,98 +21,94 @@ --> - - systemd-vconsole-setup.service - systemd - - - - Developer - Lennart - Poettering - lennart@poettering.net - - - - - - systemd-vconsole-setup.service - 8 - - - - systemd-vconsole-setup.service - systemd-vconsole-setup - Configure the virtual console at boot - - - - systemd-vconsole-setup.service - /usr/lib/systemd/systemd-vconsole-setup - - - - Description - - systemd-vconsole-setup.service - is an early-boot service that configures the virtual - console font and console keymap. Internally it calls - loadkeys1 - and - setfont8. - - See - vconsole.conf5 - for information about the configuration files understood by this - service. - - - - - - Kernel Command Line - - A few configuration parameters from - vconsole.conf may be overridden on - the kernel command line: - - - - vconsole.keymap= - vconsole.keymap.toggle= - - Overrides the key - mapping table for the keyboard and the - second toggle keymap. - - - - vconsole.font= - vconsole.font.map= - vconsole.font.unimap= - - Configures the console - font, the console map, and the unicode - font map. - - - - - - See - vconsole.conf5 - for information about these settings. - - - - See Also - - systemd1, - vconsole.conf5, - loadkeys1, - setfont8, - systemd-localed.service8 - - + + systemd-vconsole-setup.service + systemd + + + + Developer + Lennart + Poettering + lennart@poettering.net + + + + + + systemd-vconsole-setup.service + 8 + + + + systemd-vconsole-setup.service + systemd-vconsole-setup + Configure the virtual console at boot + + + + systemd-vconsole-setup.service + /usr/lib/systemd/systemd-vconsole-setup + + + + Description + + systemd-vconsole-setup.service is an + early-boot service that configures the virtual console font and + console keymap. Internally it calls + loadkeys1 + and + setfont8. + + See + vconsole.conf5 + for information about the configuration files understood by this + service. + + + + + + Kernel Command Line + + A few configuration parameters from + vconsole.conf may be overridden on the kernel + command line: + + + + vconsole.keymap= + vconsole.keymap.toggle= + + Overrides the key mapping table for the + keyboard and the second toggle keymap. + + + + vconsole.font= + vconsole.font.map= + vconsole.font.unimap= + + Configures the console font, the console map, + and the unicode font map. + + + + See + vconsole.conf5 + for information about these settings. + + + + See Also + + systemd1, + vconsole.conf5, + loadkeys1, + setfont8, + systemd-localed.service8 + + diff --git a/man/systemd.automount.xml b/man/systemd.automount.xml index f04a4a49276..1aa45938549 100644 --- a/man/systemd.automount.xml +++ b/man/systemd.automount.xml @@ -1,7 +1,7 @@ + "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd"> - - systemd.automount - systemd - - - - Developer - Lennart - Poettering - lennart@poettering.net - - - - - - systemd.automount - 5 - - - - systemd.automount - Automount unit configuration - - - - automount.automount - - - - Description - - A unit configuration file whose name ends in - .automount encodes information - about a file system automount point controlled and - supervised by systemd. - - This man page lists the configuration options - specific to this unit type. See - systemd.unit5 - for the common options of all unit configuration - files. The common configuration items are configured - in the generic [Unit] and [Install] sections. The - automount specific configuration options are configured - in the [Automount] section. - - Automount units must be named after the - automount directories they control. Example: the - automount point /home/lennart - must be configured in a unit file - home-lennart.automount. For - details about the escaping logic used to convert a - file system path to a unit name see - systemd.unit5. - - For each automount unit file a matching mount - unit file (see - systemd.mount5 - for details) must exist which is activated when the - automount path is accessed. Example: if an automount - unit home-lennart.automount is - active and the user accesses - /home/lennart the mount unit - home-lennart.mount will be - activated. - - Automount units may be used to implement - on-demand mounting as well as parallelized mounting of - file systems. - - If an automount point is beneath another mount - point in the file system hierarchy, a dependency - between both units is created automatically. - - - - <filename>fstab</filename> - - Automount units may either be configured via unit - files, or via /etc/fstab (see - fstab5 - for details). - - For details how systemd parses - /etc/fstab see - systemd.mount5. - - If an automount point is configured in both - /etc/fstab and a unit file, the - configuration in the latter takes precedence. - - - - Options - - Automount files must include an [Automount] - section, which carries information about the file - system automount points it supervises. The options - specific to the [Automount] section of automount units - are the following: - - - - - Where= - Takes an absolute path - of a directory of the automount - point. If the automount point does not - exist at time that the automount - point is installed, it is created. This - string must be reflected in the unit - filename. (See above.) This option is - mandatory. - - - - DirectoryMode= - Directories of - automount points (and any parent - directories) are automatically created - if needed. This option specifies the - file system access mode used when - creating these directories. Takes an - access mode in octal - notation. Defaults to - 0755. - - - - - - See Also - - systemd1, - systemctl1, - systemd.unit5, - systemd.mount5, - mount8, - automount8, - systemd.directives7 - - + + systemd.automount + systemd + + + + Developer + Lennart + Poettering + lennart@poettering.net + + + + + + systemd.automount + 5 + + + + systemd.automount + Automount unit configuration + + + + automount.automount + + + + Description + + A unit configuration file whose name ends in + .automount encodes information about a file + system automount point controlled and supervised by + systemd. + + This man page lists the configuration options specific to + this unit type. See + systemd.unit5 + for the common options of all unit configuration files. The common + configuration items are configured in the generic [Unit] and + [Install] sections. The automount specific configuration options + are configured in the [Automount] section. + + Automount units must be named after the automount + directories they control. Example: the automount point + /home/lennart must be + configured in a unit file + home-lennart.automount. For details about the + escaping logic used to convert a file system path to a unit name + see + systemd.unit5. + + For each automount unit file a matching mount unit file (see + systemd.mount5 + for details) must exist which is activated when the automount path + is accessed. Example: if an automount unit + home-lennart.automount is active and the user + accesses /home/lennart the mount unit + home-lennart.mount will be activated. + + Automount units may be used to implement on-demand mounting + as well as parallelized mounting of file systems. + + If an automount point is beneath another mount point in the + file system hierarchy, a dependency between both units is created + automatically. + + + + <filename>fstab</filename> + + Automount units may either be configured via unit files, or + via /etc/fstab (see + fstab5 + for details). + + For details how systemd parses + /etc/fstab see + systemd.mount5. + + If an automount point is configured in both + /etc/fstab and a unit file, the configuration + in the latter takes precedence. + + + + Options + + Automount files must include an [Automount] section, which + carries information about the file system automount points it + supervises. The options specific to the [Automount] section of + automount units are the following: + + + + + Where= + Takes an absolute path of a directory of the + automount point. If the automount point does not exist at time + that the automount point is installed, it is created. This + string must be reflected in the unit filename. (See above.) + This option is mandatory. + + + + DirectoryMode= + Directories of automount points (and any + parent directories) are automatically created if needed. This + option specifies the file system access mode used when + creating these directories. Takes an access mode in octal + notation. Defaults to 0755. + + + + + + See Also + + systemd1, + systemctl1, + systemd.unit5, + systemd.mount5, + mount8, + automount8, + systemd.directives7 + + diff --git a/man/systemd.device.xml b/man/systemd.device.xml index 557f15f906d..829ffd17408 100644 --- a/man/systemd.device.xml +++ b/man/systemd.device.xml @@ -1,7 +1,7 @@ + "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd"> - - systemd.device - systemd - - - - Developer - Lennart - Poettering - lennart@poettering.net - - - - - - systemd.device - 5 - - - - systemd.device - Device unit configuration - - - - device.device - - - - Description - - A unit configuration file whose name ends in - .device encodes information about - a device unit as exposed in the - sysfs/udev7 - device tree. - - This unit type has no specific options. See - systemd.unit5 - for the common options of all unit configuration - files. The common configuration items are configured - in the generic [Unit] and - [Install] sections. A separate - [Device] section does not exist, - since no device-specific options may be - configured. - - systemd will dynamically create device units for - all kernel devices that are marked with the "systemd" - udev tag (by default all block and network devices, - and a few others). This may be used to define - dependencies between devices and other units. To tag a - udev device, use TAG+="systemd" in - the udev rules file, see - udev7 - for details. - - Device units are named after the - /sys and - /dev paths they control. Example: - the device /dev/sda5 is exposed - in systemd as dev-sda5.device. For - details about the escaping logic used to convert a - file system path to a unit name see - systemd.unit5. - - - - - The udev Database - - The settings of device units may either be - configured via unit files, or directly from the udev - database (which is recommended). The following udev device - properties are understood by systemd: - - - - SYSTEMD_WANTS= - SYSTEMD_USER_WANTS= - Adds dependencies of - type Wants from the - device unit to all listed units. The - first form is used by the system - systemd instance, the second by user - systemd instances. Those settings may - be used to activate arbitrary units - when a specific device becomes - available. - - Note that this and the - other tags are not taken into account - unless the device is tagged with the - systemd string in - the udev database, because otherwise - the device is not exposed as a systemd - unit (see above). - - Note that systemd will only act - on Wants - dependencies when a device first - becomes active. It will not act on - them if they are added to devices that - are already active. Use - SYSTEMD_READY= (see - below) to influence on which udev - event to trigger the dependencies. - - - - - SYSTEMD_ALIAS= - Adds an additional - alias name to the device unit. This - must be an absolute path that is - automatically transformed into a unit - name. (See above.) - - - - SYSTEMD_READY= - If set to 0, systemd - will consider this device unplugged - even if it shows up in the udev - tree. If this property is unset or set - to 1, the device will be considered - plugged if it is visible in the - udev tree. This property has no - influence on the behavior when a - device disappears from the udev - tree. - - This option is useful to support - devices that initially show up in an - uninitialized state in the tree, and - for which a changed - event is generated the moment they are - fully set up. Note that - SYSTEMD_WANTS= (see - above) is not acted on as long as - SYSTEMD_READY=0 is - set for a device. - - - - ID_MODEL_FROM_DATABASE= - ID_MODEL= - - If set, this property is - used as description string for the - device unit. - - - - - - - - - See Also - - systemd1, - systemctl1, - systemd.unit5, - udev7, - systemd.directives7 - - + + systemd.device + systemd + + + + Developer + Lennart + Poettering + lennart@poettering.net + + + + + + systemd.device + 5 + + + + systemd.device + Device unit configuration + + + + device.device + + + + Description + + A unit configuration file whose name ends in + .device encodes information about a device unit + as exposed in the + sysfs/udev7 + device tree. + + This unit type has no specific options. See + systemd.unit5 + for the common options of all unit configuration files. The common + configuration items are configured in the generic + [Unit] and [Install] + sections. A separate [Device] section does not + exist, since no device-specific options may be configured. + + systemd will dynamically create device units for all kernel + devices that are marked with the "systemd" udev tag (by default + all block and network devices, and a few others). This may be used + to define dependencies between devices and other units. To tag a + udev device, use TAG+="systemd" in the udev + rules file, see + udev7 + for details. + + Device units are named after the /sys + and /dev paths they control. Example: the + device /dev/sda5 is exposed in + systemd as dev-sda5.device. For details about + the escaping logic used to convert a file system path to a unit + name see + systemd.unit5. + + + + + The udev Database + + The settings of device units may either be configured via + unit files, or directly from the udev database (which is + recommended). The following udev device properties are understood + by systemd: + + + + SYSTEMD_WANTS= + SYSTEMD_USER_WANTS= + Adds dependencies of type + Wants from the device unit to all listed + units. The first form is used by the system systemd instance, + the second by user systemd instances. Those settings may be + used to activate arbitrary units when a specific device + becomes available. + + Note that this and the other tags are not taken into + account unless the device is tagged with the + systemd string in the udev database, + because otherwise the device is not exposed as a systemd unit + (see above). + + Note that systemd will only act on + Wants dependencies when a device first + becomes active. It will not act on them if they are added to + devices that are already active. Use + SYSTEMD_READY= (see below) to influence on + which udev event to trigger the dependencies. + + + + + SYSTEMD_ALIAS= + Adds an additional alias name to the device + unit. This must be an absolute path that is automatically + transformed into a unit name. (See above.) + + + + SYSTEMD_READY= + If set to 0, systemd will consider this device + unplugged even if it shows up in the udev tree. If this + property is unset or set to 1, the device will be considered + plugged if it is visible in the udev tree. This property has + no influence on the behavior when a device disappears from the + udev tree. + + This option is useful to support devices that initially + show up in an uninitialized state in the tree, and for which a + changed event is generated the moment they + are fully set up. Note that SYSTEMD_WANTS= + (see above) is not acted on as long as + SYSTEMD_READY=0 is set for a + device. + + + + ID_MODEL_FROM_DATABASE= + ID_MODEL= + + If set, this property is used as description + string for the device unit. + + + + + + + + See Also + + systemd1, + systemctl1, + systemd.unit5, + udev7, + systemd.directives7 + + diff --git a/man/systemd.exec.xml b/man/systemd.exec.xml index cbaec9f13b6..74d698dbfce 100644 --- a/man/systemd.exec.xml +++ b/man/systemd.exec.xml @@ -1,6 +1,6 @@ + "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd"> - - systemd.exec - systemd - - - - Developer - Lennart - Poettering - lennart@poettering.net - - - - - - systemd.exec - 5 - - - - systemd.exec - Execution environment configuration - - - - service.service, - socket.socket, - mount.mount, - swap.swap - - - - Description - - Unit configuration files for services, sockets, - mount points, and swap devices share a subset of - configuration options which define the execution - environment of spawned processes. - - This man page lists the configuration options - shared by these four unit types. See - systemd.unit5 - for the common options of all unit configuration - files, and - systemd.service5, - systemd.socket5, - systemd.swap5, - and - systemd.mount5 - for more information on the specific unit - configuration files. The execution specific - configuration options are configured in the [Service], - [Socket], [Mount], or [Swap] sections, depending on the unit - type. - - - - Options - - - - - WorkingDirectory= - - Takes an absolute - directory path. Sets the working - directory for executed processes. If - not set, defaults to the root directory - when systemd is running as a system - instance and the respective user's - home directory if run as - user. - - - - RootDirectory= - - Takes an absolute - directory path. Sets the root - directory for executed processes, with - the - chroot2 - system call. If this is used, it must - be ensured that the process and all - its auxiliary files are available in - the chroot() - jail. - - - - User= - Group= - - Sets the Unix user - or group that the processes are executed - as, respectively. Takes a single user or group - name or ID as argument. If no group is - set, the default group of the user is - chosen. - - - - SupplementaryGroups= - - Sets the supplementary - Unix groups the processes are executed - as. This takes a space-separated list - of group names or IDs. This option may - be specified more than once in which - case all listed groups are set as - supplementary groups. When the empty - string is assigned the list of - supplementary groups is reset, and all - assignments prior to this one will - have no effect. In any way, this - option does not override, but extends - the list of supplementary groups - configured in the system group - database for the - user. - - - - Nice= - - Sets the default nice - level (scheduling priority) for - executed processes. Takes an integer - between -20 (highest priority) and 19 - (lowest priority). See - setpriority2 - for details. - - - - OOMScoreAdjust= - - Sets the adjustment - level for the Out-Of-Memory killer for - executed processes. Takes an integer - between -1000 (to disable OOM killing - for this process) and 1000 (to make - killing of this process under memory - pressure very likely). See proc.txt - for details. - - - - IOSchedulingClass= - - Sets the IO scheduling - class for executed processes. Takes an - integer between 0 and 3 or one of the - strings , - , - or - . See - ioprio_set2 - for details. - - - - IOSchedulingPriority= - - Sets the IO scheduling - priority for executed processes. Takes - an integer between 0 (highest - priority) and 7 (lowest priority). The - available priorities depend on the - selected IO scheduling class (see - above). See - ioprio_set2 - for details. - - - - CPUSchedulingPolicy= - - Sets the CPU - scheduling policy for executed - processes. Takes one of - , - , - , - or - . See - sched_setscheduler2 - for details. - - - - CPUSchedulingPriority= - - Sets the CPU - scheduling priority for executed - processes. The available priority - range depends on the selected CPU - scheduling policy (see above). For - real-time scheduling policies an - integer between 1 (lowest priority) - and 99 (highest priority) can be used. - See sched_setscheduler2 - for details. - - - - - CPUSchedulingResetOnFork= - - Takes a boolean - argument. If true, elevated CPU - scheduling priorities and policies - will be reset when the executed - processes fork, and can hence not leak - into child processes. See - sched_setscheduler2 - for details. Defaults to false. - - - - CPUAffinity= - - Controls the CPU - affinity of the executed - processes. Takes a space-separated - list of CPU indices. This option may - be specified more than once in which - case the specified CPU affinity masks - are merged. If the empty string is - assigned, the mask is reset, all - assignments prior to this will have no - effect. See - sched_setaffinity2 - for details. - - - - UMask= - - Controls the file mode - creation mask. Takes an access mode in - octal notation. See - umask2 - for details. Defaults to - 0022. - - - - Environment= - - Sets environment - variables for executed - processes. Takes a space-separated - list of variable assignments. This - option may be specified more than once - in which case all listed variables - will be set. If the same variable is - set twice, the later setting will - override the earlier setting. If the - empty string is assigned to this - option, the list of environment - variables is reset, all prior - assignments have no effect. - Variable expansion is not performed - inside the strings, however, specifier - expansion is possible. The $ character has - no special meaning. - If you need to assign a value containing spaces - to a variable, use double quotes (") - for the assignment. - - Example: - Environment="VAR1=word1 word2" VAR2=word3 "VAR3=$word 5 6" - gives three variables VAR1, - VAR2, VAR3 - with the values word1 word2, - word3, $word 5 6. - - - - See - environ7 - for details about environment variables. - - - EnvironmentFile= - Similar to - Environment= but - reads the environment variables from a - text file. The text file should - contain new-line-separated variable - assignments. Empty lines and lines - starting with ; or # will be ignored, - which may be used for commenting. A line - ending with a backslash will be concatenated - with the following one, allowing multiline variable - definitions. The parser strips leading - and trailing whitespace from the values - of assignments, unless you use - double quotes ("). - - The argument passed should be an - absolute filename or wildcard - expression, optionally prefixed with - -, which indicates - that if the file does not exist, it - will not be read and no error or warning - message is logged. This option may be - specified more than once in which case - all specified files are read. If the - empty string is assigned to this - option, the list of file to read is - reset, all prior assignments have no - effect. - - The files listed with this - directive will be read shortly before - the process is executed (more - specifically, after all - processes from a previous unit state - terminated. This means you can - generate these files in one unit - state, and read it with this option in - the next). Settings from these files - override settings made with - Environment=. If - the same variable is set twice from - these files, the files will be read in - the order they are specified and the - later setting will override the - earlier setting. - - - - StandardInput= - Controls where file - descriptor 0 (STDIN) of the executed - processes is connected to. Takes one - of , - , - , - or - . - - If is - selected, standard input will be - connected to - /dev/null, - i.e. all read attempts by the process - will result in immediate EOF. - - If is - selected, standard input is connected - to a TTY (as configured by - TTYPath=, see - below) and the executed process - becomes the controlling process of the - terminal. If the terminal is already - being controlled by another process, - the executed process waits until the - current controlling process releases - the terminal. - - is similar - to , but the - executed process is forcefully and - immediately made the controlling - process of the terminal, potentially - removing previous controlling - processes from the - terminal. - - is - similar to but if - the terminal already has a controlling - process start-up of the executed - process fails. - - The - option is only valid in - socket-activated services, and only - when the socket configuration file - (see - systemd.socket5 - for details) specifies a single socket - only. If this option is set, standard - input will be connected to the socket - the service was activated from, which - is primarily useful for compatibility - with daemons designed for use with the - traditional - inetd8 - daemon. - - This setting defaults to - . - - - StandardOutput= - Controls where file - descriptor 1 (STDOUT) of the executed - processes is connected to. Takes one - of , - , - , - , - , - , - , - , - or - . - - - duplicates the file descriptor of - standard input for standard - output. - - connects - standard output to - /dev/null, - i.e. everything written to it will be - lost. - - connects - standard output to a tty (as - configured via - TTYPath=, see - below). If the TTY is used for output - only, the executed process will not - become the controlling process of the - terminal, and will not fail or wait - for other processes to release the - terminal. - - - connects standard output with the - journal which is accessible via - journalctl1. - Note that everything that is written - to syslog or kmsg (see below) is - implicitly stored in the journal as - well, the specific two options listed - below are hence supersets of this - one. - - connects - standard output to the syslog3 - system syslog service, in addition to - the journal. Note that the journal - daemon is usually configured to - forward everything it receives to - syslog anyway, in which case this - option is no different from - . - - connects - standard output with the kernel log - buffer which is accessible via - dmesg1, - in addition to the journal. The - journal daemon might be configured to - send all logs to kmsg anyway, in which - case this option is no different from - . - - , - and - work in - a similar way as the three options - above but copy the output to the - system console as well. - - connects - standard output to a socket acquired - via socket activation. The semantics - are similar to the same option of - StandardInput=. - - This setting defaults to the - value set with - - in - systemd-system.conf5, - which defaults to - . - - - StandardError= - Controls where file - descriptor 2 (STDERR) of the - executed processes is connected to. - The available options are identical to - those of - StandardOutput=, - with one exception: if set to - the file - descriptor used for standard output is - duplicated for standard error. This - setting defaults to the value set with - - in - systemd-system.conf5, - which defaults to - . - - - TTYPath= - Sets the terminal - device node to use if standard input, output, - or error are connected to a - TTY (see above). Defaults to - /dev/console. - - - TTYReset= - Reset the terminal - device specified with - TTYPath= before and - after execution. Defaults to - no. - - - TTYVHangup= - Disconnect all clients - which have opened the terminal device - specified with - TTYPath= - before and after execution. Defaults - to - no. - - - TTYVTDisallocate= - If the terminal - device specified with - TTYPath= is a - virtual console terminal, try to - deallocate the TTY before and after - execution. This ensures that the - screen and scrollback buffer is - cleared. Defaults to - no. - - - SyslogIdentifier= - Sets the process name - to prefix log lines sent to the - logging system or the kernel log - buffer with. If not set, defaults to - the process name of the executed - process. This option is only useful - when - StandardOutput= or - StandardError= are - set to , - or - (or to the same - settings in combination with - ). - - - SyslogFacility= - Sets the syslog - facility to use when logging to - syslog. One of , - , - , - , - , - , - , - , - , - , - , - , - , - , - , - , - , - , - or - . See - syslog3 - for details. This option is only - useful when - StandardOutput= or - StandardError= are - set to . - Defaults to - . - - - SyslogLevel= - Default syslog level - to use when logging to syslog or the - kernel log buffer. One of - , - , - , - , - , - , - , - . See - syslog3 - for details. This option is only - useful when - StandardOutput= or - StandardError= are - set to or - . Note that - individual lines output by the daemon - might be prefixed with a different log - level which can be used to override - the default log level specified - here. The interpretation of these - prefixes may be disabled with - SyslogLevelPrefix=, - see below. For details see - sd-daemon3. - - Defaults to - . - - - - SyslogLevelPrefix= - Takes a boolean - argument. If true and - StandardOutput= or - StandardError= are - set to , - or - , log lines - written by the executed process that - are prefixed with a log level will be - passed on to syslog with this log - level set but the prefix removed. If - set to false, the interpretation of - these prefixes is disabled and the - logged lines are passed on as-is. For - details about this prefixing see - sd-daemon3. - Defaults to true. - - - - TimerSlackNSec= - Sets the timer slack - in nanoseconds for the executed - processes. The timer slack controls - the accuracy of wake-ups triggered by - timers. See - prctl2 - for more information. Note that in - contrast to most other time span - definitions this parameter takes an - integer value in nano-seconds if no - unit is specified. The usual time - units are understood - too. - - - - LimitCPU= - LimitFSIZE= - LimitDATA= - LimitSTACK= - LimitCORE= - LimitRSS= - LimitNOFILE= - LimitAS= - LimitNPROC= - LimitMEMLOCK= - LimitLOCKS= - LimitSIGPENDING= - LimitMSGQUEUE= - LimitNICE= - LimitRTPRIO= - LimitRTTIME= - These settings set both - soft and hard limits of various resources for - executed processes. See - setrlimit2 - for details. Use the string - infinity to - configure no limit on a specific - resource. - - - Limit directives and their equivalent with ulimit - - - - - - - Directive - ulimit equivalent - - - - - LimitCPU - ulimit -t - - - LimitFSIZE - ulimit -f - - - LimitDATA - ulimit -d - - - LimitSTACK - ulimit -s - - - LimitCORE - ulimit -c - - - LimitRSS - ulimit -m - - - LimitNOFILE - ulimit -n - - - LimitAS - ulimit -v - - - LimitNPROC - ulimit -u - - - LimitMEMLOCK - ulimit -l - - - LimitLOCKS - ulimit -x - - - LimitSIGPENDING - ulimit -i - - - LimitMSGQUEUE - ulimit -q - - - LimitNICE - ulimit -e - - - LimitRTPRIO - ulimit -r - - - LimitRTTIME - No equivalent - - - -
- - - - PAMName= - Sets the PAM service - name to set up a session as. If set, - the executed process will be - registered as a PAM session under the - specified service name. This is only - useful in conjunction with the - User= setting. If - not set, no PAM session will be opened - for the executed processes. See - pam8 - for details. - - - - CapabilityBoundingSet= - - Controls which - capabilities to include in the - capability bounding set for the - executed process. See - capabilities7 - for details. Takes a whitespace-separated - list of capability names as read by - cap_from_name3, - e.g. CAP_SYS_ADMIN, - CAP_DAC_OVERRIDE, - CAP_SYS_PTRACE. - Capabilities listed will be included - in the bounding set, all others are - removed. If the list of capabilities - is prefixed with ~, - all but the listed capabilities will - be included, the effect of the - assignment inverted. Note that this - option also affects the respective - capabilities in the effective, - permitted and inheritable capability - sets, on top of what - Capabilities= - does. If this option is not used, the - capability bounding set is not - modified on process execution, hence - no limits on the capabilities of the - process are enforced. This option may - appear more than once in which case - the bounding sets are merged. If the - empty string is assigned to this - option, the bounding set is reset to - the empty capability set, and all - prior settings have no effect. If set - to ~ (without any - further argument), the bounding set is - reset to the full set of available - capabilities, also undoing any - previous settings. - - - - SecureBits= - Controls the secure - bits set for the executed process. - Takes a space-separated combination of - options from the following list: - , - , - , - , - , and - . This - option may appear more than once in - which case the secure bits are ORed. - If the empty string is assigned to - this option, the bits are reset to 0. - See capabilities7 - for details. - - - - Capabilities= - Controls the - capabilities7 - set for the executed process. Take a - capability string describing the - effective, permitted and inherited - capability sets as documented in - cap_from_text3. - Note that these capability sets are - usually influenced (and filtered) by the capabilities - attached to the executed file. Due to - that - CapabilityBoundingSet= - is probably a much more useful - setting. - - - - ReadWriteDirectories= - ReadOnlyDirectories= - InaccessibleDirectories= - - Sets up a new file - system namespace for executed - processes. These options may be used - to limit access a process might have - to the main file system - hierarchy. Each setting takes a - space-separated list of absolute - directory paths. Directories listed in - ReadWriteDirectories= - are accessible from within the - namespace with the same access rights - as from outside. Directories listed in - ReadOnlyDirectories= - are accessible for reading only, - writing will be refused even if the - usual file access controls would - permit this. Directories listed in - InaccessibleDirectories= - will be made inaccessible for - processes inside the namespace. Note - that restricting access with these - options does not extend to submounts - of a directory that are created later - on. These options may be specified - more than once in which case all - directories listed will have limited - access from within the namespace. If - the empty string is assigned to this - option, the specific list is reset, - and all prior assignments have no - effect. - Paths in - ReadOnlyDirectories= - and - InaccessibleDirectories= - may be prefixed with - -, in which case - they will be ignored when they do not - exist. Note that using this - setting will disconnect propagation of - mounts from the service to the host - (propagation in the opposite direction - continues to work). This means that - this setting may not be used for - services which shall be able to - install mount points in the main mount - namespace. - - - - PrivateTmp= - - Takes a boolean - argument. If true, sets up a new file - system namespace for the executed - processes and mounts private - /tmp and - /var/tmp - directories inside it that is not - shared by processes outside of the - namespace. This is useful to secure - access to temporary files of the - process, but makes sharing between - processes via - /tmp or - /var/tmp - impossible. If this is enabled, all - temporary files created by a service - in these directories will be removed - after the service is stopped. Defaults - to false. It is possible to run two or - more units within the same private - /tmp and - /var/tmp - namespace by using the - JoinsNamespaceOf= - directive, see - systemd.unit5 - for details. Note that using this - setting will disconnect propagation of - mounts from the service to the host - (propagation in the opposite direction - continues to work). This means that - this setting may not be used for - services which shall be able to install - mount points in the main mount - namespace. - - - - PrivateDevices= - - Takes a boolean - argument. If true, sets up a new /dev - namespace for the executed processes - and only adds API pseudo devices such - as /dev/null, - /dev/zero or - /dev/random (as - well as the pseudo TTY subsystem) to - it, but no physical devices such as - /dev/sda. This is - useful to securely turn off physical - device access by the executed - process. Defaults to false. Enabling - this option will also remove - CAP_MKNOD from - the capability bounding set for the - unit (see above), and set - DevicePolicy=closed - (see - systemd.resource-control5 - for details). Note that using this - setting will disconnect propagation of - mounts from the service to the host - (propagation in the opposite direction - continues to work). This means that - this setting may not be used for - services which shall be able to - install mount points in the main mount - namespace. - - - - PrivateNetwork= - - Takes a boolean - argument. If true, sets up a new - network namespace for the executed - processes and configures only the - loopback network device - lo inside it. No - other network devices will be - available to the executed process. - This is useful to securely turn off - network access by the executed - process. Defaults to false. It is - possible to run two or more units - within the same private network - namespace by using the - JoinsNamespaceOf= - directive, see - systemd.unit5 - for details. Note that this option - will disconnect all socket families - from the host, this includes - AF_NETLINK and AF_UNIX. The latter has - the effect that AF_UNIX sockets in the - abstract socket namespace will become - unavailable to the processes (however, - those located in the file system will - continue to be - accessible). - - - - ProtectSystem= - - Takes a boolean - argument or - full. If true, - mounts the /usr - and /boot - directories read-only for processes - invoked by this unit. If set to - full, the - /etc directory is - mounted read-only, too. This setting - ensures that any modification of the - vendor supplied operating system (and - optionally its configuration) is - prohibited for the service. It is - recommended to enable this setting for - all long-running services, unless they - are involved with system updates or - need to modify the operating system in - other ways. Note however that - processes retaining the CAP_SYS_ADMIN - capability can undo the effect of this - setting. This setting is hence - particularly useful for daemons which - have this capability removed, for - example with - CapabilityBoundingSet=. Defaults - to off. - - - - ProtectHome= - - Takes a boolean - argument or - read-only. If true, - the directories - /home and - /run/user are - made inaccessible and empty for - processes invoked by this unit. If set - to read-only, the - two directories are made read-only - instead. It is recommended to enable - this setting for all long-running - services (in particular network-facing - ones), to ensure they cannot get access - to private user data, unless the - services actually require access to - the user's private data. Note however - that processes retaining the - CAP_SYS_ADMIN capability can undo the - effect of this setting. This setting - is hence particularly useful for - daemons which have this capability - removed, for example with - CapabilityBoundingSet=. Defaults - to off. - - - - MountFlags= - - Takes a mount - propagation flag: - , - or - , which - control whether mounts in the file - system namespace set up for this - unit's processes will receive or - propagate mounts or unmounts. See - mount2 - for details. Defaults to - . Use - to ensure that - mounts and unmounts are propagated - from the host to the container and - vice versa. Use - to run processes so that none of their - mounts and unmounts will propagate to - the host. Use - to also ensure that no mounts and - unmounts from the host will propagate - into the unit processes' - namespace. Note that - means that file - systems mounted on the host might stay - mounted continuously in the unit's - namespace, and thus keep the device - busy. Note that the file system - namespace related options - (PrivateTmp=, - PrivateDevices=, - ProtectSystem=, - ProtectHome=, - ReadOnlyDirectories=, - InaccessibleDirectories= - and - ReadWriteDirectories=) - require that mount and unmount - propagation from the unit's file - system namespace is disabled, and - hence downgrade - to - . - - - - - UtmpIdentifier= - - Takes a four - character identifier string for an - utmp/wtmp entry for this service. This - should only be set for services such - as getty - implementations where utmp/wtmp - entries must be created and cleared - before and after execution. If the - configured string is longer than four - characters, it is truncated and the - terminal four characters are - used. This setting interprets %I style - string replacements. This setting is - unset by default, i.e. no utmp/wtmp - entries are created or cleaned up for - this service. - - - - SELinuxContext= - - Set the SELinux - security context of the executed - process. If set, this will override - the automated domain - transition. However, the policy still - needs to authorize the transition. This - directive is ignored if SELinux is - disabled. If prefixed by - -, all errors will - be ignored. See - setexeccon3 - for details. - - - - AppArmorProfile= - - Takes a profile name as argument. - The process executed by the unit will switch to - this profile when started. Profiles must already - be loaded in the kernel, or the unit will fail. - This result in a non operation if AppArmor is not - enabled. If prefixed by -, all errors - will be ignored. - - - - - SmackProcessLabel= - - Takes a - security - label as argument. The process - executed by the unit will be started - under this label and SMACK will decide - whether the processes is allowed to - run or not based on it. The process - will continue to run under the label - specified here unless the executable - has its own - label, in - which case the process will transition - to run under that label. When not - specified, the label that systemd is - running under is used. This directive - is ignored if SMACK is - disabled. - - The value may be prefixed by - -, in which case - all errors will be ignored. An empty - value may be specified to unset - previous assignments. - - - - - IgnoreSIGPIPE= - - Takes a boolean - argument. If true, causes SIGPIPE to be - ignored in the executed - process. Defaults to true because - SIGPIPE generally is useful only in - shell pipelines. - - - - NoNewPrivileges= - - Takes a boolean - argument. If true, ensures that the - service process and all its children - can never gain new privileges. This - option is more powerful than the respective - secure bits flags (see above), as it - also prohibits UID changes of any - kind. This is the simplest, most - effective way to ensure that a process - and its children can never elevate - privileges again. - - - - SystemCallFilter= - - Takes a - space-separated list of system call - names. If this setting is used, all - system calls executed by the unit - processes except for the listed ones - will result in immediate process - termination with the - SIGSYS signal - (whitelisting). If the first character - of the list is ~, - the effect is inverted: only the - listed system calls will result in - immediate process termination - (blacklisting). If running in user - mode and this option is used, - NoNewPrivileges=yes - is implied. This feature makes use of the - Secure Computing Mode 2 interfaces of - the kernel ('seccomp filtering') and - is useful for enforcing a minimal - sandboxing environment. Note that the - execve, - rt_sigreturn, - sigreturn, - exit_group, - exit system calls - are implicitly whitelisted and do not - need to be listed explicitly. This - option may be specified more than once - in which case the filter masks are - merged. If the empty string is - assigned, the filter is reset, all - prior assignments will have no - effect. - - If you specify both types of - this option (i.e. whitelisting and - blacklisting), the first encountered - will take precedence and will dictate - the default action (termination or - approval of a system call). Then the - next occurrences of this option will - add or delete the listed system calls - from the set of the filtered system - calls, depending of its type and the - default action. (For example, if you have started - with a whitelisting of - read and - write, and right - after it add a blacklisting of - write, then - write will be - removed from the set.) - - - - - SystemCallErrorNumber= - - Takes an - errno error number - name to return when the system call - filter configured with - SystemCallFilter= - is triggered, instead of terminating - the process immediately. Takes an - error name such as - EPERM, - EACCES or - EUCLEAN. When this - setting is not used, or when the empty - string is assigned, the process will be - terminated immediately when the filter - is triggered. - - - - SystemCallArchitectures= - - Takes a space - separated list of architecture - identifiers to include in the system - call filter. The known architecture - identifiers are - x86, - x86-64, - x32, - arm as well as - the special identifier - native. Only - system calls of the specified - architectures will be permitted to - processes of this unit. This is an - effective way to disable compatibility - with non-native architectures for - processes, for example to prohibit - execution of 32-bit x86 binaries on - 64-bit x86-64 systems. The special - native identifier - implicitly maps to the native - architecture of the system (or more - strictly: to the architecture the - system manager is compiled for). If - running in user mode and this option - is used, - NoNewPrivileges=yes - is implied. Note that setting this - option to a non-empty list implies - that native is - included too. By default, this option - is set to the empty list, i.e. no - architecture system call filtering is - applied. - - - - RestrictAddressFamilies= - - Restricts the set of - socket address families accessible to - the processes of this unit. Takes a - space-separated list of address family - names to whitelist, such as - AF_UNIX, - AF_INET or - AF_INET6. When - prefixed with ~ - the listed address families will be - applied as blacklist, otherwise as - whitelist. Note that this restricts - access to the - socket2 - system call only. Sockets passed into - the process by other means (for - example, by using socket activation - with socket units, see - systemd.socket5) - are unaffected. Also, sockets created - with socketpair() - (which creates connected AF_UNIX - sockets only) are unaffected. Note - that this option has no effect on - 32-bit x86 and is ignored (but works - correctly on x86-64). If running in user - mode and this option is used, - NoNewPrivileges=yes - is implied. By default, no - restriction applies, all address - families are accessible to - processes. If assigned the empty - string, any previous list changes are - undone. - - Use this option to limit - exposure of processes to remote - systems, in particular via exotic - network protocols. Note that in most - cases, the local - AF_UNIX address - family should be included in the - configured whitelist as it is - frequently used for local - communication, including for - syslog2 - logging. - - - - Personality= - - Controls which - kernel architecture - uname2 - shall report, when invoked by unit - processes. Takes one of - x86 and - x86-64. This is - useful when running 32-bit services on - a 64-bit host system. If not specified, - the personality is left unmodified and - thus reflects the personality of the - host system's - kernel. - - - - RuntimeDirectory= - RuntimeDirectoryMode= - - Takes a list of - directory names. If set, one or more - directories by the specified names - will be created below - /run (for system - services) or below - $XDG_RUNTIME_DIR - (for user services) when the unit is - started, and removed when the unit is - stopped. The directories will have the - access mode specified in - RuntimeDirectoryMode=, - and will be owned by the user and - group specified in - User= and - Group=. Use this to - manage one or more runtime directories - of the unit and bind their lifetime to - the daemon runtime. The specified - directory names must be relative, and - may not include a - /, i.e. must refer - to simple directories to create or - remove. This is particularly useful - for unprivileged daemons that cannot - create runtime directories in - /run due to lack - of privileges, and to make sure the - runtime directory is cleaned up - automatically after use. For runtime - directories that require more complex - or different configuration or lifetime - guarantees, please consider using - tmpfiles.d5. - - - - - - - Environment variables in spawned processes - - Processes started by the system are executed in - a clean environment in which select variables - listed below are set. System processes started by systemd - do not inherit variables from PID 1, but processes - started by user systemd instances inherit all - environment variables from the user systemd instance. - - - - - $PATH - - Colon-separated list - of directories to use when launching - executables. Systemd uses a fixed - value of - /usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin. - - - - - $LANG - - Locale. Can be set in - locale.conf5 - or on the kernel command line (see - systemd1 - and - kernel-command-line7). - - - - - $USER - $LOGNAME - $HOME - $SHELL - - User name (twice), home - directory, and the login shell. - The variables are set for the units that - have User= set, - which includes user - systemd instances. - See - passwd5. - - - - - $XDG_RUNTIME_DIR - - The directory for volatile - state. Set for the user systemd - instance, and also in user sessions. - See - pam_systemd8. - - - - - $XDG_SESSION_ID - $XDG_SEAT - $XDG_VTNR - - The identifier of the - session, the seat name, and - virtual terminal of the session. Set - by - pam_systemd8 - for login sessions. - $XDG_SEAT and - $XDG_VTNR will - only be set when attached to a seat and a - tty. - - - - $MAINPID - - The PID of the units - main process if it is known. This is - only set for control processes as - invoked by - ExecReload= and - similar. - - - - $MANAGERPID - - The PID of the user - systemd instance, - set for processes spawned by it. - - - - - $LISTEN_FDS - $LISTEN_PID - - Information about file - descriptors passed to a service for - socket activation. See - sd_listen_fds3. - - - - - $TERM - - Terminal type, set - only for units connected to a terminal - (StandardInput=tty, - StandardOutput=tty, - or - StandardError=tty). - See - termcap5. - - - - - Additional variables may be configured by the - following means: for processes spawned in specific - units, use the Environment= and - EnvironmentFile= options above; to - specify variables globally, use - DefaultEnvironment= (see - systemd-system.conf5) - or the kernel option - systemd.setenv= (see - systemd1). Additional - variables may also be set through PAM, - cf. pam_env8. - - - - See Also - - systemd1, - systemctl1, - journalctl8, - systemd.unit5, - systemd.service5, - systemd.socket5, - systemd.swap5, - systemd.mount5, - systemd.kill5, - systemd.resource-control5, - systemd.directives7, - tmpfiles.d5, - exec3 - - + + systemd.exec + systemd + + + + Developer + Lennart + Poettering + lennart@poettering.net + + + + + + systemd.exec + 5 + + + + systemd.exec + Execution environment configuration + + + + service.service, + socket.socket, + mount.mount, + swap.swap + + + + Description + + Unit configuration files for services, sockets, mount + points, and swap devices share a subset of configuration options + which define the execution environment of spawned + processes. + + This man page lists the configuration options shared by + these four unit types. See + systemd.unit5 + for the common options of all unit configuration files, and + systemd.service5, + systemd.socket5, + systemd.swap5, + and + systemd.mount5 + for more information on the specific unit configuration files. The + execution specific configuration options are configured in the + [Service], [Socket], [Mount], or [Swap] sections, depending on the + unit type. + + + + Options + + + + + WorkingDirectory= + + Takes an absolute directory path. Sets the + working directory for executed processes. If not set, defaults + to the root directory when systemd is running as a system + instance and the respective user's home directory if run as + user. + + + + RootDirectory= + + Takes an absolute directory path. Sets the + root directory for executed processes, with the + chroot2 + system call. If this is used, it must be ensured that the + process and all its auxiliary files are available in the + chroot() jail. + + + + User= + Group= + + Sets the Unix user or group that the processes + are executed as, respectively. Takes a single user or group + name or ID as argument. If no group is set, the default group + of the user is chosen. + + + + SupplementaryGroups= + + Sets the supplementary Unix groups the + processes are executed as. This takes a space-separated list + of group names or IDs. This option may be specified more than + once in which case all listed groups are set as supplementary + groups. When the empty string is assigned the list of + supplementary groups is reset, and all assignments prior to + this one will have no effect. In any way, this option does not + override, but extends the list of supplementary groups + configured in the system group database for the + user. + + + + Nice= + + Sets the default nice level (scheduling + priority) for executed processes. Takes an integer between -20 + (highest priority) and 19 (lowest priority). See + setpriority2 + for details. + + + + OOMScoreAdjust= + + Sets the adjustment level for the + Out-Of-Memory killer for executed processes. Takes an integer + between -1000 (to disable OOM killing for this process) and + 1000 (to make killing of this process under memory pressure + very likely). See proc.txt + for details. + + + + IOSchedulingClass= + + Sets the IO scheduling class for executed + processes. Takes an integer between 0 and 3 or one of the + strings , , + or . See + ioprio_set2 + for details. + + + + IOSchedulingPriority= + + Sets the IO scheduling priority for executed + processes. Takes an integer between 0 (highest priority) and 7 + (lowest priority). The available priorities depend on the + selected IO scheduling class (see above). See + ioprio_set2 + for details. + + + + CPUSchedulingPolicy= + + Sets the CPU scheduling policy for executed + processes. Takes one of + , + , + , + or + . See + sched_setscheduler2 + for details. + + + + CPUSchedulingPriority= + + Sets the CPU scheduling priority for executed + processes. The available priority range depends on the + selected CPU scheduling policy (see above). For real-time + scheduling policies an integer between 1 (lowest priority) and + 99 (highest priority) can be used. See + sched_setscheduler2 + for details. + + + + CPUSchedulingResetOnFork= + + Takes a boolean argument. If true, elevated + CPU scheduling priorities and policies will be reset when the + executed processes fork, and can hence not leak into child + processes. See + sched_setscheduler2 + for details. Defaults to false. + + + + CPUAffinity= + + Controls the CPU affinity of the executed + processes. Takes a space-separated list of CPU indices. This + option may be specified more than once in which case the + specified CPU affinity masks are merged. If the empty string + is assigned, the mask is reset, all assignments prior to this + will have no effect. See + sched_setaffinity2 + for details. + + + + UMask= + + Controls the file mode creation mask. Takes an + access mode in octal notation. See + umask2 + for details. Defaults to 0022. + + + + Environment= + + Sets environment variables for executed + processes. Takes a space-separated list of variable + assignments. This option may be specified more than once in + which case all listed variables will be set. If the same + variable is set twice, the later setting will override the + earlier setting. If the empty string is assigned to this + option, the list of environment variables is reset, all prior + assignments have no effect. Variable expansion is not + performed inside the strings, however, specifier expansion is + possible. The $ character has no special meaning. If you need + to assign a value containing spaces to a variable, use double + quotes (") for the assignment. + + Example: + Environment="VAR1=word1 word2" VAR2=word3 "VAR3=$word 5 6" + gives three variables VAR1, + VAR2, VAR3 + with the values word1 word2, + word3, $word 5 6. + + + + See + environ7 + for details about environment variables. + + + EnvironmentFile= + Similar to Environment= but + reads the environment variables from a text file. The text + file should contain new-line-separated variable assignments. + Empty lines and lines starting with ; or # will be ignored, + which may be used for commenting. A line ending with a + backslash will be concatenated with the following one, + allowing multiline variable definitions. The parser strips + leading and trailing whitespace from the values of + assignments, unless you use double quotes ("). + + The argument passed should be an absolute filename or + wildcard expression, optionally prefixed with + -, which indicates that if the file does + not exist, it will not be read and no error or warning message + is logged. This option may be specified more than once in + which case all specified files are read. If the empty string + is assigned to this option, the list of file to read is reset, + all prior assignments have no effect. + + The files listed with this directive will be read + shortly before the process is executed (more specifically, + after all processes from a previous unit state terminated. + This means you can generate these files in one unit state, and + read it with this option in the next). Settings from these + files override settings made with + Environment=. If the same variable is set + twice from these files, the files will be read in the order + they are specified and the later setting will override the + earlier setting. + + + + StandardInput= + Controls where file descriptor 0 (STDIN) of + the executed processes is connected to. Takes one of + , + , + , + or + . + + If is selected, standard input + will be connected to /dev/null, i.e. all + read attempts by the process will result in immediate + EOF. + + If is selected, standard input is + connected to a TTY (as configured by + TTYPath=, see below) and the executed + process becomes the controlling process of the terminal. If + the terminal is already being controlled by another process, + the executed process waits until the current controlling + process releases the terminal. + + is similar to + , but the executed process is forcefully + and immediately made the controlling process of the terminal, + potentially removing previous controlling processes from the + terminal. + + is similar to + but if the terminal already has a + controlling process start-up of the executed process + fails. + + The option is only valid in + socket-activated services, and only when the socket + configuration file (see + systemd.socket5 + for details) specifies a single socket only. If this option is + set, standard input will be connected to the socket the + service was activated from, which is primarily useful for + compatibility with daemons designed for use with the + traditional + inetd8 + daemon. + + This setting defaults to + . + + + StandardOutput= + Controls where file descriptor 1 (STDOUT) of + the executed processes is connected to. Takes one of + , + , + , + , + , + , + , + , + or + . + + duplicates the file descriptor + of standard input for standard output. + + connects standard output to + /dev/null, i.e. everything written to it + will be lost. + + connects standard output to a tty + (as configured via TTYPath=, see below). If + the TTY is used for output only, the executed process will not + become the controlling process of the terminal, and will not + fail or wait for other processes to release the + terminal. + + connects standard output with + the journal which is accessible via + journalctl1. + Note that everything that is written to syslog or kmsg (see + below) is implicitly stored in the journal as well, the + specific two options listed below are hence supersets of this + one. + + connects standard output to the + syslog3 + system syslog service, in addition to the journal. Note that + the journal daemon is usually configured to forward everything + it receives to syslog anyway, in which case this option is no + different from . + + connects standard output with the + kernel log buffer which is accessible via + dmesg1, + in addition to the journal. The journal daemon might be + configured to send all logs to kmsg anyway, in which case this + option is no different from . + + , + and + work in a similar way as the + three options above but copy the output to the system console + as well. + + connects standard output to a + socket acquired via socket activation. The semantics are + similar to the same option of + StandardInput=. + + This setting defaults to the value set with + in + systemd-system.conf5, + which defaults to . + + + StandardError= + Controls where file descriptor 2 (STDERR) of + the executed processes is connected to. The available options + are identical to those of StandardOutput=, + with one exception: if set to the + file descriptor used for standard output is duplicated for + standard error. This setting defaults to the value set with + in + systemd-system.conf5, + which defaults to . + + + TTYPath= + Sets the terminal device node to use if + standard input, output, or error are connected to a TTY (see + above). Defaults to + /dev/console. + + + TTYReset= + Reset the terminal device specified with + TTYPath= before and after execution. + Defaults to no. + + + TTYVHangup= + Disconnect all clients which have opened the + terminal device specified with TTYPath= + before and after execution. Defaults to + no. + + + TTYVTDisallocate= + If the terminal device specified with + TTYPath= is a virtual console terminal, try + to deallocate the TTY before and after execution. This ensures + that the screen and scrollback buffer is cleared. Defaults to + no. + + + SyslogIdentifier= + Sets the process name to prefix log lines sent + to the logging system or the kernel log buffer with. If not + set, defaults to the process name of the executed process. + This option is only useful when + StandardOutput= or + StandardError= are set to + , or + (or to the same settings in combination + with ). + + + SyslogFacility= + Sets the syslog facility to use when logging + to syslog. One of , + , , + , , + , , + , , + , , + , , + , , + , , + , or + . See + syslog3 + for details. This option is only useful when + StandardOutput= or + StandardError= are set to + . Defaults to + . + + + SyslogLevel= + Default syslog level to use when logging to + syslog or the kernel log buffer. One of + , + , + , + , + , + , + , + . See + syslog3 + for details. This option is only useful when + StandardOutput= or + StandardError= are set to + or . Note that + individual lines output by the daemon might be prefixed with a + different log level which can be used to override the default + log level specified here. The interpretation of these prefixes + may be disabled with SyslogLevelPrefix=, + see below. For details see + sd-daemon3. + + Defaults to + . + + + + SyslogLevelPrefix= + Takes a boolean argument. If true and + StandardOutput= or + StandardError= are set to + , or + , log lines written by the executed + process that are prefixed with a log level will be passed on + to syslog with this log level set but the prefix removed. If + set to false, the interpretation of these prefixes is disabled + and the logged lines are passed on as-is. For details about + this prefixing see + sd-daemon3. + Defaults to true. + + + + TimerSlackNSec= + Sets the timer slack in nanoseconds for the + executed processes. The timer slack controls the accuracy of + wake-ups triggered by timers. See + prctl2 + for more information. Note that in contrast to most other time + span definitions this parameter takes an integer value in + nano-seconds if no unit is specified. The usual time units are + understood too. + + + + LimitCPU= + LimitFSIZE= + LimitDATA= + LimitSTACK= + LimitCORE= + LimitRSS= + LimitNOFILE= + LimitAS= + LimitNPROC= + LimitMEMLOCK= + LimitLOCKS= + LimitSIGPENDING= + LimitMSGQUEUE= + LimitNICE= + LimitRTPRIO= + LimitRTTIME= + These settings set both soft and hard limits + of various resources for executed processes. See + setrlimit2 + for details. Use the string infinity to + configure no limit on a specific resource. + + + Limit directives and their equivalent with ulimit + + + + + + + Directive + ulimit equivalent + + + + + LimitCPU + ulimit -t + + + LimitFSIZE + ulimit -f + + + LimitDATA + ulimit -d + + + LimitSTACK + ulimit -s + + + LimitCORE + ulimit -c + + + LimitRSS + ulimit -m + + + LimitNOFILE + ulimit -n + + + LimitAS + ulimit -v + + + LimitNPROC + ulimit -u + + + LimitMEMLOCK + ulimit -l + + + LimitLOCKS + ulimit -x + + + LimitSIGPENDING + ulimit -i + + + LimitMSGQUEUE + ulimit -q + + + LimitNICE + ulimit -e + + + LimitRTPRIO + ulimit -r + + + LimitRTTIME + No equivalent + + + +
+ + + + PAMName= + Sets the PAM service name to set up a session + as. If set, the executed process will be registered as a PAM + session under the specified service name. This is only useful + in conjunction with the User= setting. If + not set, no PAM session will be opened for the executed + processes. See + pam8 + for details. + + + + CapabilityBoundingSet= + + Controls which capabilities to include in the + capability bounding set for the executed process. See + capabilities7 + for details. Takes a whitespace-separated list of capability + names as read by + cap_from_name3, + e.g. CAP_SYS_ADMIN, + CAP_DAC_OVERRIDE, + CAP_SYS_PTRACE. Capabilities listed will + be included in the bounding set, all others are removed. If + the list of capabilities is prefixed with + ~, all but the listed capabilities will be + included, the effect of the assignment inverted. Note that + this option also affects the respective capabilities in the + effective, permitted and inheritable capability sets, on top + of what Capabilities= does. If this option + is not used, the capability bounding set is not modified on + process execution, hence no limits on the capabilities of the + process are enforced. This option may appear more than once in + which case the bounding sets are merged. If the empty string + is assigned to this option, the bounding set is reset to the + empty capability set, and all prior settings have no effect. + If set to ~ (without any further argument), + the bounding set is reset to the full set of available + capabilities, also undoing any previous + settings. + + + + SecureBits= + Controls the secure bits set for the executed + process. Takes a space-separated combination of options from + the following list: + , + , + , + , + , and + . + This option may appear more than once in which case the secure + bits are ORed. If the empty string is assigned to this option, + the bits are reset to 0. See + capabilities7 + for details. + + + + Capabilities= + Controls the + capabilities7 + set for the executed process. Take a capability string + describing the effective, permitted and inherited capability + sets as documented in + cap_from_text3. + Note that these capability sets are usually influenced (and + filtered) by the capabilities attached to the executed file. + Due to that CapabilityBoundingSet= is + probably a much more useful setting. + + + + ReadWriteDirectories= + ReadOnlyDirectories= + InaccessibleDirectories= + + Sets up a new file system namespace for + executed processes. These options may be used to limit access + a process might have to the main file system hierarchy. Each + setting takes a space-separated list of absolute directory + paths. Directories listed in + ReadWriteDirectories= are accessible from + within the namespace with the same access rights as from + outside. Directories listed in + ReadOnlyDirectories= are accessible for + reading only, writing will be refused even if the usual file + access controls would permit this. Directories listed in + InaccessibleDirectories= will be made + inaccessible for processes inside the namespace. Note that + restricting access with these options does not extend to + submounts of a directory that are created later on. These + options may be specified more than once in which case all + directories listed will have limited access from within the + namespace. If the empty string is assigned to this option, the + specific list is reset, and all prior assignments have no + effect. + Paths in + ReadOnlyDirectories= + and + InaccessibleDirectories= + may be prefixed with + -, in which case + they will be ignored when they do not + exist. Note that using this + setting will disconnect propagation of + mounts from the service to the host + (propagation in the opposite direction + continues to work). This means that + this setting may not be used for + services which shall be able to + install mount points in the main mount + namespace. + + + + PrivateTmp= + + Takes a boolean argument. If true, sets up a + new file system namespace for the executed processes and + mounts private /tmp and + /var/tmp directories inside it that is + not shared by processes outside of the namespace. This is + useful to secure access to temporary files of the process, but + makes sharing between processes via /tmp + or /var/tmp impossible. If this is + enabled, all temporary files created by a service in these + directories will be removed after the service is stopped. + Defaults to false. It is possible to run two or more units + within the same private /tmp and + /var/tmp namespace by using the + JoinsNamespaceOf= directive, see + systemd.unit5 + for details. Note that using this setting will disconnect + propagation of mounts from the service to the host + (propagation in the opposite direction continues to work). + This means that this setting may not be used for services + which shall be able to install mount points in the main mount + namespace. + + + + PrivateDevices= + + Takes a boolean argument. If true, sets up a + new /dev namespace for the executed processes and only adds + API pseudo devices such as /dev/null, + /dev/zero or + /dev/random (as well as the pseudo TTY + subsystem) to it, but no physical devices such as + /dev/sda. This is useful to securely turn + off physical device access by the executed process. Defaults + to false. Enabling this option will also remove + CAP_MKNOD from the capability bounding + set for the unit (see above), and set + DevicePolicy=closed (see + systemd.resource-control5 + for details). Note that using this setting will disconnect + propagation of mounts from the service to the host + (propagation in the opposite direction continues to work). + This means that this setting may not be used for services + which shall be able to install mount points in the main mount + namespace. + + + + PrivateNetwork= + + Takes a boolean argument. If true, sets up a + new network namespace for the executed processes and + configures only the loopback network device + lo inside it. No other network devices will + be available to the executed process. This is useful to + securely turn off network access by the executed process. + Defaults to false. It is possible to run two or more units + within the same private network namespace by using the + JoinsNamespaceOf= directive, see + systemd.unit5 + for details. Note that this option will disconnect all socket + families from the host, this includes AF_NETLINK and AF_UNIX. + The latter has the effect that AF_UNIX sockets in the abstract + socket namespace will become unavailable to the processes + (however, those located in the file system will continue to be + accessible). + + + + ProtectSystem= + + Takes a boolean argument or + full. If true, mounts the + /usr and /boot + directories read-only for processes invoked by this unit. If + set to full, the /etc + directory is mounted read-only, too. This setting ensures that + any modification of the vendor supplied operating system (and + optionally its configuration) is prohibited for the service. + It is recommended to enable this setting for all long-running + services, unless they are involved with system updates or need + to modify the operating system in other ways. Note however + that processes retaining the CAP_SYS_ADMIN capability can undo + the effect of this setting. This setting is hence particularly + useful for daemons which have this capability removed, for + example with CapabilityBoundingSet=. + Defaults to off. + + + + ProtectHome= + + Takes a boolean argument or + read-only. If true, the directories + /home and /run/user + are made inaccessible and empty for processes invoked by this + unit. If set to read-only, the two + directories are made read-only instead. It is recommended to + enable this setting for all long-running services (in + particular network-facing ones), to ensure they cannot get + access to private user data, unless the services actually + require access to the user's private data. Note however that + processes retaining the CAP_SYS_ADMIN capability can undo the + effect of this setting. This setting is hence particularly + useful for daemons which have this capability removed, for + example with CapabilityBoundingSet=. + Defaults to off. + + + + MountFlags= + + Takes a mount propagation flag: + , or + , which control whether mounts in the + file system namespace set up for this unit's processes will + receive or propagate mounts or unmounts. See + mount2 + for details. Defaults to . Use + to ensure that mounts and unmounts are + propagated from the host to the container and vice versa. Use + to run processes so that none of their + mounts and unmounts will propagate to the host. Use + to also ensure that no mounts and + unmounts from the host will propagate into the unit processes' + namespace. Note that means that file + systems mounted on the host might stay mounted continuously in + the unit's namespace, and thus keep the device busy. Note that + the file system namespace related options + (PrivateTmp=, + PrivateDevices=, + ProtectSystem=, + ProtectHome=, + ReadOnlyDirectories=, + InaccessibleDirectories= and + ReadWriteDirectories=) require that mount + and unmount propagation from the unit's file system namespace + is disabled, and hence downgrade to + . + + + + UtmpIdentifier= + + Takes a four character identifier string for + an utmp/wtmp entry for this service. This should only be set + for services such as getty implementations + where utmp/wtmp entries must be created and cleared before and + after execution. If the configured string is longer than four + characters, it is truncated and the terminal four characters + are used. This setting interprets %I style string + replacements. This setting is unset by default, i.e. no + utmp/wtmp entries are created or cleaned up for this + service. + + + + SELinuxContext= + + Set the SELinux security context of the + executed process. If set, this will override the automated + domain transition. However, the policy still needs to + authorize the transition. This directive is ignored if SELinux + is disabled. If prefixed by -, all errors + will be ignored. See + setexeccon3 + for details. + + + + AppArmorProfile= + + Takes a profile name as argument. The process + executed by the unit will switch to this profile when started. + Profiles must already be loaded in the kernel, or the unit + will fail. This result in a non operation if AppArmor is not + enabled. If prefixed by -, all errors will + be ignored. + + + + SmackProcessLabel= + + Takes a security + label as argument. The process executed by the unit will be + started under this label and SMACK will decide whether the + processes is allowed to run or not based on it. The process + will continue to run under the label specified here unless the + executable has its own label, in + which case the process will transition to run under that + label. When not specified, the label that systemd is running + under is used. This directive is ignored if SMACK is + disabled. + + The value may be prefixed by -, in + which case all errors will be ignored. An empty value may be + specified to unset previous assignments. + + + + + IgnoreSIGPIPE= + + Takes a boolean argument. If true, causes + SIGPIPE to be ignored in the executed + process. Defaults to true because SIGPIPE + generally is useful only in shell pipelines. + + + + NoNewPrivileges= + + Takes a boolean argument. If true, ensures + that the service process and all its children can never gain + new privileges. This option is more powerful than the + respective secure bits flags (see above), as it also prohibits + UID changes of any kind. This is the simplest, most effective + way to ensure that a process and its children can never + elevate privileges again. + + + + SystemCallFilter= + + Takes a space-separated list of system call + names. If this setting is used, all system calls executed by + the unit processes except for the listed ones will result in + immediate process termination with the + SIGSYS signal (whitelisting). If the + first character of the list is ~, the + effect is inverted: only the listed system calls will result + in immediate process termination (blacklisting). If running in + user mode and this option is used, + NoNewPrivileges=yes is implied. This + feature makes use of the Secure Computing Mode 2 interfaces of + the kernel ('seccomp filtering') and is useful for enforcing a + minimal sandboxing environment. Note that the + execve, + rt_sigreturn, + sigreturn, + exit_group, exit + system calls are implicitly whitelisted and do not need to be + listed explicitly. This option may be specified more than once + in which case the filter masks are merged. If the empty string + is assigned, the filter is reset, all prior assignments will + have no effect. + + If you specify both types of this option (i.e. + whitelisting and blacklisting), the first encountered will + take precedence and will dictate the default action + (termination or approval of a system call). Then the next + occurrences of this option will add or delete the listed + system calls from the set of the filtered system calls, + depending of its type and the default action. (For example, if + you have started with a whitelisting of + read and write, and + right after it add a blacklisting of + write, then write + will be removed from the set.) + + + + SystemCallErrorNumber= + + Takes an errno error number + name to return when the system call filter configured with + SystemCallFilter= is triggered, instead of + terminating the process immediately. Takes an error name such + as EPERM, EACCES or + EUCLEAN. When this setting is not used, + or when the empty string is assigned, the process will be + terminated immediately when the filter is + triggered. + + + + SystemCallArchitectures= + + Takes a space separated list of architecture + identifiers to include in the system call filter. The known + architecture identifiers are x86, + x86-64, x32, + arm as well as the special identifier + native. Only system calls of the + specified architectures will be permitted to processes of this + unit. This is an effective way to disable compatibility with + non-native architectures for processes, for example to + prohibit execution of 32-bit x86 binaries on 64-bit x86-64 + systems. The special native identifier + implicitly maps to the native architecture of the system (or + more strictly: to the architecture the system manager is + compiled for). If running in user mode and this option is + used, NoNewPrivileges=yes is implied. Note + that setting this option to a non-empty list implies that + native is included too. By default, this + option is set to the empty list, i.e. no architecture system + call filtering is applied. + + + + RestrictAddressFamilies= + + Restricts the set of socket address families + accessible to the processes of this unit. Takes a + space-separated list of address family names to whitelist, + such as + AF_UNIX, + AF_INET or + AF_INET6. When + prefixed with ~ the listed address + families will be applied as blacklist, otherwise as whitelist. + Note that this restricts access to the + socket2 + system call only. Sockets passed into the process by other + means (for example, by using socket activation with socket + units, see + systemd.socket5) + are unaffected. Also, sockets created with + socketpair() (which creates connected + AF_UNIX sockets only) are unaffected. Note that this option + has no effect on 32-bit x86 and is ignored (but works + correctly on x86-64). If running in user mode and this option + is used, NoNewPrivileges=yes is implied. By + default, no restriction applies, all address families are + accessible to processes. If assigned the empty string, any + previous list changes are undone. + + Use this option to limit exposure of processes to remote + systems, in particular via exotic network protocols. Note that + in most cases, the local AF_UNIX address + family should be included in the configured whitelist as it is + frequently used for local communication, including for + syslog2 + logging. + + + + Personality= + + Controls which kernel architecture + uname2 + shall report, when invoked by unit processes. Takes one of + x86 and x86-64. This + is useful when running 32-bit services on a 64-bit host + system. If not specified, the personality is left unmodified + and thus reflects the personality of the host system's + kernel. + + + + RuntimeDirectory= + RuntimeDirectoryMode= + + Takes a list of directory names. If set, one + or more directories by the specified names will be created + below /run (for system services) or below + $XDG_RUNTIME_DIR (for user services) when + the unit is started, and removed when the unit is stopped. The + directories will have the access mode specified in + RuntimeDirectoryMode=, and will be owned by + the user and group specified in User= and + Group=. Use this to manage one or more + runtime directories of the unit and bind their lifetime to the + daemon runtime. The specified directory names must be + relative, and may not include a /, i.e. + must refer to simple directories to create or remove. This is + particularly useful for unprivileged daemons that cannot + create runtime directories in /run due to + lack of privileges, and to make sure the runtime directory is + cleaned up automatically after use. For runtime directories + that require more complex or different configuration or + lifetime guarantees, please consider using + tmpfiles.d5. + + + + + + + Environment variables in spawned processes + + Processes started by the system are executed in a clean + environment in which select variables listed below are set. System + processes started by systemd do not inherit variables from PID 1, + but processes started by user systemd instances inherit all + environment variables from the user systemd instance. + + + + + $PATH + + Colon-separated list of directories to use + when launching executables. Systemd uses a fixed value of + /usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin. + + + + + $LANG + + Locale. Can be set in + locale.conf5 + or on the kernel command line (see + systemd1 + and + kernel-command-line7). + + + + + $USER + $LOGNAME + $HOME + $SHELL + + User name (twice), home directory, and the + login shell. The variables are set for the units that have + User= set, which includes user + systemd instances. See + passwd5. + + + + + $XDG_RUNTIME_DIR + + The directory for volatile state. Set for the + user systemd instance, and also in user + sessions. See + pam_systemd8. + + + + + $XDG_SESSION_ID + $XDG_SEAT + $XDG_VTNR + + The identifier of the session, the seat name, + and virtual terminal of the session. Set by + pam_systemd8 + for login sessions. $XDG_SEAT and + $XDG_VTNR will only be set when attached to + a seat and a tty. + + + + $MAINPID + + The PID of the units main process if it is + known. This is only set for control processes as invoked by + ExecReload= and similar. + + + + $MANAGERPID + + The PID of the user systemd + instance, set for processes spawned by it. + + + + $LISTEN_FDS + $LISTEN_PID + + Information about file descriptors passed to a + service for socket activation. See + sd_listen_fds3. + + + + + $TERM + + Terminal type, set only for units connected to + a terminal (StandardInput=tty, + StandardOutput=tty, or + StandardError=tty). See + termcap5. + + + + + Additional variables may be configured by the following + means: for processes spawned in specific units, use the + Environment= and + EnvironmentFile= options above; to specify + variables globally, use DefaultEnvironment= + (see + systemd-system.conf5) + or the kernel option systemd.setenv= (see + systemd1). + Additional variables may also be set through PAM, + cf. pam_env8. + + + + See Also + + systemd1, + systemctl1, + journalctl8, + systemd.unit5, + systemd.service5, + systemd.socket5, + systemd.swap5, + systemd.mount5, + systemd.kill5, + systemd.resource-control5, + systemd.directives7, + tmpfiles.d5, + exec3 + + diff --git a/man/systemd.journal-fields.xml b/man/systemd.journal-fields.xml index 154b95ac7e2..1fd46de31f1 100644 --- a/man/systemd.journal-fields.xml +++ b/man/systemd.journal-fields.xml @@ -1,6 +1,6 @@ + "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd"> + "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd"> - - systemd.kill - systemd - - - - Developer - Lennart - Poettering - lennart@poettering.net - - - - - - systemd.kill - 5 - - - - systemd.kill - Process killing procedure - configuration - - - - service.service, - socket.socket, - mount.mount, - swap.swap, - scope.scope - - - - Description - - Unit configuration files for services, sockets, - mount points, swap devices and scopes share a subset - of configuration options which define the - killing procedure of processes belonging to the unit. - - This man page lists the configuration options - shared by these five unit types. See - systemd.unit5 - for the common options shared by all unit - configuration files, and - systemd.service5, - systemd.socket5, - systemd.swap5, - systemd.mount5 - and - systemd.scope5 - for more information on the configuration file options - specific to each unit type. - - The kill procedure - configuration options are configured in the [Service], - [Socket], [Mount] or [Swap] section, depending on the - unit type. - - - - Options - - - - - KillMode= - Specifies how - processes of this unit shall be - killed. One of - , - , - , - . - - If set to - , all - remaining processes in the control - group of this unit will be killed on - unit stop (for services: after the - stop command is executed, as - configured with - ExecStop=). If set - to , only the - main process itself is killed. If set - to , the - SIGTERM signal - (see below) is sent to the main - process while the subsequent - SIGKILL signal - (see below) is sent to all remaining - processes of the unit's control - group. If set to - , no process is - killed. In this case, only the stop - command will be executed on unit stop, - but no process be killed - otherwise. Processes remaining alive - after stop are left in their control - group and the control group continues - to exist after stop unless it is - empty. - - Processes will first be - terminated via - SIGTERM (unless - the signal to send is changed via - KillSignal=). Optionally, - this is immediately followed by a - SIGHUP (if - enabled with - SendSIGHUP=). If - then, after a delay (configured via the - TimeoutStopSec= option), - processes still remain, the - termination request is repeated with - the SIGKILL - signal (unless this is disabled via - the SendSIGKILL= - option). See - kill2 - for more - information. - - Defaults to - . - - - - KillSignal= - Specifies which signal - to use when killing a service. This - controls the signal that is sent as - first step of shutting down a unit - (see above), and is usually followed - by SIGKILL (see - above and below). For a list of valid - signals, see - signal7. Defaults - to SIGTERM. - - - - - SendSIGHUP= - Specifies whether to - send SIGHUP to - remaining processes immediately after - sending the signal configured with - KillSignal=. This - is useful to indicate to shells and - shell-like programs that their - connection has been severed. Takes a - boolean value. Defaults to "no". - - - - - SendSIGKILL= - Specifies whether to - send SIGKILL to remaining processes - after a timeout, if the normal - shutdown procedure left processes of - the service around. Takes a boolean - value. Defaults to "yes". - - - - - - - - See Also - - systemd1, - systemctl1, - journalctl8, - systemd.unit5, - systemd.service5, - systemd.socket5, - systemd.swap5, - systemd.mount5, - systemd.exec5, - systemd.directives7, - kill2, - signal7 - - + + systemd.kill + systemd + + + + Developer + Lennart + Poettering + lennart@poettering.net + + + + + + systemd.kill + 5 + + + + systemd.kill + Process killing procedure + configuration + + + + service.service, + socket.socket, + mount.mount, + swap.swap, + scope.scope + + + + Description + + Unit configuration files for services, sockets, mount + points, swap devices and scopes share a subset of configuration + options which define the killing procedure of processes belonging + to the unit. + + This man page lists the configuration options shared by + these five unit types. See + systemd.unit5 + for the common options shared by all unit configuration files, and + systemd.service5, + systemd.socket5, + systemd.swap5, + systemd.mount5 + and + systemd.scope5 + for more information on the configuration file options specific to + each unit type. + + The kill procedure configuration options are configured in + the [Service], [Socket], [Mount] or [Swap] section, depending on + the unit type. + + + + Options + + + + + KillMode= + Specifies how processes of this unit shall be + killed. One of + , + , + , + . + + If set to , all remaining + processes in the control group of this unit will be killed on + unit stop (for services: after the stop command is executed, + as configured with ExecStop=). If set to + , only the main process itself is + killed. If set to , the + SIGTERM signal (see below) is sent to the + main process while the subsequent SIGKILL + signal (see below) is sent to all remaining processes of the + unit's control group. If set to , no + process is killed. In this case, only the stop command will be + executed on unit stop, but no process be killed otherwise. + Processes remaining alive after stop are left in their control + group and the control group continues to exist after stop + unless it is empty. + + Processes will first be terminated via + SIGTERM (unless the signal to send is + changed via KillSignal=). Optionally, this + is immediately followed by a SIGHUP (if + enabled with SendSIGHUP=). If then, after a + delay (configured via the TimeoutStopSec= + option), processes still remain, the termination request is + repeated with the SIGKILL signal (unless + this is disabled via the SendSIGKILL= + option). See + kill2 + for more information. + + Defaults to + . + + + + KillSignal= + Specifies which signal to use when killing a + service. This controls the signal that is sent as first step + of shutting down a unit (see above), and is usually followed + by SIGKILL (see above and below). For a + list of valid signals, see + signal7. + Defaults to SIGTERM. + + + + SendSIGHUP= + Specifies whether to send + SIGHUP to remaining processes immediately + after sending the signal configured with + KillSignal=. This is useful to indicate to + shells and shell-like programs that their connection has been + severed. Takes a boolean value. Defaults to "no". + + + + + SendSIGKILL= + Specifies whether to send + SIGKILL to remaining processes after a + timeout, if the normal shutdown procedure left processes of + the service around. Takes a boolean value. Defaults to "yes". + + + + + + + + See Also + + systemd1, + systemctl1, + journalctl8, + systemd.unit5, + systemd.service5, + systemd.socket5, + systemd.swap5, + systemd.mount5, + systemd.exec5, + systemd.directives7, + kill2, + signal7 + + diff --git a/man/systemd.link.xml b/man/systemd.link.xml index ecf7954d1b3..2cfe7107f88 100644 --- a/man/systemd.link.xml +++ b/man/systemd.link.xml @@ -1,7 +1,7 @@ + "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd"> - - systemd.link - systemd + + systemd.link + systemd - - - Developer - Tom - Gundersen - - - + + + Developer + Tom + Gundersen + + + - - systemd.link - 5 - + + systemd.link + 5 + - - systemd.link - Network device configuration - + + systemd.link + Network device configuration + - - link.link - + + link.link + - - Description + + Description - Network link configuration is performed by the net_setup_link - udev builtin. + Network link configuration is performed by the + net_setup_link udev builtin. - The link files are read from the files located in the - system network directory /usr/lib/systemd/network, - the volatile runtime network directory /run/systemd/network, - and the local administration network directory /etc/systemd/network. - Link files must have the extension .link; other extensions are ignored. - All link files are collectively sorted and processed in lexical order, - regardless of the directories in which they live. However, files with - identical filenames replace each other. Files in /etc - have the highest priority, files in /run take precedence - over files with the same name in /usr/lib. This can be - used to override a system-supplied link file with a local file if needed; - a symlink in /etc with the same name as a link file in - /usr/lib, pointing to /dev/null, - disables the link file entirely. + The link files are read from the files located in the system + network directory /usr/lib/systemd/network, + the volatile runtime network directory + /run/systemd/network, and the local + administration network directory + /etc/systemd/network. Link files must have + the extension .link; other extensions are + ignored. All link files are collectively sorted and processed in + lexical order, regardless of the directories in which they live. + However, files with identical filenames replace each other. Files + in /etc have the highest priority, files in + /run take precedence over files with the same + name in /usr/lib. This can be used to + override a system-supplied link file with a local file if needed; + a symlink in /etc with the same name as a + link file in /usr/lib, pointing to + /dev/null, disables the link file + entirely. - The link file contains a - [Match] section, which determines - if a given link file may be applied to a given device, - as well as a [Link] section specifying how - the device should be configured. The first (in lexical - order) of the link files that matches a given device - is applied. Note that a default file - 99-default.link is shipped by the - system, any user-supplied .link - should hence have a lexically earlier name to be - considered at all. - + The link file contains a [Match] section, + which determines if a given link file may be applied to a given + device, as well as a [Link] section specifying + how the device should be configured. The first (in lexical order) + of the link files that matches a given device is applied. Note + that a default file 99-default.link is + shipped by the system, any user-supplied + .link should hence have a lexically earlier + name to be considered at all. + - - [Match] Section Options + + [Match] Section Options - A link file is said to match a device if each of the entries in the - [Match] section matches, or if the section is empty. - The following keys are accepted: + A link file is said to match a device if each of the entries + in the [Match] section matches, or if the + section is empty. The following keys are accepted: - - - MACAddress= - - The hardware address. - - - - OriginalName= - - The device name, as exposed by the udev - property "INTERFACE". May contain shell style - globs. This can not be used to match on names - that have already been changed from userspace. - Caution is advised when matching on - kernel-assigned names, as they are known to - be unstable between reboots. - - - - Path= - - The persistent path, as exposed by the - udev property ID_PATH. May - contain shell style globs. - - - - Driver= - - The driver currently bound to the device, - as exposed by the udev property DRIVER - of its parent device, or if that is not set, the - driver as exposed by ethtool -i - of the device itself. - - - - Type= - - The device type, as exposed by the udev - property DEVTYPE. - - - - Host= - - Matches against the hostname or machine - ID of the host. See ConditionHost= in - systemd.unit5 - for details. - - - - Virtualization= - - Checks whether the system is executed in - a virtualized environment and optionally test - whether it is a specific implementation. See - ConditionVirtualization= in - systemd.unit5 - for details. - - - - KernelCommandLine= - - Checks whether a specific kernel command - line option is set (or if prefixed with the - exclamation mark unset). See - ConditionKernelCommandLine= in - systemd.unit5 - for details. - - - - Architecture= - - Checks whether the system is running on a - specific architecture. See - ConditionArchitecture= in - systemd.unit5 - for details. - - - + + + MACAddress= + + The hardware address. + + + + OriginalName= + + The device name, as exposed by the udev property + "INTERFACE". May contain shell style globs. This can not be + used to match on names that have already been changed from + userspace. Caution is advised when matching on + kernel-assigned names, as they are known to be unstable + between reboots. + + + + Path= + + The persistent path, as exposed by the + udev property ID_PATH. May + contain shell style globs. + + + + Driver= + + The driver currently bound to the device, + as exposed by the udev property DRIVER + of its parent device, or if that is not set, the + driver as exposed by ethtool -i + of the device itself. + + + + Type= + + The device type, as exposed by the udev + property DEVTYPE. + + + + Host= + + Matches against the hostname or machine + ID of the host. See ConditionHost= in + systemd.unit5 + for details. + + + + Virtualization= + + Checks whether the system is executed in + a virtualized environment and optionally test + whether it is a specific implementation. See + ConditionVirtualization= in + systemd.unit5 + for details. + + + + KernelCommandLine= + + Checks whether a specific kernel command line option + is set (or if prefixed with the exclamation mark unset). See + ConditionKernelCommandLine= in + systemd.unit5 + for details. + + + + Architecture= + + Checks whether the system is running on a specific + architecture. See ConditionArchitecture= + in + systemd.unit5 + for details. + + + - + - - [Link] Section Options + + [Link] Section Options - The [Link] section accepts the following - keys: + The [Link] section accepts the following + keys: - - - Description= - - A description of the device. - - - - Alias= - - The ifalias is set to - this value. - - - - MACAddressPolicy= - - The policy by which the MAC address - should be set. The available policies are: - + + + Description= + + A description of the device. + + + + Alias= + + The ifalias is set to this + value. + + + + MACAddressPolicy= + + The policy by which the MAC address should be set. The + available policies are: + - - - persistent - - If the hardware has a persistent - MAC address, as most hardware should, - and if it is used by the kernel, nothing - is done. Otherwise, a new MAC address - is generated which is guaranteed to be - the same on every boot for the given - machine and the given device, but which - is otherwise random. - - - - random - - If the kernel is using a random MAC - address, nothing is done. Otherwise, a new - address is randomly generated each time the - device appears, typically at boot. - - - - - - - MACAddress= - - The MAC address to use, if no - MACAddressPolicy= - is specified. - - - - NamePolicy= - - An ordered, space-separated list of - policies by which the interface name should - be set. NamePolicy may be - disabled by specifying - net.ifnames=0 on the kernel - command line. Each of the policies may fail, and - the first successful one is used. The name is - not set directly, but is exported to udev as - the property ID_NET_NAME, - which is, by default, used by a udev rule to set - NAME. If the name has already - been set by userspace, no renaming is performed. - The available policies are: + + + persistent + + If the hardware has a persistent MAC address, as + most hardware should, and if it is used by the kernel, + nothing is done. Otherwise, a new MAC address is + generated which is guaranteed to be the same on every + boot for the given machine and the given device, but + which is otherwise random. + + + + random + + If the kernel is using a random MAC address, + nothing is done. Otherwise, a new address is randomly + generated each time the device appears, typically at + boot. + + + + + + + MACAddress= + + The MAC address to use, if no + MACAddressPolicy= + is specified. + + + + NamePolicy= + + An ordered, space-separated list of policies by which + the interface name should be set. + NamePolicy may be disabled by specifying + net.ifnames=0 on the kernel command line. + Each of the policies may fail, and the first successful one + is used. The name is not set directly, but is exported to + udev as the property ID_NET_NAME, which + is, by default, used by a udev rule to set + NAME. If the name has already been set by + userspace, no renaming is performed. The available policies + are: - - - kernel - - If the kernel claims that the name it - has set for a device is predictable, then - no renaming is performed. - - - - - database - - The name is set based on entries in - the udev's Hardware Database with the key - ID_NET_NAME_FROM_DATABASE. - - - - - onboard - - The name is set based on information given by - the firmware for on-board devices, as exported by - the udev property ID_NET_NAME_ONBOARD. - - - - - slot - - The name is set based on information given by - the firmware for hot-plug devices, as exported by - the udev property ID_NET_NAME_SLOT. - - - - - path - - The name is set based on the device's physical - location, as exported by the udev property - ID_NET_NAME_PATH. - - - - mac - - The name is set based on the device's - persistent MAC address, as exported by the udev - property ID_NET_NAME_MAC. - - - - - - - Name= - - The interface name to use in case all the - policies specified in - NamePolicy= fail, or in case - NamePolicy= is missing or - disabled. - - - - MTUBytes= - - The maximum transmission unit in bytes to - set for the device. The usual suffixes K, M, G, - are supported and are understood to the base of - 1024. - - - - BitsPerSecond= - - The speed to set for the device, the - value is rounded down to the nearest Mbps. - The usual suffixes K, M, G, are supported and - are understood to the base of 1000. - - - - Duplex= - - The duplex mode to set for the device. - The accepted values are half - and full. - - - - WakeOnLan= - - The Wake-on-LAN policy to set for the - device. The supported values are: + + + kernel + + If the kernel claims that the name it has set + for a device is predictable, then no renaming is + performed. + + + + database + + The name is set based on entries in the udev's + Hardware Database with the key + ID_NET_NAME_FROM_DATABASE. + + + + + onboard + + The name is set based on information given by + the firmware for on-board devices, as exported by the + udev property ID_NET_NAME_ONBOARD. + + + + + slot + + The name is set based on information given by + the firmware for hot-plug devices, as exported by the + udev property ID_NET_NAME_SLOT. + + + + + path + + The name is set based on the device's physical + location, as exported by the udev property + ID_NET_NAME_PATH. + + + + mac + + The name is set based on the device's persistent + MAC address, as exported by the udev property + ID_NET_NAME_MAC. + + + + + + + Name= + + The interface name to use in case all the + policies specified in + NamePolicy= fail, or in case + NamePolicy= is missing or + disabled. + + + + MTUBytes= + + The maximum transmission unit in bytes to set for the + device. The usual suffixes K, M, G, are supported and are + understood to the base of 1024. + + + + BitsPerSecond= + + The speed to set for the device, the value is rounded + down to the nearest Mbps. The usual suffixes K, M, G, are + supported and are understood to the base of 1000. + + + + Duplex= + + The duplex mode to set for the device. The accepted + values are half and + full. + + + + WakeOnLan= + + The Wake-on-LAN policy to set for the device. The + supported values are: - - - phy - - Wake on PHY activity. - - - - magic - - Wake on receipt of a magic packet. - - - - - off - - Never wake. - - - - - - - + + + phy + + Wake on PHY activity. + + + + magic + + Wake on receipt of a magic packet. + + + + + off + + Never wake. + + + + + + + - - Example - - /etc/systemd/network/wireless.link + + Example + + /etc/systemd/network/wireless.link - [Match] + [Match] MACAddress=12:34:56:78:9a:bc Driver=brcmsmac Path=pci-0000:02:00.0-* @@ -402,25 +395,25 @@ MTUBytes=1450 BitsPerSecond=10M WakeOnLan=magic MACAddress=cb:a9:87:65:43:21 - - + + - - See Also - - - systemd-udevd.service8 - , - - udevadm8 - , - - systemd.netdev5 - , - - systemd.network5 - - - + + See Also + + + systemd-udevd.service8 + , + + udevadm8 + , + + systemd.netdev5 + , + + systemd.network5 + + + diff --git a/man/systemd.mount.xml b/man/systemd.mount.xml index 8527386594f..bef66a3c0b4 100644 --- a/man/systemd.mount.xml +++ b/man/systemd.mount.xml @@ -1,7 +1,7 @@ + "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd"> - - systemd.mount - systemd - - - - Developer - Lennart - Poettering - lennart@poettering.net - - - - - - systemd.mount - 5 - - - - systemd.mount - Mount unit configuration - - - - mount.mount - - - - Description - - A unit configuration file whose name ends in - .mount encodes information about - a file system mount point controlled and supervised by - systemd. - - This man page lists the configuration options - specific to this unit type. See - systemd.unit5 - for the common options of all unit configuration - files. The common configuration items are configured - in the generic [Unit] and [Install] sections. The - mount specific configuration options are configured - in the [Mount] section. - - Additional options are listed in - systemd.exec5, - which define the execution environment the - mount8 - binary is executed in, and in - systemd.kill5, - which define the way the processes are terminated, and - in - systemd.resource-control5, - which configure resource control settings for the - processes of the service. Note that the User= and - Group= options are not particularly useful for mount - units specifying a Type= option or - using configuration not specified in - /etc/fstab; - mount8 - will refuse options that are not listed in - /etc/fstab if it is not run as - UID 0. - - Mount units must be named after the mount point - directories they control. Example: the mount point - /home/lennart must be configured - in a unit file - home-lennart.mount. For details - about the escaping logic used to convert a file system - path to a unit name, see - systemd.unit5. - - Optionally, a mount unit may be accompanied by - an automount unit, to allow on-demand or parallelized - mounting. See - systemd.automount5. - - If a mount point is beneath another mount point - in the file system hierarchy, a dependency between both - units is created automatically. - - Mount points created at runtime (independently of - unit files or /etc/fstab) will be - monitored by systemd and appear like any other mount - unit in systemd. - See /proc/self/mountinfo description - in proc5. - - - Some file systems have special semantics as API - file systems for kernel-to-userspace and - userspace-to-userpace interfaces. Some of them may not - be changed via mount units, and cannot be disabled. - For a longer discussion see API - File Systems. - - - - <filename>fstab</filename> - - Mount units may either be configured via unit - files, or via /etc/fstab (see - fstab5 - for details). Mounts listed in - /etc/fstab will be converted into - native units dynamically at boot and when the - configuration of the system manager is reloaded. In - general, configuring mount points through - /etc/fstab is the preferred - approach. See - systemd-fstab-generator8 - for details about the conversion. - - When reading /etc/fstab a - few special mount options are understood by systemd - which influence how dependencies are created for mount - points. systemd will create a dependency of type - or - (see option below), from - either local-fs.target or - remote-fs.target, depending - whether the file system is local or remote. - - - - - - - An automount unit will be created - for the file system. See - systemd.automount5 - for details. - - - - - - Configure how long systemd should - wait for a device to show up before giving up on - an entry from - /etc/fstab. Specify a time in - seconds or explicitly append a unit as - s, min, - h, - ms. - - Note that this option can only be used in - /etc/fstab, and will be - ignored when part of Options= - setting in a unit file. - - - - - - - - With , this - mount will not be added as a dependency for - local-fs.target or - remote-fs.target. This means - that it will not be mounted automatically during - boot, unless it is pulled in by some other - unit. Option has the - opposite meaning and is the default. - - - - - - - With this - mount will be only wanted, not required, by - local-fs.target or - remote-fs.target. This means - that the boot will continue even if this mount - point is not mounted successfully. - - - - - - - An additional filesystem to be - mounted in the initramfs. See - initrd-fs.target description - in - systemd.special7. - - - - - If a mount point is configured in both - /etc/fstab and a unit file that - is stored below /usr, the former - will take precedence. If the unit file is stored below - /etc, it will take - precedence. This means: native unit files take - precedence over traditional configuration files, but - this is superseded by the rule that configuration in - /etc will always take precedence - over configuration in - /usr. - - - - Options - - Mount files must include a [Mount] section, - which carries information about the file system mount points it - supervises. A number of options that may be used in - this section are shared with other unit types. These - options are documented in - systemd.exec5 - and - systemd.kill5. The - options specific to the [Mount] section of mount - units are the following: - - - - - What= - Takes an absolute path - of a device node, file or other - resource to mount. See - mount8 - for details. If this refers to a - device node, a dependency on the - respective device unit is - automatically created. (See - systemd.device5 for more information.) - This option is - mandatory. - - - - Where= - Takes an absolute path - of a directory of the mount point. If - the mount point does not exist at the - time of mounting, it is created. This - string must be reflected in the unit - filename. (See above.) This option is - mandatory. - - - - Type= - Takes a string for the - file system type. See - mount8 - for details. This setting is - optional. - - - - Options= - - Mount options to use - when mounting. This takes a - comma-separated list of options. This - setting is optional. - - - - SloppyOptions= - - Takes a boolean - argument. If true, parsing of the - options specified in - Options= is - relaxed, and unknown mount options are - tolerated. This corresponds with - mount8's - -s - switch. Defaults to - off. - - - - DirectoryMode= - Directories of mount - points (and any parent directories) - are automatically created if - needed. This option specifies the file - system access mode used when creating - these directories. Takes an access - mode in octal notation. Defaults to - 0755. - - - - TimeoutSec= - Configures the time to - wait for the mount command to - finish. If a command does not exit - within the configured time, the mount - will be considered failed and be shut - down again. All commands still running - will be terminated forcibly via - SIGTERM, and after another delay of - this time with SIGKILL. (See - in - systemd.kill5.) - Takes a unit-less value in seconds, or - a time span value such as "5min - 20s". Pass 0 to disable the timeout - logic. The default value is set from the manager configuration - file's DefaultTimeoutStart= variable. - - - - Check - systemd.exec5 - and - systemd.kill5 - for more settings. - - - - See Also - - systemd1, - systemctl1, - systemd.unit5, - systemd.exec5, - systemd.kill5, - systemd.resource-control5, - systemd.service5, - systemd.device5, - proc5, - mount8, - systemd-fstab-generator8, - systemd.directives7 - - + + systemd.mount + systemd + + + + Developer + Lennart + Poettering + lennart@poettering.net + + + + + + systemd.mount + 5 + + + + systemd.mount + Mount unit configuration + + + + mount.mount + + + + Description + + A unit configuration file whose name ends in + .mount encodes information about a file system + mount point controlled and supervised by systemd. + + This man page lists the configuration options specific to + this unit type. See + systemd.unit5 + for the common options of all unit configuration files. The common + configuration items are configured in the generic [Unit] and + [Install] sections. The mount specific configuration options are + configured in the [Mount] section. + + Additional options are listed in + systemd.exec5, + which define the execution environment the + mount8 + binary is executed in, and in + systemd.kill5, + which define the way the processes are terminated, and in + systemd.resource-control5, + which configure resource control settings for the processes of the + service. Note that the User= and Group= options are not + particularly useful for mount units specifying a + Type= option or using configuration not + specified in /etc/fstab; + mount8 + will refuse options that are not listed in + /etc/fstab if it is not run as UID 0. + + Mount units must be named after the mount point directories + they control. Example: the mount point + /home/lennart must be + configured in a unit file home-lennart.mount. + For details about the escaping logic used to convert a file system + path to a unit name, see + systemd.unit5. + + Optionally, a mount unit may be accompanied by an automount + unit, to allow on-demand or parallelized mounting. See + systemd.automount5. + + If a mount point is beneath another mount point in the file + system hierarchy, a dependency between both units is created + automatically. + + Mount points created at runtime (independently of unit files + or /etc/fstab) will be monitored by systemd + and appear like any other mount unit in systemd. See + /proc/self/mountinfo description in + proc5. + + + Some file systems have special semantics as API file systems + for kernel-to-userspace and userspace-to-userpace interfaces. Some + of them may not be changed via mount units, and cannot be + disabled. For a longer discussion see API + File Systems. + + + + <filename>fstab</filename> + + Mount units may either be configured via unit files, or via + /etc/fstab (see + fstab5 + for details). Mounts listed in /etc/fstab + will be converted into native units dynamically at boot and when + the configuration of the system manager is reloaded. In general, + configuring mount points through /etc/fstab + is the preferred approach. See + systemd-fstab-generator8 + for details about the conversion. + + When reading /etc/fstab a few special + mount options are understood by systemd which influence how + dependencies are created for mount points. systemd will create a + dependency of type or + (see option + below), from either local-fs.target or + remote-fs.target, depending whether the file + system is local or remote. + + + + + + + An automount unit will be created for the file + system. See + systemd.automount5 + for details. + + + + + + Configure how long systemd should wait for a + device to show up before giving up on an entry from + /etc/fstab. Specify a time in seconds or + explicitly append a unit as s, + min, h, + ms. + + Note that this option can only be used in + /etc/fstab, and will be + ignored when part of Options= + setting in a unit file. + + + + + + + + With , this mount will + not be added as a dependency for + local-fs.target or + remote-fs.target. This means that it will + not be mounted automatically during boot, unless it is pulled + in by some other unit. Option has the + opposite meaning and is the default. + + + + + + + With this mount will + be only wanted, not required, by + local-fs.target or + remote-fs.target. This means that the + boot will continue even if this mount point is not mounted + successfully. + + + + + + + An additional filesystem to be mounted in the + initramfs. See initrd-fs.target + description in + systemd.special7. + + + + + If a mount point is configured in both + /etc/fstab and a unit file that is stored + below /usr, the former will take precedence. + If the unit file is stored below /etc, it + will take precedence. This means: native unit files take + precedence over traditional configuration files, but this is + superseded by the rule that configuration in + /etc will always take precedence over + configuration in /usr. + + + + Options + + Mount files must include a [Mount] section, which carries + information about the file system mount points it supervises. A + number of options that may be used in this section are shared with + other unit types. These options are documented in + systemd.exec5 + and + systemd.kill5. + The options specific to the [Mount] section of mount units are the + following: + + + + + What= + Takes an absolute path of a device node, file + or other resource to mount. See + mount8 + for details. If this refers to a device node, a dependency on + the respective device unit is automatically created. (See + systemd.device5 + for more information.) This option is + mandatory. + + + + Where= + Takes an absolute path of a directory of the + mount point. If the mount point does not exist at the time of + mounting, it is created. This string must be reflected in the + unit filename. (See above.) This option is + mandatory. + + + + Type= + Takes a string for the file system type. See + mount8 + for details. This setting is optional. + + + + Options= + + Mount options to use when mounting. This takes + a comma-separated list of options. This setting is + optional. + + + + SloppyOptions= + + Takes a boolean argument. If true, parsing of + the options specified in Options= is + relaxed, and unknown mount options are tolerated. This + corresponds with + mount8's + -s switch. Defaults to + off. + + + + DirectoryMode= + Directories of mount points (and any parent + directories) are automatically created if needed. This option + specifies the file system access mode used when creating these + directories. Takes an access mode in octal notation. Defaults + to 0755. + + + + TimeoutSec= + Configures the time to wait for the mount + command to finish. If a command does not exit within the + configured time, the mount will be considered failed and be + shut down again. All commands still running will be terminated + forcibly via SIGTERM, and after another + delay of this time with SIGKILL. (See + in + systemd.kill5.) + Takes a unit-less value in seconds, or a time span value such + as "5min 20s". Pass 0 to disable the timeout logic. The + default value is set from the manager configuration file's + DefaultTimeoutStart= + variable. + + + + Check + systemd.exec5 + and + systemd.kill5 + for more settings. + + + + See Also + + systemd1, + systemctl1, + systemd.unit5, + systemd.exec5, + systemd.kill5, + systemd.resource-control5, + systemd.service5, + systemd.device5, + proc5, + mount8, + systemd-fstab-generator8, + systemd.directives7 + + diff --git a/man/systemd.netdev.xml b/man/systemd.netdev.xml index e278aa1a808..4480e1999d0 100644 --- a/man/systemd.netdev.xml +++ b/man/systemd.netdev.xml @@ -1,6 +1,6 @@ + "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd"> + "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd"> + "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd"> - - systemd.path - systemd - - - - Developer - Lennart - Poettering - lennart@poettering.net - - - - - - systemd.path - 5 - - - - systemd.path - Path unit configuration - - - - path.path - - - - Description - - A unit configuration file whose name ends in - .path encodes information about - a path monitored by systemd, for - path-based activation. - - This man page lists the configuration options - specific to this unit type. See - systemd.unit5 - for the common options of all unit configuration - files. The common configuration items are configured - in the generic [Unit] and [Install] sections. The - path specific configuration options are configured in - the [Path] section. - - For each path file, a matching unit file must - exist, describing the unit to activate when the path - changes. By default, a service by the same name as the - path (except for the suffix) is activated. Example: a - path file foo.path activates a - matching service foo.service. The - unit to activate may be controlled by - Unit= (see below). - - Internally, path units use the - inotify7 - API to monitor file systems. Due to that, it suffers by the - same limitations as inotify, and for example cannot be - used to monitor files or directories changed by other - machines on remote NFS file systems. - - If a path unit is beneath another mount - point in the file system hierarchy, a dependency - between both units is created automatically. - - Unless DefaultDependencies=false - is used, path units will implicitly have dependencies of - type Conflicts= and - Before= on - shutdown.target. These ensure - that path units are terminated cleanly prior to system - shutdown. Only path units involved with early boot or - late system shutdown should disable this option. - - - - - Options - - Path files must include a [Path] section, - which carries information about the path(s) it - monitors. The options specific to the [Path] section - of path units are the following: - - - - PathExists= - PathExistsGlob= - PathChanged= - PathModified= - DirectoryNotEmpty= - - Defines paths to - monitor for certain changes: - PathExists= may be - used to watch the mere existence of a - file or directory. If the file - specified exists, the configured unit - is - activated. PathExistsGlob= - works similar, but checks for the - existence of at least one file - matching the globbing pattern - specified. PathChanged= - may be used to watch a file or - directory and activate the configured - unit whenever it changes. It is not - activated on every write to the - watched file but it is activated if - the file which was open for writing - gets - closed. PathModified= - is similar, but additionally it is - activated also on simple writes to the - watched file. - DirectoryNotEmpty= - may be used to watch a directory and - activate the configured unit whenever - it contains at least one file. - - The arguments of these - directives must be absolute file - system paths. - - Multiple directives may be - combined, of the same and of different - types, to watch multiple paths. If the - empty string is assigned to any of - these options, the list of paths to - watch is reset, and any prior - assignments of these options will not - have any effect. - - If a path already exists - (in case of - PathExists= and - PathExistsGlob=) or - a directory already is not empty (in - case of - DirectoryNotEmpty=) - at the time the path unit is - activated, then the configured unit is - immediately activated as - well. Something similar does not apply - to PathChanged= and - PathModified=. - - If the path itself or any of the - containing directories are not - accessible, systemd - will watch for permission changes and - notice that conditions are satisfied - when permissions allow that. - - - - Unit= - - The unit to activate - when any of the configured paths - changes. The argument is a unit name, - whose suffix is not - .path. If not - specified, this value defaults to a - service that has the same name as the - path unit, except for the suffix. (See - above.) It is recommended that the - unit name that is activated and the - unit name of the path unit are named - identical, except for the - suffix. - - - MakeDirectory= - - Takes a boolean - argument. If true, the directories to - watch are created before - watching. This option is ignored for - PathExists= - settings. Defaults to - . - - - DirectoryMode= - - If - MakeDirectory= is - enabled, use the mode specified here to - create the directories in - question. Takes an access mode in - octal notation. Defaults to - . - - - - - - See Also - - systemd1, - systemctl1, - systemd.unit5, - systemd.service5, - inotify7, - systemd.directives7 - - + + systemd.path + systemd + + + + Developer + Lennart + Poettering + lennart@poettering.net + + + + + + systemd.path + 5 + + + + systemd.path + Path unit configuration + + + + path.path + + + + Description + + A unit configuration file whose name ends in + .path encodes information about a path + monitored by systemd, for path-based activation. + + This man page lists the configuration options specific to + this unit type. See + systemd.unit5 + for the common options of all unit configuration files. The common + configuration items are configured in the generic [Unit] and + [Install] sections. The path specific configuration options are + configured in the [Path] section. + + For each path file, a matching unit file must exist, + describing the unit to activate when the path changes. By default, + a service by the same name as the path (except for the suffix) is + activated. Example: a path file foo.path + activates a matching service foo.service. The + unit to activate may be controlled by Unit= + (see below). + + Internally, path units use the + inotify7 + API to monitor file systems. Due to that, it suffers by the same + limitations as inotify, and for example cannot be used to monitor + files or directories changed by other machines on remote NFS file + systems. + + If a path unit is beneath another mount point in the file + system hierarchy, a dependency between both units is created + automatically. + + Unless DefaultDependencies=false is used, + path units will implicitly have dependencies of type + Conflicts= and Before= on + shutdown.target. These ensure that path units + are terminated cleanly prior to system shutdown. Only path units + involved with early boot or late system shutdown should disable + this option. + + + + + Options + + Path files must include a [Path] section, which carries + information about the path(s) it monitors. The options specific to + the [Path] section of path units are the following: + + + + PathExists= + PathExistsGlob= + PathChanged= + PathModified= + DirectoryNotEmpty= + + Defines paths to monitor for certain changes: + PathExists= may be used to watch the mere + existence of a file or directory. If the file specified + exists, the configured unit is activated. + PathExistsGlob= works similar, but checks + for the existence of at least one file matching the globbing + pattern specified. PathChanged= may be used + to watch a file or directory and activate the configured unit + whenever it changes. It is not activated on every write to the + watched file but it is activated if the file which was open + for writing gets closed. PathModified= is + similar, but additionally it is activated also on simple + writes to the watched file. + DirectoryNotEmpty= may be used to watch a + directory and activate the configured unit whenever it + contains at least one file. + + The arguments of these directives must be absolute file + system paths. + + Multiple directives may be combined, of the same and of + different types, to watch multiple paths. If the empty string + is assigned to any of these options, the list of paths to + watch is reset, and any prior assignments of these options + will not have any effect. + + If a path already exists (in case of + PathExists= and + PathExistsGlob=) or a directory already is + not empty (in case of DirectoryNotEmpty=) + at the time the path unit is activated, then the configured + unit is immediately activated as well. Something similar does + not apply to PathChanged= and + PathModified=. + + If the path itself or any of the containing directories + are not accessible, systemd will watch for + permission changes and notice that conditions are satisfied + when permissions allow that. + + + Unit= + + The unit to activate when any of the + configured paths changes. The argument is a unit name, whose + suffix is not .path. If not specified, this + value defaults to a service that has the same name as the path + unit, except for the suffix. (See above.) It is recommended + that the unit name that is activated and the unit name of the + path unit are named identical, except for the + suffix. + + + MakeDirectory= + + Takes a boolean argument. If true, the + directories to watch are created before watching. This option + is ignored for PathExists= settings. + Defaults to . + + + DirectoryMode= + + If MakeDirectory= is + enabled, use the mode specified here to create the directories + in question. Takes an access mode in octal notation. Defaults + to . + + + + + + See Also + + systemd1, + systemctl1, + systemd.unit5, + systemd.service5, + inotify7, + systemd.directives7 + + diff --git a/man/systemd.preset.xml b/man/systemd.preset.xml index 55cb4de1740..2f9add8d6ca 100644 --- a/man/systemd.preset.xml +++ b/man/systemd.preset.xml @@ -21,183 +21,169 @@ --> - - systemd.preset - systemd - - - - Developer - Lennart - Poettering - lennart@poettering.net - - - - - - systemd.preset - 5 - - - - systemd.preset - Service enablement presets - - - - /etc/systemd/system-preset/*.preset - /run/systemd/system-preset/*.preset - /usr/lib/systemd/system-preset/*.preset - /etc/systemd/user-preset/*.preset - /run/systemd/user-preset/*.preset - /usr/lib/systemd/user-preset/*.preset - - - - Description - - Preset files may be used to encode policy which - units shall be enabled by default and which ones - shall be disabled. They are read by systemctl - preset (for more information see - systemctl1) - which uses this information to enable or disable a - unit according to preset policy. systemctl - preset is used by the post install - scriptlets of RPM packages (or other OS package formats), - to enable/disable specific units by default on package - installation, enforcing distribution, spin or - administrator preset policy. This allows choosing a certain - set of units to be enabled/disabled even before - installing the actual package. - - For more information on the preset logic please - have a look at the Presets - document. - - It is not recommended to ship preset files - within the respective software packages implementing - the units, but rather centralize them in a - distribution or spin default policy, which can be - amended by administrator policy. - - If no preset files exist, systemctl - preset will enable all units that are - installed by default. If this is not desired and all - units shall rather be disabled, it is necessary to ship - a preset file with a single, catchall - "disable *" line. (See example 1, - below.) - - - - Preset File Format - - The preset files contain a list of - directives consisting of either the word - enable or - disable followed by a space and a - unit name (possibly with shell style wildcards), - separated by newlines. Empty lines and lines whose - first non-whitespace character is # or ; are - ignored. - - Two different directives are understood: - enable may be used to enable units - by default, disable to disable - units by default. - - If multiple lines apply to a unit name, the - first matching one takes precedence over all - others. - - Each preset file shall be named in the style of - <priority>-<program>.conf. - Files in /etc/ override files - with the same name in /usr/lib/ - and /run/. Files in - /run/ override files with the - same name in /usr/lib/. Packages - should install their preset files in - /usr/lib/. Files in - /etc/ are reserved for the local - administrator, who may use this logic to override the - preset files installed by vendor packages. All preset - files are sorted by their filename in lexicographic - order, regardless of which of the directories they - reside in. If multiple files specify the same unit name, - the entry in the file with the lexicographically earliest - name will be applied. It is recommended to prefix all - filenames with a two-digit number and a dash, to simplify - the ordering of the files. - - If the administrator wants to disable a preset - file supplied by the vendor, the recommended way is to - place a symlink to /dev/null in - /etc/systemd/system-preset/ - bearing the same filename. - - - - Example - - - Default off example <filename>/usr/lib/systemd/system-preset/99-default.preset</filename>: - - disable * - - - This disables all units. Due to the filename - prefix 99-, it will be read last and - hence can easily be overridden by spin or - administrator preset policy or suchlike. - - - A GNOME spin example <filename>/usr/lib/systemd/system-preset/50-gnome.preset</filename>: - - enable gdm.service + + systemd.preset + systemd + + + + Developer + Lennart + Poettering + lennart@poettering.net + + + + + + systemd.preset + 5 + + + + systemd.preset + Service enablement presets + + + + /etc/systemd/system-preset/*.preset + /run/systemd/system-preset/*.preset + /usr/lib/systemd/system-preset/*.preset + /etc/systemd/user-preset/*.preset + /run/systemd/user-preset/*.preset + /usr/lib/systemd/user-preset/*.preset + + + + Description + + Preset files may be used to encode policy which units shall + be enabled by default and which ones shall be disabled. They are + read by systemctl preset (for more information + see + systemctl1) + which uses this information to enable or disable a unit according + to preset policy. systemctl preset is used by + the post install scriptlets of RPM packages (or other OS package + formats), to enable/disable specific units by default on package + installation, enforcing distribution, spin or administrator preset + policy. This allows choosing a certain set of units to be + enabled/disabled even before installing the actual package. + + For more information on the preset logic please have a look + at the Presets + document. + + It is not recommended to ship preset files within the + respective software packages implementing the units, but rather + centralize them in a distribution or spin default policy, which + can be amended by administrator policy. + + If no preset files exist, systemctl + preset will enable all units that are installed by + default. If this is not desired and all units shall rather be + disabled, it is necessary to ship a preset file with a single, + catchall "disable *" line. (See example 1, + below.) + + + + Preset File Format + + The preset files contain a list of directives consisting of + either the word enable or + disable followed by a space and a unit name + (possibly with shell style wildcards), separated by newlines. + Empty lines and lines whose first non-whitespace character is # or + ; are ignored. + + Two different directives are understood: + enable may be used to enable units by default, + disable to disable units by default. + + If multiple lines apply to a unit name, the first matching + one takes precedence over all others. + + Each preset file shall be named in the style of + <priority>-<program>.conf. Files + in /etc/ override files with the same name in + /usr/lib/ and /run/. + Files in /run/ override files with the same + name in /usr/lib/. Packages should install + their preset files in /usr/lib/. Files in + /etc/ are reserved for the local + administrator, who may use this logic to override the preset files + installed by vendor packages. All preset files are sorted by their + filename in lexicographic order, regardless of which of the + directories they reside in. If multiple files specify the same + unit name, the entry in the file with the lexicographically + earliest name will be applied. It is recommended to prefix all + filenames with a two-digit number and a dash, to simplify the + ordering of the files. + + If the administrator wants to disable a preset file supplied + by the vendor, the recommended way is to place a symlink to + /dev/null in + /etc/systemd/system-preset/ bearing the same + filename. + + + + Example + + + Default off example <filename>/usr/lib/systemd/system-preset/99-default.preset</filename>: + + disable * + + + This disables all units. Due to the filename prefix + 99-, it will be read last and hence can easily + be overridden by spin or administrator preset policy or + suchlike. + + + A GNOME spin example <filename>/usr/lib/systemd/system-preset/50-gnome.preset</filename>: + + enable gdm.service enable colord.service enable accounts-daemon.service enable avahi-daemon.* - + - This enables the three mentioned units, plus all - avahi-daemon regardless of which - unit type. A file like this could be useful for - inclusion in a GNOME spin of a distribution. It will - ensure that the units necessary for GNOME are properly - enabled as they are installed. It leaves all other - units untouched, and subject to other (later) preset - files, for example like the one from the first example - above. + This enables the three mentioned units, plus all + avahi-daemon regardless of which unit type. A + file like this could be useful for inclusion in a GNOME spin of a + distribution. It will ensure that the units necessary for GNOME + are properly enabled as they are installed. It leaves all other + units untouched, and subject to other (later) preset files, for + example like the one from the first example above. - - Administrator policy <filename>/etc/systemd/system-preset/00-lennart.preset</filename>: + + Administrator policy <filename>/etc/systemd/system-preset/00-lennart.preset</filename>: - enable httpd.service + enable httpd.service enable sshd.service enable postfix.service disable * - - - This enables three specific services and - disables all others. This is useful for administrators - to specifically select the units to enable, and - disable all others. Due to the filename prefix - 00- it will be read early and hence - overrides all other preset policy files. - - - - See Also - - systemd1, - systemctl1, - systemd-delta1 - - + + + This enables three specific services and disables all + others. This is useful for administrators to specifically select + the units to enable, and disable all others. Due to the filename + prefix 00- it will be read early and hence + overrides all other preset policy files. + + + + See Also + + systemd1, + systemctl1, + systemd-delta1 + + diff --git a/man/systemd.service.xml b/man/systemd.service.xml index f33e8df0569..37d9e982191 100644 --- a/man/systemd.service.xml +++ b/man/systemd.service.xml @@ -1,7 +1,7 @@ + "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd"> - - systemd.service - systemd - - - - Developer - Lennart - Poettering - lennart@poettering.net - - - - - - systemd.service - 5 - - - - systemd.service - Service unit configuration - - - - service.service - - - - Description - - A unit configuration file whose name ends in - .service encodes information - about a process controlled and supervised by - systemd. - - This man page lists the configuration options - specific to this unit type. See - systemd.unit5 - for the common options of all unit configuration - files. The common configuration items are configured - in the generic [Unit] and - [Install] sections. The service - specific configuration options are configured in the - [Service] section. - - Additional options are listed in - systemd.exec5, - which define the execution environment the commands - are executed in, and in - systemd.kill5, - which define the way the processes of the service are - terminated, and in - systemd.resource-control5, - which configure resource control settings for the - processes of the service. - - Unless DefaultDependencies= - is set to , service units will - implicitly have dependencies of type - Requires= and - After= on - basic.target as well as - dependencies of type Conflicts= and - Before= on - shutdown.target. These ensure - that normal service units pull in basic system - initialization, and are terminated cleanly prior to - system shutdown. Only services involved with early - boot or late system shutdown should disable this - option. - - If a service is requested under a certain name - but no unit configuration file is found, systemd looks - for a SysV init script by the same name (with the - .service suffix removed) and - dynamically creates a service unit from that - script. This is useful for compatibility with - SysV. Note that this compatibility is quite - comprehensive but not 100%. For details about the - incompatibilities, see the Incompatibilities - with SysV document. - - - - - Options - - Service files must include a - [Service] section, which carries - information about the service and the process it - supervises. A number of options that may be used in - this section are shared with other unit types. These - options are documented in - systemd.exec5 - and - systemd.kill5. The - options specific to the [Service] - section of service units are the following: - - - - Type= - - Configures the process - start-up type for this service - unit. One of , - , - , - , - or - . - - If set to - (the default - if neither - Type= nor - BusName=, but - ExecStart= are - specified), it is expected that the - process configured with - ExecStart= is the - main process of the service. In this - mode, if the process offers - functionality to other processes on - the system, its communication channels - should be installed before the daemon - is started up (e.g. sockets set up by - systemd, via socket activation), as - systemd will immediately proceed - starting follow-up units. - - If set to - , it is - expected that the process configured - with ExecStart= - will call fork() - as part of its start-up. The parent process is - expected to exit when start-up is - complete and all communication - channels are set up. The child continues - to run as the main daemon - process. This is the behavior of - traditional UNIX daemons. If this - setting is used, it is recommended to - also use the - PIDFile= option, so - that systemd can identify the main - process of the daemon. systemd will - proceed with starting follow-up units - as soon as the parent process - exits. - - Behavior of - is similar to - ; however, it - is expected that the process has to - exit before systemd starts follow-up - units. RemainAfterExit= - is particularly useful for this type - of service. This is the implied - default if neither - Type= or - ExecStart= are - specified. - - Behavior of - is similar to - ; however, it is - expected that the daemon acquires a - name on the D-Bus bus, as configured - by - BusName=. systemd - will proceed with starting follow-up - units after the D-Bus bus name has been - acquired. Service units with this - option configured implicitly gain - dependencies on the - dbus.socket - unit. This type is the default if - BusName= is - specified. - - Behavior of - is similar to - ; however, it is - expected that the daemon sends a - notification message via - sd_notify3 - or an equivalent call when it has finished - starting up. systemd will proceed with - starting follow-up units after this - notification message has been sent. If - this option is used, - NotifyAccess= (see - below) should be set to open access to - the notification socket provided by - systemd. If - NotifyAccess= is - not set, it will be implicitly set to - . Note that - currently - Type= - will not work if used in combination with - PrivateNetwork=. - - Behavior of - is very similar - to ; however, - actual execution of the service - binary is delayed until all jobs are - dispatched. This may be used to avoid - interleaving of output of shell - services with the status output on the - console. - - - - - RemainAfterExit= - - Takes a boolean value - that specifies whether the service - shall be considered active even when - all its processes exited. Defaults to - . - - - - - GuessMainPID= - - Takes a boolean value - that specifies whether systemd should - try to guess the main PID of a service - if it cannot be determined - reliably. This option is ignored - unless - is set and - is unset because for the other types - or with an explicitly configured PID - file, the main PID is always known. The - guessing algorithm might come to - incorrect conclusions if a daemon - consists of more than one process. If - the main PID cannot be determined, - failure detection and automatic - restarting of a service will not work - reliably. Defaults to - . - - - - - PIDFile= - - Takes an absolute file - name pointing to the PID file of this - daemon. Use of this option is - recommended for services where - Type= is set to - . systemd will - read the PID of the main process of - the daemon after start-up of the - service. systemd will not write to the - file configured here. - - - - - BusName= - - Takes a D-Bus bus - name that this service is reachable - as. This option is mandatory for - services where - Type= is set to - . - - - - - BusPolicy= - - If specified, a custom - kdbus - endpoint will be created and installed as the - default bus node for the service. Such a custom - endpoint can hold an own set of policy rules - that are enforced on top of the bus-wide ones. - The custom endpoint is named after the service - it was created for, and its node will be - bind-mounted over the default bus node - location, so the service can only access the - bus through its own endpoint. Note that custom - bus endpoints default to a 'deny all' policy. - Hence, if at least one - BusPolicy= directive is - given, you have to make sure to add explicit - rules for everything the service should be able - to do. - The value of this directive is comprised - of two parts; the bus name, and a verb to - specify to granted access, which is one of - , - , or - . - implies - , and - implies both and - . - If multiple access levels are specified for the - same bus name, the most powerful one takes - effect. - - Examples: - BusPolicy=org.freedesktop.systemd1 talk - BusPolicy=org.foo.bar see - This option is only available on kdbus enabled systems. - - - - - ExecStart= - Commands with their - arguments that are executed when this - service is started. The value is split - into zero or more command lines is - according to the rules described below - (see section "Command Lines" below). - - - When Type is - not , only one - command may and must be given. When - Type=oneshot is - used, zero or more commands may be - specified. This can be specified by - providing multiple command lines in - the same directive, or alternatively, - this directive may be specified more - than once with the same effect. If the - empty string is assigned to this - option, the list of commands to start - is reset, prior assignments of this - option will have no effect. If no - ExecStart= is - specified, then the service must have - RemainAfterExit=yes - set. - - For each of the specified - commands, the first argument must be - an absolute path to an executable. - Optionally, if this file name is - prefixed with @, - the second token will be passed as - argv[0] to the - executed process, followed by the - further arguments specified. If the - absolute filename is prefixed with - -, an exit code of - the command normally considered a - failure (i.e. non-zero exit status or - abnormal exit due to signal) is - ignored and considered success. If - both - and - @ are used, they - can appear in either order. - - If more than one command is - specified, the commands are invoked - sequentially in the order they appear - in the unit file. If one of the - commands fails (and is not prefixed - with -), other - lines are not executed, and the unit - is considered failed. - - Unless - Type=forking is - set, the process started via this - command line will be considered the - main process of the daemon. - - - - - - ExecStartPre= - ExecStartPost= - Additional commands - that are executed before or after - the command in - ExecStart=, respectively. - Syntax is the same as for - ExecStart=, except - that multiple command lines are allowed - and the commands are executed one - after the other, serially. - - If any of those commands (not - prefixed with -) - fail, the rest are not executed and - the unit is considered failed. - - - - - ExecReload= - Commands to execute to - trigger a configuration reload in the - service. This argument takes multiple - command lines, following the same - scheme as described for - ExecStart= - above. Use of this setting is - optional. Specifier and environment - variable substitution is supported - here following the same scheme as for - ExecStart=. - - One additional, special - environment variable is set: if known, - $MAINPID is set to - the main process of the daemon, and - may be used for command lines like the - following: - - /bin/kill -HUP $MAINPID - - Note however that reloading a - daemon by sending a signal (as with - the example line above) is usually not - a good choice, because this is an - asynchronous operation and hence not - suitable to order reloads of multiple - services against each other. It is - strongly recommended to set - ExecReload= to a - command that not only triggers a - configuration reload of the daemon, - but also synchronously waits for it to - complete. - - - - - ExecStop= - Commands to execute to - stop the service started via - ExecStart=. This - argument takes multiple command lines, - following the same scheme as described - for ExecStart= - above. Use of this setting is - optional. After the commands configured - in this option are run, all processes - remaining for a service are - terminated according to the - KillMode= setting - (see - systemd.kill5). If - this option is not specified, the - process is terminated immediately when - service stop is requested. Specifier - and environment variable substitution - is supported (including - $MAINPID, see - above). - - - - ExecStopPost= - Additional commands - that are executed after the service - was stopped. This includes cases where - the commands configured in - ExecStop= were used, - where the service does not have any - ExecStop= defined, or - where the service exited unexpectedly. This - argument takes multiple command lines, - following the same scheme as described - for ExecStart. Use - of these settings is - optional. Specifier and environment - variable substitution is - supported. - - - - RestartSec= - Configures the time to - sleep before restarting a service (as - configured with - Restart=). Takes a - unit-less value in seconds, or a time - span value such as "5min - 20s". Defaults to - 100ms. - - - - TimeoutStartSec= - Configures the time to - wait for start-up. If a - daemon service does not signal - start-up completion within the - configured time, the service will be - considered failed and will be shut - down again. - Takes a unit-less value in seconds, or a - time span value such as "5min - 20s". Pass 0 to - disable the timeout logic. Defaults to - DefaultTimeoutStartSec= from - the manager configuration file, except - when Type=oneshot is - used, in which case the timeout - is disabled by default - (see systemd-system.conf5). - - - - - TimeoutStopSec= - Configures the time to - wait for stop. If a service is asked - to stop, but does not terminate in the - specified time, it will be terminated - forcibly via SIGTERM, - and after another timeout of equal duration - with SIGKILL (see - KillMode= - in systemd.kill5). - Takes a unit-less value in seconds, or a - time span value such as "5min - 20s". Pass 0 to disable - the timeout logic. Defaults to - DefaultTimeoutStopSec= from the - manager configuration file - (see systemd-system.conf5). - - - - - TimeoutSec= - A shorthand for configuring - both TimeoutStartSec= - and TimeoutStopSec= - to the specified value. - - - - - WatchdogSec= - Configures the - watchdog timeout for a service. The - watchdog is activated when the start-up is - completed. The service must call - sd_notify3 - regularly with WATCHDOG=1 - (i.e. the "keep-alive ping"). If the time - between two such calls is larger than - the configured time, then the service - is placed in a failed state and it will - be terminated with SIGABRT. - By setting Restart= to - or - , the service - will be automatically restarted. The - time configured here will be passed to - the executed service process in the - WATCHDOG_USEC= - environment variable. This allows - daemons to automatically enable the - keep-alive pinging logic if watchdog - support is enabled for the service. If - this option is used, - NotifyAccess= (see - below) should be set to open access to - the notification socket provided by - systemd. If - NotifyAccess= is - not set, it will be implicitly set to - . Defaults to 0, - which disables this - feature. - - - - Restart= - Configures whether the - service shall be restarted when the - service process exits, is killed, - or a timeout is reached. The service - process may be the main service - process, but it may also be one of the - processes specified with - ExecStartPre=, - ExecStartPost=, - ExecStop=, - ExecStopPost=, or - ExecReload=. - When the death of the process is a - result of systemd operation (e.g. service - stop or restart), the service will not be - restarted. Timeouts include missing - the watchdog "keep-alive ping" - deadline and a service start, reload, - and stop operation timeouts. - - Takes one of - , - , - , - , - , - , or - . If set to - (the default), the - service will not be restarted. If set - to , it - will be restarted only when the - service process exits cleanly. In - this context, a clean exit means an - exit code of 0, or one of the signals - SIGHUP, - SIGINT, - SIGTERM or - SIGPIPE, and - additionally, exit statuses and - signals specified in - SuccessExitStatus=. - If set to , - the service will be restarted when the - process exits with a non-zero exit - code, is terminated by a signal - (including on core dump, but excluding - the aforementiond four signals), when - an operation (such as service reload) - times out, and when the configured - watchdog timeout is triggered. If set - to , the - service will be restarted when the - process is terminated by a signal - (including on core dump, excluding the - aforementioned four signals), when an - operation times out, or when the - watchdog timeout is triggered. If set - to , the - service will be restarted only if the - service process exits due to an - uncaught signal not specified as a - clean exit status. If set to - , the - service will be restarted only if the - watchdog timeout for the service - expires. If set to - , the service - will be restarted regardless of - whether it exited cleanly or not, got - terminated abnormally by a signal, or - hit a timeout. - - - Exit causes and the effect of the <varname>Restart=</varname> settings on them - - - - - - - Restart settings/Exit causes - - - - - - - - - - - - Clean exit code or signal - - X - X - - - - - - - Unclean exit code - - X - - X - - - - - - Unclean signal - - X - - X - X - X - - - - Timeout - - X - - X - X - - - - - Watchdog - - X - - X - X - - X - - - -
- - As exceptions to the setting - above the service will not be - restarted if the exit code or signal - is specified in - RestartPreventExitStatus= - (see below). Also, the services will - always be restarted if the exit code - or signal is specified in - RestartForceExitStatus= - (see below). - - Setting this to - is the - recommended choice for long-running - services, in order to increase - reliability by attempting automatic - recovery from errors. For services - that shall be able to terminate on - their own choice (and avoid - immediate restarting), - is an - alternative choice. - - - - - SuccessExitStatus= - Takes a list of exit - status definitions that when returned - by the main service process will be - considered successful termination, in - addition to the normal successful exit - code 0 and the signals SIGHUP, SIGINT, - SIGTERM, and SIGPIPE. Exit status - definitions can either be numeric exit - codes or termination signal names, - separated by spaces. For example: - SuccessExitStatus=1 2 8 SIGKILL - ensures that exit codes 1, 2, 8 and - the termination signal - SIGKILL are - considered clean service terminations. - - - Note that if a process has a - signal handler installed and exits by - calling - _exit2 - in response to a signal, the - information about the signal is lost. - Programs should instead perform cleanup and kill themselves with the same signal instead. See - Proper handling of SIGINT/SIGQUIT — How to be a proper program. - - This option may appear more than once, - in which case the list of successful - exit statuses is merged. If the empty - string is assigned to this option, the - list is reset, all prior assignments - of this option will have no - effect. - - - - RestartPreventExitStatus= - Takes a list of exit - status definitions that when returned - by the main service process will - prevent automatic service restarts, - regardless of the restart setting - configured with - Restart=. Exit - status definitions can either be - numeric exit codes or termination - signal names, and are separated by - spaces. Defaults to the empty list, so - that, by default, no exit status is - excluded from the configured restart - logic. For example: - RestartPreventExitStatus=1 6 SIGABRT ensures that exit - codes 1 and 6 and the termination - signal SIGABRT will - not result in automatic service - restarting. This - option may appear more than once, in - which case the list of restart-preventing - statuses is merged. If the empty - string is assigned to this option, the - list is reset and all prior assignments - of this option will have no - effect. - - - - RestartForceExitStatus= - Takes a list of exit - status definitions that when returned - by the main service process will force - automatic service restarts, regardless - of the restart setting configured with - Restart=. The - argument format is similar to - RestartPreventExitStatus=. - - - - PermissionsStartOnly= - Takes a boolean - argument. If true, the permission-related - execution options, as - configured with - User= and similar - options (see - systemd.exec5 - for more information), are only applied - to the process started with - ExecStart=, and not - to the various other - ExecStartPre=, - ExecStartPost=, - ExecReload=, - ExecStop=, and - ExecStopPost= - commands. If false, the setting is - applied to all configured commands the - same way. Defaults to - false. - - - - RootDirectoryStartOnly= - Takes a boolean - argument. If true, the root directory, - as configured with the - RootDirectory= - option (see - systemd.exec5 - for more information), is only applied - to the process started with - ExecStart=, and not - to the various other - ExecStartPre=, - ExecStartPost=, - ExecReload=, - ExecStop=, and - ExecStopPost= - commands. If false, the setting is - applied to all configured commands the - same way. Defaults to - false. - - - - NonBlocking= - Set the - O_NONBLOCK flag - for all file descriptors passed via - socket-based activation. If true, all - file descriptors >= 3 (i.e. all except - stdin, stdout, and stderr) will have - the O_NONBLOCK flag - set and hence are in - non-blocking mode. This option is only - useful in conjunction with a socket - unit, as described in - systemd.socket5. Defaults - to false. - - - - NotifyAccess= - Controls access to the - service status notification socket, as - accessible via the - sd_notify3 - call. Takes one of - (the default), - or - . If - , no daemon status - updates are accepted from the service - processes, all status update messages - are ignored. If , - only service updates sent from the - main process of the service are - accepted. If , all - services updates from all members of - the service's control group are - accepted. This option should be set to - open access to the notification socket - when using - Type=notify or - WatchdogSec= (see - above). If those options are used but - NotifyAccess= is not - configured, it will be implicitly set - to - . - - - - Sockets= - Specifies the name of - the socket units this service shall - inherit socket file descriptors - from when the service is - started. Normally it should not be - necessary to use this setting as all - socket file descriptors whose unit - shares the same name as the service - (subject to the different unit name - suffix of course) are passed to the - spawned process. - - Note that the same socket file - descriptors may be passed to multiple - processes simultaneously. Also note - that a different service may be - activated on incoming socket traffic - than the one which is ultimately - configured to inherit the socket file - descriptors. Or in other words: the - Service= setting of - .socket units - does not have to match the inverse of - the Sockets= - setting of the - .service it - refers to. - - This option may appear more than - once, in which case the list of socket - units is merged. If the empty string - is assigned to this option, the list of - sockets is reset, and all prior uses of - this setting will have no - effect. - - - - StartLimitInterval= - StartLimitBurst= - - Configure service - start rate limiting. By default, - services which are started more - than 5 times within 10 seconds are not - permitted to start any more times - until the 10 second interval ends. With - these two options, this rate limiting - may be modified. Use - StartLimitInterval= - to configure the checking interval (defaults to - DefaultStartLimitInterval= in - manager configuration file, set to 0 to disable - any kind of rate limiting). Use - StartLimitBurst= to - configure how many starts per interval - are allowed (defaults to - DefaultStartLimitBurst= in - manager configuration file). These - configuration options are particularly - useful in conjunction with - Restart=; however, - they apply to all kinds of starts - (including manual), not just those - triggered by the - Restart= logic. - Note that units which are configured - for Restart= and - which reach the start limit are not - attempted to be restarted anymore; - however, they may still be restarted - manually at a later point, from which - point on, the restart logic is again - activated. Note that - systemctl - reset-failed will cause the - restart rate counter for a service to - be flushed, which is useful if the - administrator wants to manually start - a service and the start limit - interferes with - that. - - - - StartLimitAction= - - Configure the action - to take if the rate limit configured - with - StartLimitInterval= - and - StartLimitBurst= is - hit. Takes one of - , - , - , - , - , - or - . If - is set, hitting - the rate limit will trigger no action - besides that the start will not be - permitted. - causes a reboot following the normal - shutdown procedure (i.e. equivalent to - systemctl reboot). - causes a - forced reboot which will terminate all - processes forcibly but should cause no - dirty file systems on reboot - (i.e. equivalent to systemctl - reboot -f) and - - causes immediate execution of the - reboot2 - system call, which might result in - data loss. Similar, - , - , - - have the effect of powering down the - system with similar - semantics. Defaults to - . - - - - FailureAction= - Configure the action - to take when the service enters a failed - state. Takes the same values as - StartLimitAction= - and executes the same actions. - Defaults to . - - - - - RebootArgument= - Configure the optional - argument for the - reboot2 - system call if - StartLimitAction= - or FailureAction= - is a reboot action. This works just - like the optional argument to - systemctl reboot - command. - - - - FileDescriptorStoreMax= - Configure how many - file descriptors may be stored in the - service manager for the service using - sd_pid_notify_with_fds3's - FDSTORE=1 - messages. This is useful for - implementing service restart schemes - where the state is serialized to - /run and the file - descriptors passed to the service - manager, to allow restarts without - losing state. Defaults to 0, i.e. no - file descriptors may be stored in the - service manager by default. All file - descriptors passed to the service - manager from a specific service are - passed back to the service's main - process on the next service - restart. Any file descriptors passed - to the service manager are - automatically closed when POLLHUP or - POLLERR is seen on them, or when the - service is fully stopped and no job - queued or being executed for - it. - - - - - Check - systemd.exec5 - and - systemd.kill5 - for more settings. - - - - - Command lines - - This section describes command line parsing and - variable and specifier substitions for - ExecStart=, - ExecStartPre=, - ExecStartPost=, - ExecReload=, - ExecStop=, and - ExecStopPost= options. - - Multiple command lines may be concatenated in a - single directive by separating them with semicolons - (these semicolons must be passed as separate words). - Lone semicolons may be escaped as - \;. - - Each command line is split on whitespace, with - the first item being the command to execute, and the - subsequent items being the arguments. Double quotes - ("...") and single quotes ('...') may be used, in - which case everything until the next matching quote - becomes part of the same argument. C-style escapes are - also supported, see table below. Quotes themselves are - removed after parsing and escape sequences - substituted. In addition, a trailing backslash - (\) may be used to merge lines. - - - This syntax is intended to be very similar to - shell syntax, but only the meta-characters and - expansions described in the following paragraphs are - understood. Specifically, redirection using - <, <<, - >, and - >>, pipes using - |, running programs in the - background using &, and - other elements of shell syntax are not - supported. - - The command to execute must an absolute path - name. It may contain spaces, but control characters - are not allowed. - - The command line accepts % - specifiers as described in - systemd.unit5. - Note that the first argument of the command line - (i.e. the program to execute) may not include - specifiers. - - Basic environment variable substitution is - supported. Use ${FOO} as part of a - word, or as a word of its own, on the command line, in - which case it will be replaced by the value of the - environment variable including all whitespace it - contains, resulting in a single argument. Use - $FOO as a separate word on the - command line, in which case it will be replaced by the - value of the environment variable split at whitespace - resulting in zero or more arguments. For this type of - expansion, quotes and respected when splitting into - words, and afterwards removed. - - Example: - - Environment="ONE=one" 'TWO=two two' + + systemd.service + systemd + + + + Developer + Lennart + Poettering + lennart@poettering.net + + + + + + systemd.service + 5 + + + + systemd.service + Service unit configuration + + + + service.service + + + + Description + + A unit configuration file whose name ends in + .service encodes information about a process + controlled and supervised by systemd. + + This man page lists the configuration options specific to + this unit type. See + systemd.unit5 + for the common options of all unit configuration files. The common + configuration items are configured in the generic + [Unit] and [Install] + sections. The service specific configuration options are + configured in the [Service] section. + + Additional options are listed in + systemd.exec5, + which define the execution environment the commands are executed + in, and in + systemd.kill5, + which define the way the processes of the service are terminated, + and in + systemd.resource-control5, + which configure resource control settings for the processes of the + service. + + Unless DefaultDependencies= is set to + , service units will implicitly have + dependencies of type Requires= and + After= on basic.target as + well as dependencies of type Conflicts= and + Before= on + shutdown.target. These ensure that normal + service units pull in basic system initialization, and are + terminated cleanly prior to system shutdown. Only services + involved with early boot or late system shutdown should disable + this option. + + If a service is requested under a certain name but no unit + configuration file is found, systemd looks for a SysV init script + by the same name (with the .service suffix + removed) and dynamically creates a service unit from that script. + This is useful for compatibility with SysV. Note that this + compatibility is quite comprehensive but not 100%. For details + about the incompatibilities, see the Incompatibilities + with SysV document. + + + + + Options + + Service files must include a [Service] + section, which carries information about the service and the + process it supervises. A number of options that may be used in + this section are shared with other unit types. These options are + documented in + systemd.exec5 + and + systemd.kill5. + The options specific to the [Service] section + of service units are the following: + + + + Type= + + Configures the process start-up type for this + service unit. One of + , + , + , + , + or + . + + If set to (the default if + neither Type= nor + BusName=, but ExecStart= + are specified), it is expected that the process configured + with ExecStart= is the main process of the + service. In this mode, if the process offers functionality to + other processes on the system, its communication channels + should be installed before the daemon is started up (e.g. + sockets set up by systemd, via socket activation), as systemd + will immediately proceed starting follow-up units. + + If set to , it is expected that + the process configured with ExecStart= will + call fork() as part of its start-up. The + parent process is expected to exit when start-up is complete + and all communication channels are set up. The child continues + to run as the main daemon process. This is the behavior of + traditional UNIX daemons. If this setting is used, it is + recommended to also use the PIDFile= + option, so that systemd can identify the main process of the + daemon. systemd will proceed with starting follow-up units as + soon as the parent process exits. + + Behavior of is similar to + ; however, it is expected that the + process has to exit before systemd starts follow-up units. + RemainAfterExit= is particularly useful for + this type of service. This is the implied default if neither + Type= or ExecStart= are + specified. + + Behavior of is similar to + ; however, it is expected that the + daemon acquires a name on the D-Bus bus, as configured by + BusName=. systemd will proceed with + starting follow-up units after the D-Bus bus name has been + acquired. Service units with this option configured implicitly + gain dependencies on the dbus.socket + unit. This type is the default if BusName= + is specified. + + Behavior of is similar to + ; however, it is expected that the + daemon sends a notification message via + sd_notify3 + or an equivalent call when it has finished starting up. + systemd will proceed with starting follow-up units after this + notification message has been sent. If this option is used, + NotifyAccess= (see below) should be set to + open access to the notification socket provided by systemd. If + NotifyAccess= is not set, it will be + implicitly set to . Note that currently + Type= will not work + if used in combination with + PrivateNetwork=. + + Behavior of is very similar to + ; however, actual execution of the + service binary is delayed until all jobs are dispatched. This + may be used to avoid interleaving of output of shell services + with the status output on the console. + + + + + RemainAfterExit= + + Takes a boolean value that specifies whether + the service shall be considered active even when all its + processes exited. Defaults to . + + + + + GuessMainPID= + + Takes a boolean value that specifies whether + systemd should try to guess the main PID of a service if it + cannot be determined reliably. This option is ignored unless + is set and + is unset because for the other types + or with an explicitly configured PID file, the main PID is + always known. The guessing algorithm might come to incorrect + conclusions if a daemon consists of more than one process. If + the main PID cannot be determined, failure detection and + automatic restarting of a service will not work reliably. + Defaults to . + + + + + PIDFile= + + Takes an absolute file name pointing to the + PID file of this daemon. Use of this option is recommended for + services where Type= is set to + . systemd will read the PID of the + main process of the daemon after start-up of the service. + systemd will not write to the file configured here. + + + + + BusName= + + Takes a D-Bus bus name that this service is + reachable as. This option is mandatory for services where + Type= is set to + . + + + + + BusPolicy= + + If specified, a custom + kdbus + endpoint will be created and installed as the default bus node + for the service. Such a custom endpoint can hold an own set of + policy rules that are enforced on top of the bus-wide ones. + The custom endpoint is named after the service it was created + for, and its node will be bind-mounted over the default bus + node location, so the service can only access the bus through + its own endpoint. Note that custom bus endpoints default to a + 'deny all' policy. Hence, if at least one + BusPolicy= directive is given, you have to + make sure to add explicit rules for everything the service + should be able to do. + The value of this directive is comprised + of two parts; the bus name, and a verb to + specify to granted access, which is one of + , + , or + . + implies + , and + implies both and + . + If multiple access levels are specified for the + same bus name, the most powerful one takes + effect. + + Examples: + BusPolicy=org.freedesktop.systemd1 talk + BusPolicy=org.foo.bar see + This option is only available on kdbus enabled systems. + + + + + ExecStart= + Commands with their arguments that are + executed when this service is started. The value is split into + zero or more command lines is according to the rules described + below (see section "Command Lines" below). + + + When Type is not + , only one command may and must be + given. When Type=oneshot is used, zero or + more commands may be specified. This can be specified by + providing multiple command lines in the same directive, or + alternatively, this directive may be specified more than once + with the same effect. If the empty string is assigned to this + option, the list of commands to start is reset, prior + assignments of this option will have no effect. If no + ExecStart= is specified, then the service + must have RemainAfterExit=yes set. + + For each of the specified commands, the first argument + must be an absolute path to an executable. Optionally, if this + file name is prefixed with @, the second + token will be passed as argv[0] to the + executed process, followed by the further arguments specified. + If the absolute filename is prefixed with + -, an exit code of the command normally + considered a failure (i.e. non-zero exit status or abnormal + exit due to signal) is ignored and considered success. If both + - and @ are used, they + can appear in either order. + + If more than one command is specified, the commands are + invoked sequentially in the order they appear in the unit + file. If one of the commands fails (and is not prefixed with + -), other lines are not executed, and the + unit is considered failed. + + Unless Type=forking is set, the + process started via this command line will be considered the + main process of the daemon. + + + + + ExecStartPre= + ExecStartPost= + Additional commands that are executed before + or after the command in ExecStart=, + respectively. Syntax is the same as for + ExecStart=, except that multiple command + lines are allowed and the commands are executed one after the + other, serially. + + If any of those commands (not prefixed with + -) fail, the rest are not executed and the + unit is considered failed. + + + + + ExecReload= + Commands to execute to trigger a configuration + reload in the service. This argument takes multiple command + lines, following the same scheme as described for + ExecStart= above. Use of this setting is + optional. Specifier and environment variable substitution is + supported here following the same scheme as for + ExecStart=. + + One additional, special environment variable is set: if + known, $MAINPID is set to the main process + of the daemon, and may be used for command lines like the + following: + + /bin/kill -HUP $MAINPID + + Note however that reloading a daemon by sending a signal + (as with the example line above) is usually not a good choice, + because this is an asynchronous operation and hence not + suitable to order reloads of multiple services against each + other. It is strongly recommended to set + ExecReload= to a command that not only + triggers a configuration reload of the daemon, but also + synchronously waits for it to complete. + + + + + ExecStop= + Commands to execute to stop the service + started via ExecStart=. This argument takes + multiple command lines, following the same scheme as described + for ExecStart= above. Use of this setting + is optional. After the commands configured in this option are + run, all processes remaining for a service are terminated + according to the KillMode= setting (see + systemd.kill5). + If this option is not specified, the process is terminated + immediately when service stop is requested. Specifier and + environment variable substitution is supported (including + $MAINPID, see above). + + + + ExecStopPost= + Additional commands that are executed after + the service was stopped. This includes cases where the + commands configured in ExecStop= were used, + where the service does not have any + ExecStop= defined, or where the service + exited unexpectedly. This argument takes multiple command + lines, following the same scheme as described for + ExecStart. Use of these settings is + optional. Specifier and environment variable substitution is + supported. + + + + RestartSec= + Configures the time to sleep before restarting + a service (as configured with Restart=). + Takes a unit-less value in seconds, or a time span value such + as "5min 20s". Defaults to 100ms. + + + + TimeoutStartSec= + Configures the time to wait for start-up. If a + daemon service does not signal start-up completion within the + configured time, the service will be considered failed and + will be shut down again. Takes a unit-less value in seconds, + or a time span value such as "5min 20s". Pass + 0 to disable the timeout logic. Defaults to + DefaultTimeoutStartSec= from the manager + configuration file, except when + Type=oneshot is used, in which case the + timeout is disabled by default (see + systemd-system.conf5). + + + + + TimeoutStopSec= + Configures the time to wait for stop. If a + service is asked to stop, but does not terminate in the + specified time, it will be terminated forcibly via + SIGTERM, and after another timeout of + equal duration with SIGKILL (see + KillMode= in + systemd.kill5). + Takes a unit-less value in seconds, or a time span value such + as "5min 20s". Pass 0 to disable the + timeout logic. Defaults to + DefaultTimeoutStopSec= from the manager + configuration file (see + systemd-system.conf5). + + + + + TimeoutSec= + A shorthand for configuring both + TimeoutStartSec= and + TimeoutStopSec= to the specified value. + + + + + WatchdogSec= + Configures the watchdog timeout for a service. + The watchdog is activated when the start-up is completed. The + service must call + sd_notify3 + regularly with WATCHDOG=1 (i.e. the + "keep-alive ping"). If the time between two such calls is + larger than the configured time, then the service is placed in + a failed state and it will be terminated with + SIGABRT. By setting + Restart= to or + , the service will be automatically + restarted. The time configured here will be passed to the + executed service process in the + WATCHDOG_USEC= environment variable. This + allows daemons to automatically enable the keep-alive pinging + logic if watchdog support is enabled for the service. If this + option is used, NotifyAccess= (see below) + should be set to open access to the notification socket + provided by systemd. If NotifyAccess= is + not set, it will be implicitly set to . + Defaults to 0, which disables this feature. + + + + Restart= + Configures whether the service shall be + restarted when the service process exits, is killed, or a + timeout is reached. The service process may be the main + service process, but it may also be one of the processes + specified with ExecStartPre=, + ExecStartPost=, + ExecStop=, + ExecStopPost=, or + ExecReload=. When the death of the process + is a result of systemd operation (e.g. service stop or + restart), the service will not be restarted. Timeouts include + missing the watchdog "keep-alive ping" deadline and a service + start, reload, and stop operation timeouts. + + Takes one of + , + , + , + , + , + , or + . + If set to (the default), the service will + not be restarted. If set to , it + will be restarted only when the service process exits cleanly. + In this context, a clean exit means an exit code of 0, or one + of the signals + SIGHUP, + SIGINT, + SIGTERM or + SIGPIPE, and + additionally, exit statuses and signals specified in + SuccessExitStatus=. If set to + , the service will be restarted + when the process exits with a non-zero exit code, is + terminated by a signal (including on core dump, but excluding + the aforementiond four signals), when an operation (such as + service reload) times out, and when the configured watchdog + timeout is triggered. If set to , + the service will be restarted when the process is terminated + by a signal (including on core dump, excluding the + aforementioned four signals), when an operation times out, or + when the watchdog timeout is triggered. If set to + , the service will be restarted only + if the service process exits due to an uncaught signal not + specified as a clean exit status. If set to + , the service will be restarted + only if the watchdog timeout for the service expires. If set + to , the service will be restarted + regardless of whether it exited cleanly or not, got terminated + abnormally by a signal, or hit a timeout. + + + Exit causes and the effect of the <varname>Restart=</varname> settings on them + + + + + + + Restart settings/Exit causes + + + + + + + + + + + + Clean exit code or signal + + X + X + + + + + + + Unclean exit code + + X + + X + + + + + + Unclean signal + + X + + X + X + X + + + + Timeout + + X + + X + X + + + + + Watchdog + + X + + X + X + + X + + + +
+ + As exceptions to the setting above the service will not + be restarted if the exit code or signal is specified in + RestartPreventExitStatus= (see below). + Also, the services will always be restarted if the exit code + or signal is specified in + RestartForceExitStatus= (see below). + + Setting this to is the + recommended choice for long-running services, in order to + increase reliability by attempting automatic recovery from + errors. For services that shall be able to terminate on their + own choice (and avoid immediate restarting), + is an alternative choice. + + + + + SuccessExitStatus= + Takes a list of exit status definitions that + when returned by the main service process will be considered + successful termination, in addition to the normal successful + exit code 0 and the signals SIGHUP, + SIGINT, SIGTERM, and + SIGPIPE. Exit status definitions can + either be numeric exit codes or termination signal names, + separated by spaces. For example: + SuccessExitStatus=1 2 8 + SIGKILL ensures that exit codes 1, 2, 8 and + the termination signal SIGKILL are + considered clean service terminations. + + + Note that if a process has a signal handler installed + and exits by calling + _exit2 + in response to a signal, the information about the signal is + lost. Programs should instead perform cleanup and kill + themselves with the same signal instead. See + Proper + handling of SIGINT/SIGQUIT — How to be a proper + program. + + This option may appear more than once, in which case the + list of successful exit statuses is merged. If the empty + string is assigned to this option, the list is reset, all + prior assignments of this option will have no + effect. + + + + RestartPreventExitStatus= + Takes a list of exit status definitions that + when returned by the main service process will prevent + automatic service restarts, regardless of the restart setting + configured with Restart=. Exit status + definitions can either be numeric exit codes or termination + signal names, and are separated by spaces. Defaults to the + empty list, so that, by default, no exit status is excluded + from the configured restart logic. For example: + RestartPreventExitStatus=1 6 + SIGABRT ensures that exit codes 1 and 6 and + the termination signal SIGABRT will not + result in automatic service restarting. This option may appear + more than once, in which case the list of restart-preventing + statuses is merged. If the empty string is assigned to this + option, the list is reset and all prior assignments of this + option will have no effect. + + + + RestartForceExitStatus= + Takes a list of exit status definitions that + when returned by the main service process will force automatic + service restarts, regardless of the restart setting configured + with Restart=. The argument format is + similar to + RestartPreventExitStatus=. + + + + PermissionsStartOnly= + Takes a boolean argument. If true, the + permission-related execution options, as configured with + User= and similar options (see + systemd.exec5 + for more information), are only applied to the process started + with + ExecStart=, and not to the various other + ExecStartPre=, + ExecStartPost=, + ExecReload=, + ExecStop=, and + ExecStopPost= + commands. If false, the setting is applied to all configured + commands the same way. Defaults to false. + + + + RootDirectoryStartOnly= + Takes a boolean argument. If true, the root + directory, as configured with the + RootDirectory= option (see + systemd.exec5 + for more information), is only applied to the process started + with ExecStart=, and not to the various + other ExecStartPre=, + ExecStartPost=, + ExecReload=, ExecStop=, + and ExecStopPost= commands. If false, the + setting is applied to all configured commands the same way. + Defaults to false. + + + + NonBlocking= + Set the O_NONBLOCK flag + for all file descriptors passed via socket-based activation. + If true, all file descriptors >= 3 (i.e. all except stdin, + stdout, and stderr) will have the + O_NONBLOCK flag set and hence are in + non-blocking mode. This option is only useful in conjunction + with a socket unit, as described in + systemd.socket5. + Defaults to false. + + + + NotifyAccess= + Controls access to the service status + notification socket, as accessible via the + sd_notify3 + call. Takes one of (the default), + or . If + , no daemon status updates are accepted + from the service processes, all status update messages are + ignored. If , only service updates sent + from the main process of the service are accepted. If + , all services updates from all members of + the service's control group are accepted. This option should + be set to open access to the notification socket when using + Type=notify or + WatchdogSec= (see above). If those options + are used but NotifyAccess= is not + configured, it will be implicitly set to + . + + + + Sockets= + Specifies the name of the socket units this + service shall inherit socket file descriptors from when the + service is started. Normally it should not be necessary to use + this setting as all socket file descriptors whose unit shares + the same name as the service (subject to the different unit + name suffix of course) are passed to the spawned + process. + + Note that the same socket file descriptors may be passed + to multiple processes simultaneously. Also note that a + different service may be activated on incoming socket traffic + than the one which is ultimately configured to inherit the + socket file descriptors. Or in other words: the + Service= setting of + .socket units does not have to match the + inverse of the Sockets= setting of the + .service it refers to. + + This option may appear more than once, in which case the + list of socket units is merged. If the empty string is + assigned to this option, the list of sockets is reset, and all + prior uses of this setting will have no + effect. + + + + StartLimitInterval= + StartLimitBurst= + + Configure service start rate limiting. By + default, services which are started more than 5 times within + 10 seconds are not permitted to start any more times until the + 10 second interval ends. With these two options, this rate + limiting may be modified. Use + StartLimitInterval= to configure the + checking interval (defaults to + DefaultStartLimitInterval= in manager + configuration file, set to 0 to disable any kind of rate + limiting). Use StartLimitBurst= to + configure how many starts per interval are allowed (defaults + to DefaultStartLimitBurst= in manager + configuration file). These configuration options are + particularly useful in conjunction with + Restart=; however, they apply to all kinds + of starts (including manual), not just those triggered by the + Restart= logic. Note that units which are + configured for Restart= and which reach the + start limit are not attempted to be restarted anymore; + however, they may still be restarted manually at a later + point, from which point on, the restart logic is again + activated. Note that systemctl reset-failed + will cause the restart rate counter for a service to be + flushed, which is useful if the administrator wants to + manually start a service and the start limit interferes with + that. + + + + StartLimitAction= + + Configure the action to take if the rate limit + configured with StartLimitInterval= and + StartLimitBurst= is hit. Takes one of + , + , + , + , + , + or + . If + is set, hitting the rate limit will + trigger no action besides that the start will not be + permitted. causes a reboot following + the normal shutdown procedure (i.e. equivalent to + systemctl reboot). + causes a forced reboot which + will terminate all processes forcibly but should cause no + dirty file systems on reboot (i.e. equivalent to + systemctl reboot -f) and + causes immediate execution + of the + reboot2 + system call, which might result in data loss. Similar, + , , + have the effect of + powering down the system with similar semantics. Defaults to + . + + + + FailureAction= + Configure the action to take when the service + enters a failed state. Takes the same values as + StartLimitAction= and executes the same + actions. Defaults to . + + + + RebootArgument= + Configure the optional argument for the + reboot2 + system call if StartLimitAction= or + FailureAction= is a reboot action. This + works just like the optional argument to systemctl + reboot command. + + + + FileDescriptorStoreMax= + Configure how many file descriptors may be + stored in the service manager for the service using + sd_pid_notify_with_fds3's + FDSTORE=1 messages. This is useful for + implementing service restart schemes where the state is + serialized to /run and the file + descriptors passed to the service manager, to allow restarts + without losing state. Defaults to 0, i.e. no file descriptors + may be stored in the service manager by default. All file + descriptors passed to the service manager from a specific + service are passed back to the service's main process on the + next service restart. Any file descriptors passed to the + service manager are automatically closed when POLLHUP or + POLLERR is seen on them, or when the service is fully stopped + and no job queued or being executed for it. + + + + + Check + systemd.exec5 + and + systemd.kill5 + for more settings. + + + + + Command lines + + This section describes command line parsing and + variable and specifier substitions for + ExecStart=, + ExecStartPre=, + ExecStartPost=, + ExecReload=, + ExecStop=, and + ExecStopPost= options. + + Multiple command lines may be concatenated in a single + directive by separating them with semicolons (these semicolons + must be passed as separate words). Lone semicolons may be escaped + as \;. + + Each command line is split on whitespace, with the first + item being the command to execute, and the subsequent items being + the arguments. Double quotes ("...") and single quotes ('...') may + be used, in which case everything until the next matching quote + becomes part of the same argument. C-style escapes are also + supported, see table below. Quotes themselves are removed after + parsing and escape sequences substituted. In addition, a trailing + backslash (\) may be used to merge lines. + + + This syntax is intended to be very similar to shell syntax, + but only the meta-characters and expansions described in the + following paragraphs are understood. Specifically, redirection + using + <, + <<, + >, and + >>, pipes using + |, running programs in the background using + &, and other elements of shell + syntax are not supported. + + The command to execute must an absolute path name. It may + contain spaces, but control characters are not allowed. + + The command line accepts % specifiers as + described in + systemd.unit5. + Note that the first argument of the command line (i.e. the program + to execute) may not include specifiers. + + Basic environment variable substitution is supported. Use + ${FOO} as part of a word, or as a word of its + own, on the command line, in which case it will be replaced by the + value of the environment variable including all whitespace it + contains, resulting in a single argument. Use + $FOO as a separate word on the command line, in + which case it will be replaced by the value of the environment + variable split at whitespace resulting in zero or more arguments. + For this type of expansion, quotes and respected when splitting + into words, and afterwards removed. + + Example: + + Environment="ONE=one" 'TWO=two two' ExecStart=/bin/echo $ONE $TWO ${TWO} - This will execute /bin/echo - with four arguments: one, - two, two, and - two two. + This will execute /bin/echo with four + arguments: one, two, + two, and two two. - Example: - Environment=ONE='one' "TWO='two two' too" THREE= + Example: + Environment=ONE='one' "TWO='two two' too" THREE= ExecStart=/bin/echo ${ONE} ${TWO} ${THREE} ExecStart=/bin/echo $ONE $TWO $THREE - This results in echo being - called twice, the first time with arguments - 'one', - 'two two' too, , - and the second time with arguments - one, two two, - too. - - - To pass a literal dollar sign, use - $$. Variables whose value is not - known at expansion time are treated as empty - strings. Note that the first argument (i.e. the - program to execute) may not be a variable. - - Variables to be used in this fashion may be - defined through Environment= and - EnvironmentFile=. In addition, - variables listed in the section "Environment variables - in spawned processes" in - systemd.exec5, - which are considered "static configuration", may be - used (this includes e.g. $USER, but - not $TERM). - - Note that shell command lines are not directly - supported. If shell command lines are to be used, they - need to be passed explicitly to a shell implementation - of some kind. Example: - ExecStart=/bin/sh -c 'dmesg | tac' - - Example: - - ExecStart=/bin/echo one ; /bin/echo "two two" - - This will execute /bin/echo - two times, each time with one argument: - one and two two, - respectively. Because two commands are specified, - Type=oneshot must be used. - - Example: - - ExecStart=/bin/echo / >/dev/null & \; \ + This results in echo being + called twice, the first time with arguments + 'one', + 'two two' too, , + and the second time with arguments + one, two two, + too. + + + To pass a literal dollar sign, use $$. + Variables whose value is not known at expansion time are treated + as empty strings. Note that the first argument (i.e. the program + to execute) may not be a variable. + + Variables to be used in this fashion may be defined through + Environment= and + EnvironmentFile=. In addition, variables listed + in the section "Environment variables in spawned processes" in + systemd.exec5, + which are considered "static configuration", may be used (this + includes e.g. $USER, but not + $TERM). + + Note that shell command lines are not directly supported. If + shell command lines are to be used, they need to be passed + explicitly to a shell implementation of some kind. Example: + ExecStart=/bin/sh -c 'dmesg | tac' + + Example: + + ExecStart=/bin/echo one ; /bin/echo "two two" + + This will execute /bin/echo two times, + each time with one argument: one and + two two, respectively. Because two commands are + specified, Type=oneshot must be used. + + Example: + + ExecStart=/bin/echo / >/dev/null & \; \ /bin/ls - This will execute /bin/echo - with five arguments: /, - >/dev/null, - &, ;, and - /bin/ls. - - - C escapes supported in command lines and environment variables - - - - - - Literal - Actual value - - - - - \a - bell - - - \b - backspace - - - \f - form feed - - - \n - newline - - - \r - carriage return - - - \t - tab - - - \v - vertical tab - - - \\ - backslash - - - \" - double quotation mark - - - \' - single quotation mark - - - \s - space - - - \xxx - character number xx in hexadecimal encoding - - - \nnn - character number nnn in octal encoding - - - -
- - - - Examples - - - Simple service - - The following unit file creates a service - that will execute - /usr/sbin/foo-daemon. - Since no Type= is specified, - the default - Type= - will be assumed. systemd will assume the unit - to be started immediately after the program has - begun executing. - - [Unit] + This will execute /bin/echo + with five arguments: /, + >/dev/null, + &, ;, and + /bin/ls. + + + C escapes supported in command lines and environment variables + + + + + + Literal + Actual value + + + + + \a + bell + + + \b + backspace + + + \f + form feed + + + \n + newline + + + \r + carriage return + + + \t + tab + + + \v + vertical tab + + + \\ + backslash + + + \" + double quotation mark + + + \' + single quotation mark + + + \s + space + + + \xxx + character number xx in hexadecimal encoding + + + \nnn + character number nnn in octal encoding + + + +
+ + + + Examples + + + Simple service + + The following unit file creates a service that will + execute /usr/sbin/foo-daemon. Since no + Type= is specified, the default + Type= will be assumed. + systemd will assume the unit to be started immediately after the + program has begun executing. + + [Unit] Description=Foo [Service] @@ -1382,50 +1094,42 @@ ExecStart=/usr/sbin/foo-daemon [Install] WantedBy=multi-user.target - Note that systemd assumes here that the - process started by systemd will continue - running until the service terminates. If the - program daemonizes itself (i.e. forks), please - use - Type= - instead. - - Since no ExecStop= was - specified, systemd will send SIGTERM to all - processes started from this service, and after - a timeout also SIGKILL. This behavior can be - modified, see - systemd.kill5 - for details. - - Note that this unit type does not include - any type of notification when a service has - completed initialization. For this, you should - use other unit types, such as - Type= - if the service understands systemd's - notification protocol, - Type= - if the service can background itself or - Type= - if the unit acquires a DBus name once - initialization is complete. See below. - - - - Oneshot service - - Sometimes units should just execute an - action without keeping active processes, such - as a filesystem check or a cleanup action on - boot. For this, - Type= - exists. Units of this type will wait until the - process specified terminates and then fall back - to being inactive. The following unit will - perform a clenaup action: - - [Unit] + Note that systemd assumes here that the process started by + systemd will continue running until the service terminates. If + the program daemonizes itself (i.e. forks), please use + Type= instead. + + Since no ExecStop= was specified, + systemd will send SIGTERM to all processes started from this + service, and after a timeout also SIGKILL. This behavior can be + modified, see + systemd.kill5 + for details. + + Note that this unit type does not include any type of + notification when a service has completed initialization. For + this, you should use other unit types, such as + Type= if the service + understands systemd's notification protocol, + Type= if the service + can background itself or + Type= if the unit + acquires a DBus name once initialization is complete. See + below. + + + + Oneshot service + + Sometimes units should just execute an action without + keeping active processes, such as a filesystem check or a + cleanup action on boot. For this, + Type= exists. Units + of this type will wait until the process specified terminates + and then fall back to being inactive. The following unit will + perform a clenaup action: + + [Unit] Description=Cleanup old Foo data [Service] @@ -1435,60 +1139,50 @@ ExecStart=/usr/sbin/foo-cleanup [Install] WantedBy=multi-user.target - Note that systemd will consider the unit - to be in the state 'starting' until the program - has terminated, so ordered dependencies will - wait for the program to finish before starting - themselves. The unit will revert to the - 'inactive' state after the execution is - done, never reaching the 'active' state. That - means another request to start the unit will - perform the action again. - - Type= - are the only service units that may have more - than one ExecStart= - specified. They will be executed in order until - either they are all successful or one of them - fails. - - - - Stoppable oneshot service - - Similarly to the oneshot services, there - are sometimes units that need to execute a - program to set up something and then execute - another to shut it down, but no process remains - active while they are considered - 'started'. Network configuration can sometimes - fall into this category. Another use case is if - a oneshot service shall not be executed a - each time when they are pulled in as a - dependency, but only the first time. - - For this, systemd knows the setting - RemainAfterExit=, - which causes systemd to consider the unit to be - active if the start action exited successfully. - This directive can be used with all types, but - is most useful with - Type= - and - Type=. - With - Type= - systemd waits until the start action has - completed before it considers the unit to be - active, so dependencies start only after the - start action has succeeded. With - Type= - dependencies will start immediately after the - start action has been dispatched. The following - unit provides an example for a simple static - firewall. - - [Unit] + Note that systemd will consider the unit to be in the + state 'starting' until the program has terminated, so ordered + dependencies will wait for the program to finish before starting + themselves. The unit will revert to the 'inactive' state after + the execution is done, never reaching the 'active' state. That + means another request to start the unit will perform the action + again. + + Type= are the + only service units that may have more than one + ExecStart= specified. They will be executed + in order until either they are all successful or one of them + fails. + + + + Stoppable oneshot service + + Similarly to the oneshot services, there are sometimes + units that need to execute a program to set up something and + then execute another to shut it down, but no process remains + active while they are considered 'started'. Network + configuration can sometimes fall into this category. Another use + case is if a oneshot service shall not be executed a each time + when they are pulled in as a dependency, but only the first + time. + + For this, systemd knows the setting + RemainAfterExit=, which + causes systemd to consider the unit to be active if the start + action exited successfully. This directive can be used with all + types, but is most useful with + Type= and + Type=. With + Type= systemd waits + until the start action has completed before it considers the + unit to be active, so dependencies start only after the start + action has succeeded. With + Type= dependencies + will start immediately after the start action has been + dispatched. The following unit provides an example for a simple + static firewall. + + [Unit] Description=Simple firewall [Service] @@ -1500,56 +1194,46 @@ ExecStop=/usr/local/sbin/simple-firewall-stop [Install] WantedBy=multi-user.target - Since the unit is considered to be - running after the start action has exited, - invoking systemctl start on - that unit again will cause no action to be - taken. - - - - Traditional forking services - - Many traditional daemons/services - background (i.e. fork, daemonize) themselves - when starting. Set - Type= - in the service's unit file to support this mode - of operation. systemd will consider the service - to be in the process of initialization while - the original program is still running. Once - it exits successfully and at least a process - remains (and - RemainAfterExit=), - the service is considered started. - - Often a traditional daemon only consists - of one process. Therefore, if only one process - is left after the original process terminates, - systemd will consider that process the main - process of the service. In that case, the - $MAINPID variable will be - available in ExecReload=, - ExecStop=, etc. - - In case more than one process remains, - systemd will be unable to determine the main - process, so it will not assume there is one. - In that case, $MAINPID will - not expand to anything. However, if the process - decides to write a traditional PID file, - systemd will be able to read the main PID from - there. Please set PIDFile= - accordingly. Note that the daemon should write - that file before finishing with its - initialization, otherwise systemd might try to - read the file before it exists. - - The following example shows a simple - daemon that forks and just starts one process - in the background: - - [Unit] + Since the unit is considered to be running after the start + action has exited, invoking systemctl start + on that unit again will cause no action to be taken. + + + + Traditional forking services + + Many traditional daemons/services background (i.e. fork, + daemonize) themselves when starting. Set + Type= in the + service's unit file to support this mode of operation. systemd + will consider the service to be in the process of initialization + while the original program is still running. Once it exits + successfully and at least a process remains (and + RemainAfterExit=), the + service is considered started. + + Often a traditional daemon only consists of one process. + Therefore, if only one process is left after the original + process terminates, systemd will consider that process the main + process of the service. In that case, the + $MAINPID variable will be available in + ExecReload=, ExecStop=, + etc. + + In case more than one process remains, systemd will be + unable to determine the main process, so it will not assume + there is one. In that case, $MAINPID will not + expand to anything. However, if the process decides to write a + traditional PID file, systemd will be able to read the main PID + from there. Please set PIDFile= accordingly. + Note that the daemon should write that file before finishing + with its initialization, otherwise systemd might try to read the + file before it exists. + + The following example shows a simple daemon that forks and + just starts one process in the background: + + [Unit] Description=Some simple daemon [Service] @@ -1559,26 +1243,23 @@ ExecStart=/usr/sbin/my-simple-daemon -d [Install] WantedBy=multi-user.target - Please see - systemd.kill5 - for details on how you can influence the way - systemd terminates the service. - - - - DBus services - - For services that acquire a name on the - DBus system bus, use - Type= - and set BusName= - accordingly. The service should not fork - (daemonize). systemd will consider the service - to be initialized once the name has been - acquired on the system bus. The following - example shows a typical DBus service: - - [Unit] + Please see + systemd.kill5 + for details on how you can influence the way systemd terminates + the service. + + + + DBus services + + For services that acquire a name on the DBus system bus, + use Type= and set + BusName= accordingly. The service should not + fork (daemonize). systemd will consider the service to be + initialized once the name has been acquired on the system bus. + The following example shows a typical DBus service: + + [Unit] Description=Simple DBus service [Service] @@ -1589,43 +1270,38 @@ ExecStart=/usr/sbin/simple-dbus-service [Install] WantedBy=multi-user.target - For bus-activatable - services, don't include a - [Install] section in the - systemd service file, but use the - SystemdService= option in - the corresponding DBus service file, for - example - (/usr/share/dbus-1/system-services/org.example.simple-dbus-service.service): + For bus-activatable services, don't + include a [Install] section in the systemd + service file, but use the SystemdService= + option in the corresponding DBus service file, for example + (/usr/share/dbus-1/system-services/org.example.simple-dbus-service.service): - [D-BUS Service] + [D-BUS Service] Name=org.example.simple-dbus-service Exec=/usr/sbin/simple-dbus-service User=root SystemdService=simple-dbus-service.service - Please see - systemd.kill5 - for details on how you can influence the way - systemd terminates the service. - - - - Services that notify systemd about their initialization - - Type= - services are really easy to write, but have the - major disadvantage of systemd not being able to - tell when initialization of the given service - is complete. For this reason, systemd supports - a simple notification protocol that allows - daemons to make systemd aware that they are - done initializing. Use - Type= - for this. A typical service file for such a - daemon would look like this: - - [Unit] + Please see + systemd.kill5 + for details on how you can influence the way systemd terminates + the service. + + + + Services that notify systemd about their initialization + + Type= services + are really easy to write, but have the major disadvantage of + systemd not being able to tell when initialization of the given + service is complete. For this reason, systemd supports a simple + notification protocol that allows daemons to make systemd aware + that they are done initializing. Use + Type= for this. A + typical service file for such a daemon would look like + this: + + [Unit] Description=Simple notifying service [Service] @@ -1635,35 +1311,32 @@ ExecStart=/usr/sbin/simple-notifying-service [Install] WantedBy=multi-user.target - Note that the daemon has to support - systemd's notification protocol, else systemd - will think the service hasn't started yet and - kill it after a timeout. For an example of how - to update daemons to support this protocol - transparently, take a look at - sd_notify3. - systemd will consider the unit to be in the - 'starting' state until a readiness notification - has arrived. - - Please see - systemd.kill5 - for details on how you can influence the way - systemd terminates the service. - - - - - See Also - - systemd1, - systemctl1, - systemd.unit5, - systemd.exec5, - systemd.resource-control5, - systemd.kill5, - systemd.directives7 - - + Note that the daemon has to support systemd's notification + protocol, else systemd will think the service hasn't started yet + and kill it after a timeout. For an example of how to update + daemons to support this protocol transparently, take a look at + sd_notify3. + systemd will consider the unit to be in the 'starting' state + until a readiness notification has arrived. + + Please see + systemd.kill5 + for details on how you can influence the way systemd terminates + the service. + + + + + See Also + + systemd1, + systemctl1, + systemd.unit5, + systemd.exec5, + systemd.resource-control5, + systemd.kill5, + systemd.directives7 + + diff --git a/man/systemd.snapshot.xml b/man/systemd.snapshot.xml index f08e38e07e7..e2d67391df3 100644 --- a/man/systemd.snapshot.xml +++ b/man/systemd.snapshot.xml @@ -1,7 +1,7 @@ + "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd"> - - systemd.snapshot - systemd + + systemd.snapshot + systemd - - - Developer - Lennart - Poettering - lennart@poettering.net - - - + + + Developer + Lennart + Poettering + lennart@poettering.net + + + - - systemd.snapshot - 5 - + + systemd.snapshot + 5 + - - systemd.snapshot - Snapshot unit configuration - + + systemd.snapshot + Snapshot unit configuration + - - snapshot.snapshot - + + snapshot.snapshot + - - Description + + Description - Snapshot units are not configured via unit - configuration files. Nonetheless they are named - similar to filenames. A unit whose name ends in - .snapshot refers to a dynamic - snapshot of the systemd runtime state. + Snapshot units are not configured via unit configuration + files. Nonetheless they are named similar to filenames. A unit + whose name ends in .snapshot refers to a + dynamic snapshot of the systemd runtime state. - Snapshots are not configured on disk but created - dynamically via systemctl snapshot - (see - systemctl1 - for details) or an equivalent command. When created, - they will automatically get dependencies on the - currently activated units. They act as saved - runtime state of the systemd manager. Later on, the - user may choose to return to the saved state via - systemctl isolate. They are - useful to roll back to a defined state after - temporarily starting/stopping services or - similar. - + Snapshots are not configured on disk but created dynamically + via systemctl snapshot (see + systemctl1 + for details) or an equivalent command. When created, they will + automatically get dependencies on the currently activated units. + They act as saved runtime state of the systemd manager. Later on, + the user may choose to return to the saved state via + systemctl isolate. They are useful to roll back + to a defined state after temporarily starting/stopping services or + similar. + - - See Also - - systemd1, - systemctl1, - systemd.unit5, - systemd.directives7 - - + + See Also + + systemd1, + systemctl1, + systemd.unit5, + systemd.directives7 + + diff --git a/man/systemd.socket.xml b/man/systemd.socket.xml index 57f769f23a1..c8b483c4128 100644 --- a/man/systemd.socket.xml +++ b/man/systemd.socket.xml @@ -1,7 +1,7 @@ + "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd"> - - systemd.socket - systemd - - - - Developer - Lennart - Poettering - lennart@poettering.net - - - - - - systemd.socket - 5 - - - - systemd.socket - Socket unit configuration - - - - socket.socket - - - - Description - - A unit configuration file whose name ends in - .socket encodes information about - an IPC or network socket or a file system FIFO - controlled and supervised by systemd, for socket-based - activation. - - This man page lists the configuration options - specific to this unit type. See - systemd.unit5 - for the common options of all unit configuration - files. The common configuration items are configured - in the generic [Unit] and [Install] sections. The - socket specific configuration options are configured - in the [Socket] section. - - Additional options are listed in - systemd.exec5, - which define the execution environment the - , - , - and - commands are executed - in, and in - systemd.kill5, - which define the way the processes are terminated, and - in - systemd.resource-control5, - which configure resource control settings for the - processes of the socket. - - For each socket file, a matching service file - must exist, describing the service to start on - incoming traffic on the socket (see - systemd.service5 - for more information about .service files). The name - of the .service unit is by default the same as the - name of the .socket unit, but can be altered with the - option described below. - Depending on the setting of the - option described below, this .service unit must either - be named like the .socket unit, but with the suffix - replaced, unless overridden with - ; or it must be a template - unit named the same way. Example: a socket file - foo.socket needs a matching - service foo.service if - is set. If - is set, a service - template file foo@.service must - exist from which services are instantiated for each - incoming connection. - - Unless DefaultDependencies= - is set to , socket units will - implicitly have dependencies of type - Requires= and - After= on - sysinit.target as well as - dependencies of type Conflicts= and - Before= on - shutdown.target. These ensure - that socket units pull in basic system - initialization, and are terminated cleanly prior to - system shutdown. Only sockets involved with early - boot or late system shutdown should disable this - option. - - Socket units will have a - Before= dependency on the service - which they trigger added implicitly. No implicit - WantedBy= or - RequiredBy= dependency from the - socket to the service is added. This means that the - service may be started without the socket, in which - case it must be able to open sockets by itself. To - prevent this, an explicit Requires= - dependency may be added. - - Socket units may be used to implement on-demand - starting of services, as well as parallelized starting - of services. See the blog stories linked at the end - for an introduction. - - Note that the daemon software configured for - socket activation with socket units needs to be able - to accept sockets from systemd, either via systemd's - native socket passing interface (see - sd_listen_fds3 - for details) or via the traditional - inetd8-style - socket passing (i.e. sockets passed in via standard input and - output, using StandardInput=socket - in the service file). - - - - Options - - Socket files must include a [Socket] section, - which carries information about the socket or FIFO it - supervises. A number of options that may be used in - this section are shared with other unit types. These - options are documented in - systemd.exec5 - and - systemd.kill5. The - options specific to the [Socket] section of socket - units are the following: - - - - ListenStream= - ListenDatagram= - ListenSequentialPacket= - Specifies an address - to listen on for a stream - (SOCK_STREAM), datagram (SOCK_DGRAM), - or sequential packet - (SOCK_SEQPACKET) socket, respectively. The address - can be written in various formats: - - If the address starts with a - slash (/), it is read as file system - socket in the AF_UNIX socket - family. - - If the address starts with an at - symbol (@), it is read as abstract - namespace socket in the - AF_UNIX - family. The @ is - replaced with a - NUL character - before binding. For details, see - unix7. - - If the address string is a - single number, it is read as port - number to listen on via - IPv6. Depending on the value of - BindIPv6Only= (see below) this - might result in the service being - available via both IPv6 and IPv4 (default) or - just via IPv6. - - - If the address string is a - string in the format v.w.x.y:z, it is - read as IPv4 specifier for listening - on an address v.w.x.y on a port - z. - - If the address string is a - string in the format [x]:y, it is read - as IPv6 address x on a port y. Note - that this might make the service - available via IPv4, too, depending on - the BindIPv6Only= - setting (see below). - - - Note that SOCK_SEQPACKET - (i.e. ListenSequentialPacket=) - is only available for AF_UNIX - sockets. SOCK_STREAM - (i.e. ListenStream=) - when used for IP sockets refers to TCP - sockets, SOCK_DGRAM - (i.e. ListenDatagram=) - to UDP. - - These options may be specified - more than once in which case incoming - traffic on any of the sockets will - trigger service activation, and all - listed sockets will be passed to the - service, regardless of whether there is - incoming traffic on them or not. If - the empty string is assigned to any of - these options, the list of addresses - to listen on is reset, all prior uses - of any of these options will have no - effect. - - It is also possible to have more - than one socket unit for the same - service when using - Service=, and the - service will receive all the sockets - configured in all the socket units. - Sockets configured in one unit are - passed in the order of configuration, - but no ordering between socket units - is specified. - - If an IP address is used here, - it is often desirable to listen on it - before the interface it is configured - on is up and running, and even - regardless of whether it will be up and - running at any point. To deal with this, - it is recommended to set the - FreeBind= option - described below. - - - - ListenFIFO= - Specifies a file - system FIFO to listen on. This expects - an absolute file system path as - argument. Behavior otherwise is very - similar to the - ListenDatagram= - directive above. - - - - ListenSpecial= - Specifies a special - file in the file system to listen - on. This expects an absolute file - system path as argument. Behavior - otherwise is very similar to the - ListenFIFO= - directive above. Use this to open - character device nodes as well as - special files in - /proc and - /sys. - - - - ListenNetlink= - Specifies a Netlink - family to create a socket for to - listen on. This expects a short string - referring to the AF_NETLINK family - name (such as audit - or kobject-uevent) - as argument, optionally suffixed by a - whitespace followed by a multicast - group integer. Behavior otherwise is - very similar to the - ListenDatagram= - directive above. - - - - ListenMessageQueue= - Specifies a POSIX - message queue name to listen on. This - expects a valid message queue name - (i.e. beginning with /). Behavior - otherwise is very similar to the - ListenFIFO= - directive above. On Linux message - queue descriptors are actually file - descriptors and can be inherited - between processes. - - - - BindIPv6Only= - Takes a one of - , - or - . Controls - the IPV6_V6ONLY socket option (see - ipv67 - for details). If - , IPv6 sockets - bound will be accessible via both IPv4 - and IPv6. If - , they will - be accessible via IPv6 only. If - (which is the - default, surprise!), the system wide - default setting is used, as controlled - by - /proc/sys/net/ipv6/bindv6only, - which in turn defaults to the - equivalent of - . - - - - - Backlog= - Takes an unsigned - integer argument. Specifies the number - of connections to queue that have not - been accepted yet. This setting - matters only for stream and sequential - packet sockets. See - listen2 - for details. Defaults to SOMAXCONN - (128). - - - - BindToDevice= - Specifies a network - interface name to bind this socket - to. If set, traffic will only be - accepted from the specified network - interfaces. This controls the - SO_BINDTODEVICE socket option (see - socket7 - for details). If this option is used, - an automatic dependency from this - socket unit on the network interface - device unit - (systemd.device5 - is created. - - - - SocketUser= - SocketGroup= - - Takes a UNIX - user/group name. When specified, - all AF_UNIX sockets and FIFO nodes in - the file system are owned by the - specified user and group. If unset - (the default), the nodes are owned by - the root user/group (if run in system - context) or the invoking user/group - (if run in user context). If only a - user is specified but no group, then - the group is derived from the user's - default group. - - - - SocketMode= - If listening on a file - system socket or FIFO, this option - specifies the file system access mode - used when creating the file - node. Takes an access mode in octal - notation. Defaults to - 0666. - - - - DirectoryMode= - If listening on a file - system socket or FIFO, the parent - directories are automatically created - if needed. This option specifies the - file system access mode used when - creating these directories. Takes an - access mode in octal - notation. Defaults to - 0755. - - - - Accept= - Takes a boolean - argument. If true, a service instance - is spawned for each incoming - connection and only the connection - socket is passed to it. If false, all - listening sockets themselves are - passed to the started service unit, - and only one service unit is spawned - for all connections (also see - above). This value is ignored for - datagram sockets and FIFOs where a - single service unit unconditionally - handles all incoming traffic. Defaults - to . For - performance reasons, it is recommended - to write new daemons only in a way - that is suitable for - . A - daemon listening on an AF_UNIX socket - may, but does not need to, call - close2 - on the received socket before - exiting. However, it must not unlink - the socket from a file system. It - should not invoke - shutdown2 - on sockets it got with - Accept=false, but - it may do so for sockets it got with - Accept=true set. - Setting Accept=true - is mostly useful to allow daemons - designed for usage with - inetd8 - to work unmodified with systemd socket - activation. - - - - MaxConnections= - The maximum number of - connections to simultaneously run - services instances for, when - is - set. If more concurrent connections - are coming in, they will be refused - until at least one existing connection - is terminated. This setting has no - effect on sockets configured with - or datagram - sockets. Defaults to - 64. - - - - KeepAlive= - Takes a boolean - argument. If true, the TCP/IP stack - will send a keep alive message after - 2h (depending on the configuration of - /proc/sys/net/ipv4/tcp_keepalive_time) - for all TCP streams accepted on this - socket. This controls the SO_KEEPALIVE - socket option (see - socket7 - and the TCP - Keepalive HOWTO for details.) - Defaults to - . - - - - KeepAliveTimeSec= - Takes time (in seconds) as argument . The connection needs to remain - idle before TCP starts sending keepalive probes. This controls the TCP_KEEPIDLE - socket option (see - socket7 - and the TCP - Keepalive HOWTO for details.) - Defaults value is 7200 seconds (2 hours). - - - - KeepAliveIntervalSec= - Takes time (in seconds) as argument between individual keepalive probes, - if the socket option SO_KEEPALIVE has been set on this socket seconds as argument. - This controls the TCP_KEEPINTVL socket option (see - socket7 - and the TCP - Keepalive HOWTO for details.) - Defaults value is 75 seconds. - - - - KeepAliveProbes= - Takes integer as argument. It's the number of unacknowledged probes to - send before considering the connection dead and notifying the application layer. - This controls the TCP_KEEPCNT socket option (see - socket7 - and the TCP - Keepalive HOWTO for details.) - Defaults value is 9. - - - - NoDelay= - Takes a boolean - argument. TCP Nagle's algorithm works by combining a number of - small outgoing messages, and sending them all at once. - This controls the TCP_NODELAY socket option (see - tcp7 - Defaults to - . - - - - Priority= - Takes an integer - argument controlling the priority for - all traffic sent from this - socket. This controls the SO_PRIORITY - socket option (see - socket7 - for details.). - - - - DeferAcceptSec= - - Takes time (in - seconds) as argument. If set, the - listening process will be awakened - only when data arrives on the socket, - and not immediately when connection is - established. When this option is set, - the - TCP_DEFER_ACCEPT - socket option will be used (see - tcp7), - and the kernel will ignore initial ACK - packets without any data. The argument - specifies the approximate amount of - time the kernel should wait for - incoming data before falling back to - the normal behaviour of honouring - empty ACK packets. This option is - beneficial for protocols where the - client sends the data first (e.g. - HTTP, in contrast to SMTP), because - the server process will not be woken - up unnecessarily before it can take - any action. - - - If the client also uses the - TCP_DEFER_ACCEPT - option, the latency of the initial - connection may be reduced, because the - kernel will send data in the final - packet establishing the connection - (the third packet in the "three-way - handshake"). - - Disabled by default. - - - - - ReceiveBuffer= - SendBuffer= - Takes an integer - argument controlling the receive or - send buffer sizes of this socket, - respectively. This controls the - SO_RCVBUF and SO_SNDBUF socket options - (see - socket7 - for details.). The usual suffixes K, - M, G are supported and are understood - to the base of 1024. - - - - IPTOS= - Takes an integer - argument controlling the IP - Type-Of-Service field for packets - generated from this socket. This - controls the IP_TOS socket option (see - ip7 - for details.). Either a numeric string - or one of , - , - or - may be - specified. - - - - IPTTL= - Takes an integer - argument controlling the IPv4 - Time-To-Live/IPv6 Hop-Count field for - packets generated from this - socket. This sets the - IP_TTL/IPV6_UNICAST_HOPS socket - options (see - ip7 - and - ipv67 - for details.) - - - - Mark= - Takes an integer - value. Controls the firewall mark of - packets generated by this socket. This - can be used in the firewall logic to - filter packets from this socket. This - sets the SO_MARK socket option. See - iptables8 - for details. - - - - ReusePort= - Takes a boolean - value. If true, allows multiple bind2s - to this TCP or UDP port. This - controls the SO_REUSEPORT socket - option. See - socket7 - for details. - - - - SmackLabel= - SmackLabelIPIn= - SmackLabelIPOut= - Takes a string - value. Controls the extended - attributes - security.SMACK64, - security.SMACK64IPIN - and - security.SMACK64IPOUT, - respectively, i.e. the security label - of the FIFO, or the security label for - the incoming or outgoing connections - of the socket, respectively. See - Smack.txt - for details. - - - - SELinuxContextFromNet= - Takes a boolean - argument. When true, systemd will attempt - to figure out the SELinux label used - for the instantiated service from the - information handed by the peer over the - network. Note that only the security - level is used from the information - provided by the peer. Other parts of - the resulting SELinux context originate - from either the target binary that is - effectively triggered by socket unit - or from the value of the - SELinuxContext= - option. This configuration option only - affects sockets with - Accept= mode set to - true. Also note that - this option is useful only when - MLS/MCS SELinux policy is - deployed. Defaults to - false. - - - - - PipeSize= - Takes a size in - bytes. Controls the pipe buffer size - of FIFOs configured in this socket - unit. See - fcntl2 - for details. The usual suffixes K, M, - G are supported and are understood to - the base of 1024. - - - - MessageQueueMaxMessages=, - MessageQueueMessageSize= - These two settings - take integer values and control the - mq_maxmsg field or the mq_msgsize field, respectively, when - creating the message queue. Note that - either none or both of these variables - need to be set. See - mq_setattr3 - for details. - - - - FreeBind= - Takes a boolean - value. Controls whether the socket can - be bound to non-local IP - addresses. This is useful to configure - sockets listening on specific IP - addresses before those IP addresses - are successfully configured on a - network interface. This sets the - IP_FREEBIND socket option. For - robustness reasons it is recommended - to use this option whenever you bind a - socket to a specific IP - address. Defaults to . - - - - Transparent= - Takes a boolean - value. Controls the IP_TRANSPARENT - socket option. Defaults to - . - - - - Broadcast= - Takes a boolean - value. This controls the SO_BROADCAST - socket option, which allows broadcast - datagrams to be sent from this - socket. Defaults to - . - - - - PassCredentials= - Takes a boolean - value. This controls the SO_PASSCRED - socket option, which allows AF_UNIX sockets to - receive the credentials of the sending - process in an ancillary message. - Defaults to - . - - - - PassSecurity= - Takes a boolean - value. This controls the SO_PASSSEC - socket option, which allows AF_UNIX - sockets to receive the security - context of the sending process in an - ancillary message. Defaults to - . - - - - TCPCongestion= - Takes a string - value. Controls the TCP congestion - algorithm used by this socket. Should - be one of "westwood", "veno", "cubic", - "lp" or any other available algorithm - supported by the IP stack. This - setting applies only to stream - sockets. - - - - ExecStartPre= - ExecStartPost= - Takes one or more - command lines, which are executed - before or after the listening - sockets/FIFOs are created and - bound, respectively. The first token of the command - line must be an absolute filename, - then followed by arguments for the - process. Multiple command lines may be - specified following the same scheme as - used for - ExecStartPre= of - service unit files. - - - - ExecStopPre= - ExecStopPost= - Additional commands - that are executed before or after - the listening sockets/FIFOs are closed - and removed, respectively. Multiple command lines - may be specified following the same - scheme as used for - ExecStartPre= of - service unit files. - - - - TimeoutSec= - Configures the time to - wait for the commands specified in - ExecStartPre=, - ExecStartPost=, - ExecStopPre= and - ExecStopPost= to - finish. If a command does not exit - within the configured time, the socket - will be considered failed and be shut - down again. All commands still running - will be terminated forcibly via - SIGTERM, and after another delay of - this time with SIGKILL. (See - in systemd.kill5.) - Takes a unit-less value in seconds, or - a time span value such as "5min - 20s". Pass 0 to disable the timeout - logic. Defaults to DefaultTimeoutStartSec= from the - manager configuration file - (see systemd-system.conf5). - - - - - Service= - Specifies the service - unit name to activate on incoming - traffic. This setting is only allowed - for sockets with - Accept=no. It - defaults to the service that bears the - same name as the socket (with the - suffix replaced). In most cases, it - should not be necessary to use this - option. - - - - RemoveOnStop= - Takes a boolean - argument. If enabled, any file nodes - created by this socket unit are - removed when it is stopped. This - applies to AF_UNIX sockets in the file - system, POSIX message queues, FIFOs, - as well as any symlinks to - them configured with - Symlinks=. Normally, - it should not be necessary to use this - option, and is not recommended as - services might continue to run after - the socket unit has been terminated - and it should still be possible to - communicate with them via their file - system node. Defaults to - off. - - - - Symlinks= - Takes a list of file - system paths. The specified paths will - be created as symlinks to the AF_UNIX - socket path or FIFO path of this - socket unit. If this setting is used, - only one AF_UNIX socket in the file - system or one FIFO may be configured - for the socket unit. Use this option - to manage one or more symlinked alias - names for a socket, binding their - lifecycle together. Defaults to the - empty list. - - - - - Check - systemd.exec5 - and - systemd.kill5 - for more settings. - - - - - See Also - - systemd1, - systemctl1, - systemd.unit5, - systemd.exec5, - systemd.kill5, - systemd.resource-control5, - systemd.service5, - systemd.directives7 - - - - For more extensive descriptions see the "systemd for Developers" series: - Socket Activation, - Socket Activation, part II, - Converting inetd Services, - Socket Activated Internet Services and OS Containers. - - + + systemd.socket + systemd + + + + Developer + Lennart + Poettering + lennart@poettering.net + + + + + + systemd.socket + 5 + + + + systemd.socket + Socket unit configuration + + + + socket.socket + + + + Description + + A unit configuration file whose name ends in + .socket encodes information about an IPC or + network socket or a file system FIFO controlled and supervised by + systemd, for socket-based activation. + + This man page lists the configuration options specific to + this unit type. See + systemd.unit5 + for the common options of all unit configuration files. The common + configuration items are configured in the generic [Unit] and + [Install] sections. The socket specific configuration options are + configured in the [Socket] section. + + Additional options are listed in + systemd.exec5, + which define the execution environment the + , , + and + commands are executed in, and in + systemd.kill5, + which define the way the processes are terminated, and in + systemd.resource-control5, + which configure resource control settings for the processes of the + socket. + + For each socket file, a matching service file must exist, + describing the service to start on incoming traffic on the socket + (see + systemd.service5 + for more information about .service files). The name of the + .service unit is by default the same as the name of the .socket + unit, but can be altered with the option + described below. Depending on the setting of the + option described below, this .service + unit must either be named like the .socket unit, but with the + suffix replaced, unless overridden with ; + or it must be a template unit named the same way. Example: a + socket file foo.socket needs a matching + service foo.service if + is set. If + is set, a service template file + foo@.service must exist from which services + are instantiated for each incoming connection. + + Unless DefaultDependencies= is set to + , socket units will implicitly have + dependencies of type Requires= and + After= on sysinit.target + as well as dependencies of type Conflicts= and + Before= on + shutdown.target. These ensure that socket + units pull in basic system initialization, and are terminated + cleanly prior to system shutdown. Only sockets involved with early + boot or late system shutdown should disable this option. + + Socket units will have a Before= + dependency on the service which they trigger added implicitly. No + implicit WantedBy= or + RequiredBy= dependency from the socket to the + service is added. This means that the service may be started + without the socket, in which case it must be able to open sockets + by itself. To prevent this, an explicit + Requires= dependency may be added. + + Socket units may be used to implement on-demand starting of + services, as well as parallelized starting of services. See the + blog stories linked at the end for an introduction. + + Note that the daemon software configured for socket + activation with socket units needs to be able to accept sockets + from systemd, either via systemd's native socket passing interface + (see + sd_listen_fds3 + for details) or via the traditional + inetd8-style + socket passing (i.e. sockets passed in via standard input and + output, using StandardInput=socket in the + service file). + + + + Options + + Socket files must include a [Socket] section, which carries + information about the socket or FIFO it supervises. A number of + options that may be used in this section are shared with other + unit types. These options are documented in + systemd.exec5 + and + systemd.kill5. + The options specific to the [Socket] section of socket units are + the following: + + + + ListenStream= + ListenDatagram= + ListenSequentialPacket= + Specifies an address to listen on for a stream + (SOCK_STREAM), datagram + (SOCK_DGRAM), or sequential packet + (SOCK_SEQPACKET) socket, respectively. + The address can be written in various formats: + + If the address starts with a slash + (/), it is read as file system socket in + the AF_UNIX socket family. + + If the address starts with an at symbol + (@), it is read as abstract namespace + socket in the AF_UNIX family. The + @ is replaced with a + NUL character before binding. For + details, see + unix7. + + If the address string is a single number, it is read as + port number to listen on via IPv6. Depending on the value of + BindIPv6Only= (see below) this might result + in the service being available via both IPv6 and IPv4 + (default) or just via IPv6. + + + If the address string is a string in the format + v.w.x.y:z, it is read as IPv4 specifier for listening on an + address v.w.x.y on a port z. + + If the address string is a string in the format [x]:y, + it is read as IPv6 address x on a port y. Note that this might + make the service available via IPv4, too, depending on the + BindIPv6Only= setting (see below). + + + Note that SOCK_SEQPACKET (i.e. + ListenSequentialPacket=) is only available + for AF_UNIX sockets. + SOCK_STREAM (i.e. + ListenStream=) when used for IP sockets + refers to TCP sockets, SOCK_DGRAM (i.e. + ListenDatagram=) to UDP. + + These options may be specified more than once in which + case incoming traffic on any of the sockets will trigger + service activation, and all listed sockets will be passed to + the service, regardless of whether there is incoming traffic + on them or not. If the empty string is assigned to any of + these options, the list of addresses to listen on is reset, + all prior uses of any of these options will have no + effect. + + It is also possible to have more than one socket unit + for the same service when using Service=, + and the service will receive all the sockets configured in all + the socket units. Sockets configured in one unit are passed in + the order of configuration, but no ordering between socket + units is specified. + + If an IP address is used here, it is often desirable to + listen on it before the interface it is configured on is up + and running, and even regardless of whether it will be up and + running at any point. To deal with this, it is recommended to + set the FreeBind= option described + below. + + + + ListenFIFO= + Specifies a file system FIFO to listen on. + This expects an absolute file system path as argument. + Behavior otherwise is very similar to the + ListenDatagram= directive + above. + + + + ListenSpecial= + Specifies a special file in the file system to + listen on. This expects an absolute file system path as + argument. Behavior otherwise is very similar to the + ListenFIFO= directive above. Use this to + open character device nodes as well as special files in + /proc and + /sys. + + + + ListenNetlink= + Specifies a Netlink family to create a socket + for to listen on. This expects a short string referring to the + AF_NETLINK family name (such as + audit or kobject-uevent) + as argument, optionally suffixed by a whitespace followed by a + multicast group integer. Behavior otherwise is very similar to + the ListenDatagram= directive + above. + + + + ListenMessageQueue= + Specifies a POSIX message queue name to listen + on. This expects a valid message queue name (i.e. beginning + with /). Behavior otherwise is very similar to the + ListenFIFO= directive above. On Linux + message queue descriptors are actually file descriptors and + can be inherited between processes. + + + + BindIPv6Only= + Takes a one of , + or . Controls + the IPV6_V6ONLY socket option (see + ipv67 + for details). If , IPv6 sockets bound + will be accessible via both IPv4 and IPv6. If + , they will be accessible via IPv6 + only. If (which is the default, + surprise!), the system wide default setting is used, as + controlled by + /proc/sys/net/ipv6/bindv6only, which in + turn defaults to the equivalent of + . + + + + + Backlog= + Takes an unsigned integer argument. Specifies + the number of connections to queue that have not been accepted + yet. This setting matters only for stream and sequential + packet sockets. See + listen2 + for details. Defaults to SOMAXCONN (128). + + + + BindToDevice= + Specifies a network interface name to bind + this socket to. If set, traffic will only be accepted from the + specified network interfaces. This controls the + SO_BINDTODEVICE socket option (see + socket7 + for details). If this option is used, an automatic dependency + from this socket unit on the network interface device unit + (systemd.device5 + is created. + + + + SocketUser= + SocketGroup= + + Takes a UNIX user/group name. When specified, + all AF_UNIX sockets and FIFO nodes in the file system are + owned by the specified user and group. If unset (the default), + the nodes are owned by the root user/group (if run in system + context) or the invoking user/group (if run in user context). + If only a user is specified but no group, then the group is + derived from the user's default group. + + + + SocketMode= + If listening on a file system socket or FIFO, + this option specifies the file system access mode used when + creating the file node. Takes an access mode in octal + notation. Defaults to 0666. + + + + DirectoryMode= + If listening on a file system socket or FIFO, + the parent directories are automatically created if needed. + This option specifies the file system access mode used when + creating these directories. Takes an access mode in octal + notation. Defaults to 0755. + + + + Accept= + Takes a boolean argument. If true, a service + instance is spawned for each incoming connection and only the + connection socket is passed to it. If false, all listening + sockets themselves are passed to the started service unit, and + only one service unit is spawned for all connections (also see + above). This value is ignored for datagram sockets and FIFOs + where a single service unit unconditionally handles all + incoming traffic. Defaults to . For + performance reasons, it is recommended to write new daemons + only in a way that is suitable for + . A daemon listening on an + AF_UNIX socket may, but does not need to, + call + close2 + on the received socket before exiting. However, it must not + unlink the socket from a file system. It should not invoke + shutdown2 + on sockets it got with Accept=false, but it + may do so for sockets it got with + Accept=true set. Setting + Accept=true is mostly useful to allow + daemons designed for usage with + inetd8 + to work unmodified with systemd socket + activation. + + + + MaxConnections= + The maximum number of connections to + simultaneously run services instances for, when + is set. If more concurrent + connections are coming in, they will be refused until at least + one existing connection is terminated. This setting has no + effect on sockets configured with + or datagram sockets. Defaults to + 64. + + + + KeepAlive= + Takes a boolean argument. If true, the TCP/IP + stack will send a keep alive message after 2h (depending on + the configuration of + /proc/sys/net/ipv4/tcp_keepalive_time) + for all TCP streams accepted on this socket. This controls the + SO_KEEPALIVE socket option (see + socket7 + and the TCP + Keepalive HOWTO for details.) Defaults to + . + + + + KeepAliveTimeSec= + Takes time (in seconds) as argument . The connection needs to remain + idle before TCP starts sending keepalive probes. This controls the TCP_KEEPIDLE + socket option (see + socket7 + and the TCP + Keepalive HOWTO for details.) + Defaults value is 7200 seconds (2 hours). + + + + KeepAliveIntervalSec= + Takes time (in seconds) as argument between + individual keepalive probes, if the socket option SO_KEEPALIVE + has been set on this socket seconds as argument. This controls + the TCP_KEEPINTVL socket option (see + socket7 + and the TCP + Keepalive HOWTO for details.) Defaults value is 75 + seconds. + + + + KeepAliveProbes= + Takes integer as argument. It's the number of + unacknowledged probes to send before considering the + connection dead and notifying the application layer. This + controls the TCP_KEEPCNT socket option (see + socket7 + and the TCP + Keepalive HOWTO for details.) Defaults value is + 9. + + + + NoDelay= + Takes a boolean argument. TCP Nagle's + algorithm works by combining a number of small outgoing + messages, and sending them all at once. This controls the + TCP_NODELAY socket option (see + tcp7 + Defaults to . + + + + Priority= + Takes an integer argument controlling the + priority for all traffic sent from this socket. This controls + the SO_PRIORITY socket option (see + socket7 + for details.). + + + + DeferAcceptSec= + + Takes time (in seconds) as argument. If set, + the listening process will be awakened only when data arrives + on the socket, and not immediately when connection is + established. When this option is set, the + TCP_DEFER_ACCEPT socket option will be + used (see + tcp7), + and the kernel will ignore initial ACK packets without any + data. The argument specifies the approximate amount of time + the kernel should wait for incoming data before falling back + to the normal behaviour of honouring empty ACK packets. This + option is beneficial for protocols where the client sends the + data first (e.g. HTTP, in contrast to SMTP), because the + server process will not be woken up unnecessarily before it + can take any action. + + + If the client also uses the + TCP_DEFER_ACCEPT option, the latency of + the initial connection may be reduced, because the kernel will + send data in the final packet establishing the connection (the + third packet in the "three-way handshake"). + + Disabled by default. + + + + + ReceiveBuffer= + SendBuffer= + Takes an integer argument controlling the + receive or send buffer sizes of this socket, respectively. + This controls the SO_RCVBUF and SO_SNDBUF socket options (see + socket7 + for details.). The usual suffixes K, M, G are supported and + are understood to the base of 1024. + + + + IPTOS= + Takes an integer argument controlling the IP + Type-Of-Service field for packets generated from this socket. + This controls the IP_TOS socket option (see + ip7 + for details.). Either a numeric string or one of + , , + or may + be specified. + + + + IPTTL= + Takes an integer argument controlling the IPv4 + Time-To-Live/IPv6 Hop-Count field for packets generated from + this socket. This sets the IP_TTL/IPV6_UNICAST_HOPS socket + options (see + ip7 + and + ipv67 + for details.) + + + + Mark= + Takes an integer value. Controls the firewall + mark of packets generated by this socket. This can be used in + the firewall logic to filter packets from this socket. This + sets the SO_MARK socket option. See + iptables8 + for details. + + + + ReusePort= + Takes a boolean value. If true, allows + multiple + bind2s + to this TCP or UDP port. This controls the SO_REUSEPORT socket + option. See + socket7 + for details. + + + + SmackLabel= + SmackLabelIPIn= + SmackLabelIPOut= + Takes a string value. Controls the extended + attributes security.SMACK64, + security.SMACK64IPIN and + security.SMACK64IPOUT, respectively, i.e. + the security label of the FIFO, or the security label for the + incoming or outgoing connections of the socket, respectively. + See Smack.txt + for details. + + + + SELinuxContextFromNet= + Takes a boolean argument. When true, systemd + will attempt to figure out the SELinux label used for the + instantiated service from the information handed by the peer + over the network. Note that only the security level is used + from the information provided by the peer. Other parts of the + resulting SELinux context originate from either the target + binary that is effectively triggered by socket unit or from + the value of the SELinuxContext= option. + This configuration option only affects sockets with + Accept= mode set to + true. Also note that this option is useful + only when MLS/MCS SELinux policy is deployed. Defaults to + false. + + + + PipeSize= + Takes a size in bytes. Controls the pipe + buffer size of FIFOs configured in this socket unit. See + fcntl2 + for details. The usual suffixes K, M, G are supported and are + understood to the base of 1024. + + + + MessageQueueMaxMessages=, + MessageQueueMessageSize= + These two settings take integer values and + control the mq_maxmsg field or the mq_msgsize field, + respectively, when creating the message queue. Note that + either none or both of these variables need to be set. See + mq_setattr3 + for details. + + + + FreeBind= + Takes a boolean value. Controls whether the + socket can be bound to non-local IP addresses. This is useful + to configure sockets listening on specific IP addresses before + those IP addresses are successfully configured on a network + interface. This sets the IP_FREEBIND socket option. For + robustness reasons it is recommended to use this option + whenever you bind a socket to a specific IP address. Defaults + to . + + + + Transparent= + Takes a boolean value. Controls the + IP_TRANSPARENT socket option. Defaults to + . + + + + Broadcast= + Takes a boolean value. This controls the + SO_BROADCAST socket option, which allows broadcast datagrams + to be sent from this socket. Defaults to + . + + + + PassCredentials= + Takes a boolean value. This controls the + SO_PASSCRED socket option, which allows + AF_UNIX sockets to receive the + credentials of the sending process in an ancillary message. + Defaults to . + + + + PassSecurity= + Takes a boolean value. This controls the + SO_PASSSEC socket option, which allows + AF_UNIX sockets to receive the security + context of the sending process in an ancillary message. + Defaults to . + + + + TCPCongestion= + Takes a string value. Controls the TCP + congestion algorithm used by this socket. Should be one of + "westwood", "veno", "cubic", "lp" or any other available + algorithm supported by the IP stack. This setting applies only + to stream sockets. + + + + ExecStartPre= + ExecStartPost= + Takes one or more command lines, which are + executed before or after the listening sockets/FIFOs are + created and bound, respectively. The first token of the + command line must be an absolute filename, then followed by + arguments for the process. Multiple command lines may be + specified following the same scheme as used for + ExecStartPre= of service unit + files. + + + + ExecStopPre= + ExecStopPost= + Additional commands that are executed before + or after the listening sockets/FIFOs are closed and removed, + respectively. Multiple command lines may be specified + following the same scheme as used for + ExecStartPre= of service unit + files. + + + + TimeoutSec= + Configures the time to wait for the commands + specified in ExecStartPre=, + ExecStartPost=, + ExecStopPre= and + ExecStopPost= to finish. If a command does + not exit within the configured time, the socket will be + considered failed and be shut down again. All commands still + running will be terminated forcibly via + SIGTERM, and after another delay of this + time with SIGKILL. (See + in + systemd.kill5.) + Takes a unit-less value in seconds, or a time span value such + as "5min 20s". Pass 0 to disable the + timeout logic. Defaults to + DefaultTimeoutStartSec= from the manager + configuration file (see + systemd-system.conf5). + + + + + Service= + Specifies the service unit name to activate on + incoming traffic. This setting is only allowed for sockets + with Accept=no. It defaults to the service + that bears the same name as the socket (with the suffix + replaced). In most cases, it should not be necessary to use + this option. + + + + RemoveOnStop= + Takes a boolean argument. If enabled, any file + nodes created by this socket unit are removed when it is + stopped. This applies to AF_UNIX sockets in the file system, + POSIX message queues, FIFOs, as well as any symlinks to them + configured with Symlinks=. Normally, it + should not be necessary to use this option, and is not + recommended as services might continue to run after the socket + unit has been terminated and it should still be possible to + communicate with them via their file system node. Defaults to + off. + + + + Symlinks= + Takes a list of file system paths. The + specified paths will be created as symlinks to the AF_UNIX + socket path or FIFO path of this socket unit. If this setting + is used, only one AF_UNIX socket in the file system or one + FIFO may be configured for the socket unit. Use this option to + manage one or more symlinked alias names for a socket, binding + their lifecycle together. Defaults to the empty + list. + + + + + Check + systemd.exec5 + and + systemd.kill5 + for more settings. + + + + + See Also + + systemd1, + systemctl1, + systemd.unit5, + systemd.exec5, + systemd.kill5, + systemd.resource-control5, + systemd.service5, + systemd.directives7 + + + + For more extensive descriptions see the "systemd for Developers" series: + Socket Activation, + Socket Activation, part II, + Converting inetd Services, + Socket Activated Internet Services and OS Containers. + + diff --git a/man/systemd.special.xml b/man/systemd.special.xml index 863d7f35d92..cf76aaf607e 100644 --- a/man/systemd.special.xml +++ b/man/systemd.special.xml @@ -1,6 +1,6 @@ + "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd"> + "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd"> - - systemd.swap - systemd - - - - Developer - Lennart - Poettering - lennart@poettering.net - - - - - - systemd.swap - 5 - - - - systemd.swap - Swap unit configuration - - - - swap.swap - - - - Description - - A unit configuration file whose name ends in - .swap encodes information about a - swap device or file for memory paging controlled and - supervised by systemd. - - This man page lists the configuration options - specific to this unit type. See - systemd.unit5 - for the common options of all unit configuration - files. The common configuration items are configured - in the generic [Unit] and [Install] sections. The swap - specific configuration options are configured in the - [Swap] section. - - Additional options are listed in - systemd.exec5, - which define the execution environment the - swapon8 - binary is executed in, and in - systemd.kill5, - which define the way the processes are - terminated, and in - systemd.resource-control5, - which configure resource control settings for the - processes of the service. - - Swap units must be named after the devices - or files they control. Example: the swap device - /dev/sda5 must be configured in a - unit file dev-sda5.swap. For - details about the escaping logic used to convert a - file system path to a unit name, see - systemd.unit5. - - All swap units automatically get the appropriate - dependencies on the devices or on the mount points - of the files they are activated from. - - Swap units with - DefaultDependencies= enabled - implicitly acquire a conflicting dependency to - umount.target so that they are - deactivated at shutdown. - - - - <filename>fstab</filename> - - Swap units may either be configured via unit - files, or via /etc/fstab (see - fstab5 - for details). Swaps listed in - /etc/fstab will be converted into - native units dynamically at boot and when the - configuration of the system manager is - reloaded. See - systemd-fstab-generator8 - for details about the conversion. - - If a swap device or file is configured in both - /etc/fstab and a unit file, the - configuration in the latter takes precedence. - - When reading /etc/fstab a - few special options are understood by systemd which - influence how dependencies are created for swap - units. - - - - - - - With the - swap unit will not be added as a dependency for - swap.target. This means that - it will not be activated automatically during - boot, unless it is pulled in by some other - unit. Option has the - opposite meaning and is the default. - - - - - - - With the - swap unit will be only wanted, not required by - swap.target. This means that - the boot will continue even if this swap device is - not activated successfully. - - - - - - - Options - - Swap files must include a [Swap] section, which - carries information about the swap device it - supervises. A number of options that may be used in - this section are shared with other unit types. These - options are documented in - systemd.exec5 - and - systemd.kill5. The - options specific to the [Swap] section of swap units - are the following: - - - - - What= - Takes an absolute path - of a device node or file to use for - paging. See - swapon8 - for details. If this refers to a - device node, a dependency on the - respective device unit is - automatically created. (See - systemd.device5 - for more information.) If this refers - to a file, a dependency on the - respective mount unit is automatically - created. (See - systemd.mount5 - for more information.) This option is - mandatory. - - - - Priority= - - Swap priority to use - when activating the swap device or - file. This takes an integer. This - setting is optional. - - - - Options= - - May contain an option - string for the swap device. This may - be used for controlling discard - options among other functionality, if - the swap backing device supports the - discard or trim operation. (See - swapon8 - for more information.) - - - - - TimeoutSec= - Configures the time to - wait for the swapon command to - finish. If a command does not exit - within the configured time, the swap - will be considered failed and be shut - down again. All commands still running - will be terminated forcibly via - SIGTERM, and after another delay of - this time with SIGKILL. (See - in - systemd.kill5.) - Takes a unit-less value in seconds, or - a time span value such as "5min - 20s". Pass 0 to disable the timeout - logic. Defaults to DefaultTimeoutStartSec= from the - manager configuration file - (see systemd-system.conf5). - - - - - Check - systemd.exec5 - and - systemd.kill5 - for more settings. - - - - See Also - - systemd1, - systemctl1, - systemd.unit5, - systemd.exec5, - systemd.kill5, - systemd.resource-control5, - systemd.device5, - systemd.mount5, - swapon8, - systemd-fstab-generator8, - systemd.directives7 - - + + systemd.swap + systemd + + + + Developer + Lennart + Poettering + lennart@poettering.net + + + + + + systemd.swap + 5 + + + + systemd.swap + Swap unit configuration + + + + swap.swap + + + + Description + + A unit configuration file whose name ends in + .swap encodes information about a swap device + or file for memory paging controlled and supervised by + systemd. + + This man page lists the configuration options specific to + this unit type. See + systemd.unit5 + for the common options of all unit configuration files. The common + configuration items are configured in the generic [Unit] and + [Install] sections. The swap specific configuration options are + configured in the [Swap] section. + + Additional options are listed in + systemd.exec5, + which define the execution environment the + swapon8 + binary is executed in, and in + systemd.kill5, + which define the way the processes are terminated, and in + systemd.resource-control5, + which configure resource control settings for the processes of the + service. + + Swap units must be named after the devices + or files they control. Example: the swap device + /dev/sda5 must be configured in a + unit file dev-sda5.swap. For details about + the escaping logic used to convert a file system path to a unit + name, see + systemd.unit5. + + All swap units automatically get the appropriate + dependencies on the devices or on the mount points of the files + they are activated from. + + Swap units with DefaultDependencies= + enabled implicitly acquire a conflicting dependency to + umount.target so that they are deactivated at + shutdown. + + + + <filename>fstab</filename> + + Swap units may either be configured via unit files, or via + /etc/fstab (see + fstab5 + for details). Swaps listed in /etc/fstab will + be converted into native units dynamically at boot and when the + configuration of the system manager is reloaded. See + systemd-fstab-generator8 + for details about the conversion. + + If a swap device or file is configured in both + /etc/fstab and a unit file, the configuration + in the latter takes precedence. + + When reading /etc/fstab a few special + options are understood by systemd which influence how dependencies + are created for swap units. + + + + + + + With the swap unit + will not be added as a dependency for + swap.target. This means that it will not + be activated automatically during boot, unless it is pulled in + by some other unit. Option has the + opposite meaning and is the default. + + + + + + + With the swap unit + will be only wanted, not required by + swap.target. This means that the boot + will continue even if this swap device is not activated + successfully. + + + + + + + Options + + Swap files must include a [Swap] section, which carries + information about the swap device it supervises. A number of + options that may be used in this section are shared with other + unit types. These options are documented in + systemd.exec5 + and + systemd.kill5. + The options specific to the [Swap] section of swap units are the + following: + + + + + What= + Takes an absolute path of a device node or + file to use for paging. See + swapon8 + for details. If this refers to a device node, a dependency on + the respective device unit is automatically created. (See + systemd.device5 + for more information.) If this refers to a file, a dependency + on the respective mount unit is automatically created. (See + systemd.mount5 + for more information.) This option is + mandatory. + + + + Priority= + + Swap priority to use when activating the swap + device or file. This takes an integer. This setting is + optional. + + + + Options= + + May contain an option string for the swap + device. This may be used for controlling discard options among + other functionality, if the swap backing device supports the + discard or trim operation. (See + swapon8 + for more information.) + + + + TimeoutSec= + Configures the time to wait for the swapon + command to finish. If a command does not exit within the + configured time, the swap will be considered failed and be + shut down again. All commands still running will be terminated + forcibly via SIGTERM, and after another + delay of this time with SIGKILL. (See + in + systemd.kill5.) + Takes a unit-less value in seconds, or a time span value such + as "5min 20s". Pass 0 to disable the + timeout logic. Defaults to + DefaultTimeoutStartSec= from the manager + configuration file (see + systemd-system.conf5). + + + + + Check + systemd.exec5 + and + systemd.kill5 + for more settings. + + + + See Also + + systemd1, + systemctl1, + systemd.unit5, + systemd.exec5, + systemd.kill5, + systemd.resource-control5, + systemd.device5, + systemd.mount5, + swapon8, + systemd-fstab-generator8, + systemd.directives7 + + diff --git a/man/systemd.target.xml b/man/systemd.target.xml index e2cdfd83c30..3b8ec165e2c 100644 --- a/man/systemd.target.xml +++ b/man/systemd.target.xml @@ -1,7 +1,7 @@ + "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd"> - - systemd.target - systemd - - - - Developer - Lennart - Poettering - lennart@poettering.net - - - - - - systemd.target - 5 - - - - systemd.target - Target unit configuration - - - - target.target - - - - Description - - A unit configuration file whose name ends in - .target encodes information about - a target unit of systemd, which is used for grouping - units and as well-known synchronization points during - start-up. - - This unit type has no specific options. See - systemd.unit5 - for the common options of all unit configuration - files. The common configuration items are configured - in the generic [Unit] and [Install] sections. A - separate [Target] section does not exist, since no - target-specific options may be configured. - - Target units do not offer any additional - functionality on top of the generic functionality - provided by units. They exist merely to group units via dependencies - (useful as boot targets), and to establish - standardized names for synchronization points used in - dependencies between units. Among other things, target - units are a more flexible replacement for SysV - runlevels in the classic SysV init system. (And for - compatibility reasons special - target units such as - runlevel3.target exist which are used by - the SysV runlevel compatibility code in systemd. See - systemd.special7 - for details). - - Unless DefaultDependencies= - is set to , target units will - implicitly complement all configured dependencies of - type Wants=, - Requires=, - RequiresOverridable= with - dependencies of type After= if the - units in question also have - DefaultDependencies=true. - - - - - See Also - - systemd1, - systemctl1, - systemd.unit5, - systemd.special7, - systemd.directives7 - - + + systemd.target + systemd + + + + Developer + Lennart + Poettering + lennart@poettering.net + + + + + + systemd.target + 5 + + + + systemd.target + Target unit configuration + + + + target.target + + + + Description + + A unit configuration file whose name ends in + .target encodes information about a target unit + of systemd, which is used for grouping units and as well-known + synchronization points during start-up. + + This unit type has no specific options. See + systemd.unit5 + for the common options of all unit configuration files. The common + configuration items are configured in the generic [Unit] and + [Install] sections. A separate [Target] section does not exist, + since no target-specific options may be configured. + + Target units do not offer any additional functionality on + top of the generic functionality provided by units. They exist + merely to group units via dependencies (useful as boot targets), + and to establish standardized names for synchronization points + used in dependencies between units. Among other things, target + units are a more flexible replacement for SysV runlevels in the + classic SysV init system. (And for compatibility reasons special + target units such as runlevel3.target exist + which are used by the SysV runlevel compatibility code in systemd. + See + systemd.special7 + for details). + + Unless DefaultDependencies= is set to + , target units will implicitly complement + all configured dependencies of type Wants=, + Requires=, + RequiresOverridable= with dependencies of type + After= if the units in question also have + DefaultDependencies=true. + + + + + See Also + + systemd1, + systemctl1, + systemd.unit5, + systemd.special7, + systemd.directives7 + + diff --git a/man/systemd.time.xml b/man/systemd.time.xml index 2e64089c295..da0729725d1 100644 --- a/man/systemd.time.xml +++ b/man/systemd.time.xml @@ -1,6 +1,6 @@ + "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd"> + "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd"> - - systemd.timer - systemd - - - - Developer - Lennart - Poettering - lennart@poettering.net - - - - - - systemd.timer - 5 - - - - systemd.timer - Timer unit configuration - - - - timer.timer - - - - Description - - A unit configuration file whose name ends in - .timer encodes information about - a timer controlled and supervised by systemd, for - timer-based activation. - - This man page lists the configuration options - specific to this unit type. See - systemd.unit5 - for the common options of all unit configuration - files. The common configuration items are configured - in the generic [Unit] and [Install] sections. The - timer specific configuration options are configured in - the [Timer] section. - - For each timer file, a matching unit file must - exist, describing the unit to activate when the timer - elapses. By default, a service by the same name as the - timer (except for the suffix) is activated. Example: a - timer file foo.timer activates a - matching service foo.service. The - unit to activate may be controlled by - Unit= (see below). - - Unless DefaultDependencies= - is set to , all timer units will - implicitly have dependencies of type - Conflicts= and - Before= on - shutdown.target to ensure that - they are stopped cleanly prior to system shutdown. - Timer units with at least one - OnCalendar= directive will have an - additional After= dependency on - timer-sync.target to avoid - being started before the system clock has been - correctly set. Only timer units involved with early - boot or late system shutdown should disable the - DefaultDependencies= option. - - - - Options - - Timer files must include a [Timer] section, - which carries information about the timer it - defines. The options specific to the [Timer] section - of timer units are the following: - - - - OnActiveSec= - OnBootSec= - OnStartupSec= - OnUnitActiveSec= - OnUnitInactiveSec= - - Defines monotonic timers - relative to different starting points: - OnActiveSec= defines a - timer relative to the moment the timer - itself is - activated. OnBootSec= - defines a timer relative to when the - machine was booted - up. OnStartupSec= - defines a timer relative to when - systemd was first - started. OnUnitActiveSec= - defines a timer relative to when the - unit the timer is activating was last - activated. OnUnitInactiveSec= - defines a timer relative to when the - unit the timer is activating was last - deactivated. - - Multiple directives may be - combined of the same and of different - types. For example, by combining - OnBootSec= and - OnUnitActiveSec=, it is - possible to define a timer that - elapses in regular intervals and - activates a specific service each - time. - - The arguments to the directives - are time spans configured in - seconds. Example: "OnBootSec=50" means - 50s after boot-up. The argument may - also include time units. Example: - "OnBootSec=5h 30min" means 5 hours and - 30 minutes after boot-up. For details - about the syntax of time spans, see - systemd.unit5. - - If a timer configured with - OnBootSec= or - OnStartupSec= is - already in the past when the timer - unit is activated, it will immediately - elapse and the configured unit is - started. This is not the case for - timers defined in the other - directives. - - These are monotonic timers, - independent of wall-clock time and timezones. If the - computer is temporarily suspended, the - monotonic clock stops too. - - If the empty string is assigned - to any of these options, the list of - timers is reset, and all prior - assignments will have no - effect. - - Note that timers do not - necessarily expire at the precise - time configured with these settings, - as they are subject to the - AccuracySec= - setting below. - - - - - OnCalendar= - - Defines realtime - (i.e. wallclock) timers with calendar - event expressions. See - systemd.time7 - for more information on the syntax of - calendar event expressions. Otherwise, - the semantics are similar to - OnActiveSec= and - related settings. - - Note that timers do not - necessarily expire at the precise - time configured with this setting, - as it is subject to the - AccuracySec= - setting below. - - - - AccuracySec= - - Specify the accuracy - the timer shall elapse with. Defaults - to 1min. The timer is scheduled to - elapse within a time window starting - with the time specified in - OnCalendar=, - OnActiveSec=, - OnBootSec=, - OnStartupSec=, - OnUnitActiveSec= or - OnUnitInactiveSec= - and ending the time configured with - AccuracySec= - later. Within this time window, the - expiry time will be placed at a - host-specific, randomized but stable - position that is synchronized between - all local timer units. This is done in - order to distribute the wake-up time - in networked installations, as well as - optimizing power consumption to - suppress unnecessary CPU wake-ups. To - get best accuracy, set this option to - 1us. Note that the timer is still - subject to the timer slack configured - via - systemd-system.conf5's - TimerSlackNSec= - setting. See - prctl2 - for details. To optimize power - consumption, make sure to set this - value as high as possible and as low - as necessary. - - - Unit= - - The unit to activate - when this timer elapses. The argument is a - unit name, whose suffix is not - .timer. If not - specified, this value defaults to a - service that has the same name as the - timer unit, except for the - suffix. (See above.) It is recommended - that the unit name that is activated - and the unit name of the timer unit - are named identically, except for the - suffix. - - - - - Persistent= - - Takes a boolean - argument. If true, the time when the - service unit was last triggered is - stored on disk. When the timer is - activated, the service unit is - triggered immediately if it would have - been triggered at least once during - the time when the timer was inactive. - This is useful to catch up on missed - runs of the service when the machine - was off. Note that this setting only - has an effect on timers configured - with OnCalendar=. - - - - - WakeSystem= - - Takes a boolean - argument. If true, an elapsing timer - will cause the system to resume from - suspend, should it be suspended and if - the system supports this. Note that - this option will only make sure the - system resumes on the appropriate - times, it will not take care of - suspending it again after any work - that is to be done is - finished. Defaults to - false. - - - - - - See Also - - systemd1, - systemctl1, - systemd.unit5, - systemd.service5, - systemd.time7, - systemd.directives7, - systemd-system.conf5, - prctl2 - - + + systemd.timer + systemd + + + + Developer + Lennart + Poettering + lennart@poettering.net + + + + + + systemd.timer + 5 + + + + systemd.timer + Timer unit configuration + + + + timer.timer + + + + Description + + A unit configuration file whose name ends in + .timer encodes information about a timer + controlled and supervised by systemd, for timer-based + activation. + + This man page lists the configuration options specific to + this unit type. See + systemd.unit5 + for the common options of all unit configuration files. The common + configuration items are configured in the generic [Unit] and + [Install] sections. The timer specific configuration options are + configured in the [Timer] section. + + For each timer file, a matching unit file must exist, + describing the unit to activate when the timer elapses. By + default, a service by the same name as the timer (except for the + suffix) is activated. Example: a timer file + foo.timer activates a matching service + foo.service. The unit to activate may be + controlled by Unit= (see below). + + Unless DefaultDependencies= is set to + , all timer units will implicitly have + dependencies of type Conflicts= and + Before= on shutdown.target + to ensure that they are stopped cleanly prior to system shutdown. + Timer units with at least one OnCalendar= + directive will have an additional After= + dependency on timer-sync.target to avoid + being started before the system clock has been correctly set. Only + timer units involved with early boot or late system shutdown + should disable the DefaultDependencies= + option. + + + + Options + + Timer files must include a [Timer] section, which carries + information about the timer it defines. The options specific to + the [Timer] section of timer units are the following: + + + + OnActiveSec= + OnBootSec= + OnStartupSec= + OnUnitActiveSec= + OnUnitInactiveSec= + + Defines monotonic timers relative to different + starting points: OnActiveSec= defines a + timer relative to the moment the timer itself is activated. + OnBootSec= defines a timer relative to when + the machine was booted up. OnStartupSec= + defines a timer relative to when systemd was first started. + OnUnitActiveSec= defines a timer relative + to when the unit the timer is activating was last activated. + OnUnitInactiveSec= defines a timer relative + to when the unit the timer is activating was last + deactivated. + + Multiple directives may be combined of the same and of + different types. For example, by combining + OnBootSec= and + OnUnitActiveSec=, it is possible to define + a timer that elapses in regular intervals and activates a + specific service each time. + + The arguments to the directives are time spans + configured in seconds. Example: "OnBootSec=50" means 50s after + boot-up. The argument may also include time units. Example: + "OnBootSec=5h 30min" means 5 hours and 30 minutes after + boot-up. For details about the syntax of time spans, see + systemd.unit5. + + If a timer configured with OnBootSec= + or OnStartupSec= is already in the past + when the timer unit is activated, it will immediately elapse + and the configured unit is started. This is not the case for + timers defined in the other directives. + + These are monotonic timers, independent of wall-clock + time and timezones. If the computer is temporarily suspended, + the monotonic clock stops too. + + If the empty string is assigned to any of these options, + the list of timers is reset, and all prior assignments will + have no effect. + + Note that timers do not necessarily expire at the + precise time configured with these settings, as they are + subject to the AccuracySec= setting + below. + + + + + OnCalendar= + + Defines realtime (i.e. wallclock) timers with + calendar event expressions. See + systemd.time7 + for more information on the syntax of calendar event + expressions. Otherwise, the semantics are similar to + OnActiveSec= and related settings. + + Note that timers do not necessarily expire at the + precise time configured with this setting, as it is subject to + the AccuracySec= setting + below. + + + + AccuracySec= + + Specify the accuracy the timer shall elapse + with. Defaults to 1min. The timer is scheduled to elapse + within a time window starting with the time specified in + OnCalendar=, + OnActiveSec=, + OnBootSec=, + OnStartupSec=, + OnUnitActiveSec= or + OnUnitInactiveSec= and ending the time + configured with AccuracySec= later. Within + this time window, the expiry time will be placed at a + host-specific, randomized but stable position that is + synchronized between all local timer units. This is done in + order to distribute the wake-up time in networked + installations, as well as optimizing power consumption to + suppress unnecessary CPU wake-ups. To get best accuracy, set + this option to 1us. Note that the timer is still subject to + the timer slack configured via + systemd-system.conf5's + TimerSlackNSec= setting. See + prctl2 + for details. To optimize power consumption, make sure to set + this value as high as possible and as low as + necessary. + + + Unit= + + The unit to activate when this timer elapses. + The argument is a unit name, whose suffix is not + .timer. If not specified, this value + defaults to a service that has the same name as the timer + unit, except for the suffix. (See above.) It is recommended + that the unit name that is activated and the unit name of the + timer unit are named identically, except for the + suffix. + + + + + Persistent= + + Takes a boolean argument. If true, the time + when the service unit was last triggered is stored on disk. + When the timer is activated, the service unit is triggered + immediately if it would have been triggered at least once + during the time when the timer was inactive. This is useful to + catch up on missed runs of the service when the machine was + off. Note that this setting only has an effect on timers + configured with OnCalendar=. + + + + + WakeSystem= + + Takes a boolean argument. If true, an elapsing + timer will cause the system to resume from suspend, should it + be suspended and if the system supports this. Note that this + option will only make sure the system resumes on the + appropriate times, it will not take care of suspending it + again after any work that is to be done is finished. Defaults + to false. + + + + + + See Also + + systemd1, + systemctl1, + systemd.unit5, + systemd.service5, + systemd.time7, + systemd.directives7, + systemd-system.conf5, + prctl2 + + diff --git a/man/systemd.unit.xml b/man/systemd.unit.xml index 9704d6f2277..4dae6313890 100644 --- a/man/systemd.unit.xml +++ b/man/systemd.unit.xml @@ -1,6 +1,6 @@ %entities; ]> @@ -26,51 +26,51 @@ - - systemd.unit - systemd - - - - Developer - Lennart - Poettering - lennart@poettering.net - - - - - - systemd.unit - 5 - - - - systemd.unit - Unit configuration - - - - service.service, - socket.socket, - device.device, - mount.mount, - automount.automount, - swap.swap, - target.target, - path.path, - timer.timer, - snapshot.snapshot, - slice.slice, - scope.scope - - /etc/systemd/system/* + + systemd.unit + systemd + + + + Developer + Lennart + Poettering + lennart@poettering.net + + + + + + systemd.unit + 5 + + + + systemd.unit + Unit configuration + + + + service.service, + socket.socket, + device.device, + mount.mount, + automount.automount, + swap.swap, + target.target, + path.path, + timer.timer, + snapshot.snapshot, + slice.slice, + scope.scope + + /etc/systemd/system/* /run/systemd/system/* /usr/lib/systemd/system/* ... - + - $XDG_CONFIG_HOME/systemd/user/* + $XDG_CONFIG_HOME/systemd/user/* $HOME/.config/systemd/user/* /etc/systemd/user/* $XDG_RUNTIME_DIR/systemd/user/* @@ -79,1513 +79,1213 @@ $HOME/.local/share/systemd/user/* /usr/lib/systemd/user/* ... - - - - - Description - - A unit configuration file encodes information - about a service, a socket, a device, a mount point, an - automount point, a swap file or partition, a start-up - target, a watched file system path, a timer controlled - and supervised by - systemd1, - a temporary system state snapshot, a resource - management slice or a group of externally created - processes. The syntax is inspired by XDG - Desktop Entry Specification - .desktop files, which are in turn - inspired by Microsoft Windows - .ini files. - - This man page lists the common configuration - options of all the unit types. These options need to - be configured in the [Unit] or [Install] - sections of the unit files. - - In addition to the generic [Unit] and [Install] - sections described here, each unit may have a - type-specific section, e.g. [Service] for a service - unit. See the respective man pages for more - information: - systemd.service5, - systemd.socket5, - systemd.device5, - systemd.mount5, - systemd.automount5, - systemd.swap5, - systemd.target5, - systemd.path5, - systemd.timer5, - systemd.snapshot5. - systemd.slice5. - systemd.scope5. - - - Various settings are allowed to be specified - more than once, in which case the interpretation - depends on the setting. Often, multiple settings form - a list, and setting to an empty value "resets", which - means that previous assignments are ignored. When this - is allowed, it is mentioned in the description of the - setting. Note that using multiple assignments to the - same value makes the unit file incompatible with - parsers for the XDG .desktop file - format. - - Unit files are loaded from a set of paths - determined during compilation, described in the next section. - - - Unit files may contain additional options on top - of those listed here. If systemd encounters an unknown - option, it will write a warning log message but - continue loading the unit. If an option or section name - is prefixed with , it is ignored - completely by systemd. Options within an ignored - section do not need the prefix. Applications may use - this to include additional information in the unit - files. - - Boolean arguments used in unit files can be - written in various formats. For positive settings the - strings , , - and are - equivalent. For negative settings, the strings - , , - and are - equivalent. - - Time span values encoded in unit files can be - written in various formats. A stand-alone number - specifies a time in seconds. If suffixed with a time - unit, the unit is honored. A concatenation of multiple - values with units is supported, in which case the - values are added up. Example: "50" refers to 50 - seconds; "2min 200ms" refers to 2 minutes plus 200 - milliseconds, i.e. 120200ms. The following time units - are understood: s, min, h, d, w, ms, us. For details - see - systemd.time7. - - Empty lines and lines starting with # or ; are - ignored. This may be used for commenting. Lines ending - in a backslash are concatenated with the following - line while reading and the backslash is replaced by a - space character. This may be used to wrap long lines. - - Along with a unit file - foo.service, the directory - foo.service.wants/ may exist. All - unit files symlinked from such a directory are - implicitly added as dependencies of type - Wants= to the unit. This is useful - to hook units into the start-up of other units, - without having to modify their unit files. For details - about the semantics of Wants=, see - below. The preferred way to create symlinks in the - .wants/ directory of a unit file - is with the enable command of the - systemctl1 - tool which reads information from the [Install] - section of unit files (see below). A similar - functionality exists for Requires= - type dependencies as well, the directory suffix is - .requires/ in this case. - - Along with a unit file - foo.service, a directory - foo.service.d/ may exist. All - files with the suffix .conf from - this directory will be parsed after the file itself is - parsed. This is useful to alter or add configuration - settings to a unit, without having to modify their - unit files. Make sure that the file that is included - has the appropriate section headers before any - directive. Note that for instanced units this logic - will first look for the instance - .d/ subdirectory and read its - .conf files, followed by the - template .d/ subdirectory and reads - its .conf files. - - - - Note that while systemd offers a flexible - dependency system between units it is recommended to - use this functionality only sparingly and instead rely - on techniques such as bus-based or socket-based - activation which make dependencies implicit, resulting - in a both simpler and more flexible system. - - Some unit names reflect paths existing in the - file system namespace. Example: a device unit - dev-sda.device refers to a device - with the device node /dev/sda in - the file system namespace. If this applies, a special - way to escape the path name is used, so that the - result is usable as part of a filename. Basically, - given a path, "/" is replaced by "-" and all other - characters which are not ASCII alphanumerics are - replaced by C-style "\x2d" escapes (except that "_" - is never replaced and "." is only replaced when it - would be the first character in the escaped path). - The root directory "/" is encoded as single dash, - while otherwise the initial and ending "/" are removed - from all paths during transformation. This escaping - is reversible. Properly escaped paths can be generated - using the systemd-escape1 - command. - - Optionally, units may be instantiated from a - template file at runtime. This allows creation of - multiple units from a single configuration file. If - systemd looks for a unit configuration file, it will - first search for the literal unit name in the - file system. If that yields no success and the unit - name contains an @ character, systemd will look for a - unit template that shares the same name but with the - instance string (i.e. the part between the @ character - and the suffix) removed. Example: if a service - getty@tty3.service is requested - and no file by that name is found, systemd will look - for getty@.service and - instantiate a service from that configuration file if - it is found. - - To refer to the instance string from - within the configuration file you may use the special - %i specifier in many of the - configuration options. See below for details. - - If a unit file is empty (i.e. has the file size - 0) or is symlinked to /dev/null, - its configuration will not be loaded and it appears - with a load state of masked, and - cannot be activated. Use this as an effective way to - fully disable a unit, making it impossible to start it - even manually. - - The unit file format is covered by the - Interface - Stability Promise. - - - - - Unit Load Path - - Unit files are loaded from a set of paths - determined during compilation, described in the two - tables below. Unit files found in directories listed - earlier override files with the same name in - directories lower in the list. - - When systemd is running in user mode - () and the variable - $SYSTEMD_UNIT_PATH is set, the - contents of this variable overrides the unit load - path. If $SYSTEMD_UNIT_PATH ends - with an empty component (:), the - usual unit load path will be appended to the contents - of the variable. - - - - Load path when running in system mode (<option>--system</option>). - - - - - - - - Path - Description - - - - - /etc/systemd/system - Local configuration - - - /run/systemd/system - Runtime units - - - /usr/lib/systemd/system - Units of installed packages - - - -
- - - - Load path when running in user mode (<option>--user</option>). - - - - - - - - Path - Description - - - - - $XDG_CONFIG_HOME/systemd/user - User configuration (only used when $XDG_CONFIG_HOME is set) - - - $HOME/.config/systemd/user - User configuration (only used when $XDG_CONFIG_HOME is not set) - - - /etc/systemd/user - Local configuration - - - $XDG_RUNTIME_DIR/systemd/user - Runtime units (only used when $XDG_RUNTIME_DIR is set) - - - /run/systemd/user - Runtime units - - - $XDG_DATA_HOME/systemd/user - Units of packages that have been installed in the home directory (only used when $XDG_DATA_HOME is set) - - - $HOME/.local/share/systemd/user - Units of packages that have been installed in the home directory (only used when $XDG_DATA_HOME is not set) - - - /usr/lib/systemd/user - Units of packages that have been installed system-wide - - - -
- - Additional units might be loaded into systemd - ("linked") from directories not on the unit load - path. See the link command for - systemctl1. Also, - some units are dynamically created via generators - Generators. - - - - - [Unit] Section Options - - Unit file may include a [Unit] section, which - carries generic information about the unit that is not - dependent on the type of unit: - - - - - Description= - A free-form string - describing the unit. This is intended - for use in UIs to show descriptive - information along with the unit - name. The description should contain a name - that means something to the end user. - Apache2 Web Server is a good - example. Bad examples are - high-performance light-weight HTTP - server (too generic) or - Apache2 (too specific and - meaningless for people who do not know - Apache). - - - - Documentation= - A space-separated list - of URIs referencing documentation for - this unit or its - configuration. Accepted are only URIs - of the types - http://, - https://, - file:, - info:, - man:. For more - information about the syntax of these - URIs, see - uri7. The - URIs should be listed in order of - relevance, starting with the most - relevant. It is a good idea to first - reference documentation that explains - what the unit's purpose is, followed - by how it is configured, followed by - any other related documentation. This - option may be specified more than once, - in which case the specified list of - URIs is merged. If the empty string is - assigned to this option, the list is - reset and all prior assignments will - have no effect. - - - - Requires= - - Configures requirement - dependencies on other units. If this - unit gets activated, the units listed - here will be activated as well. If one - of the other units gets deactivated or - its activation fails, this unit will - be deactivated. This option may be - specified more than once or multiple - space-separated units may be specified - in one option in which case - requirement dependencies for all - listed names will be created. Note - that requirement dependencies do not - influence the order in which services - are started or stopped. This has to be - configured independently with the - After= or - Before= options. If - a unit - foo.service - requires a unit - bar.service as - configured with - Requires= and no - ordering is configured with - After= or - Before=, then both - units will be started simultaneously - and without any delay between them if - foo.service is - activated. Often it is a better choice - to use Wants= - instead of - Requires= in order - to achieve a system that is more - robust when dealing with failing - services. - - Note that dependencies of this - type may also be configured outside of - the unit configuration file by - adding a symlink to a - .requires/ directory - accompanying the unit file. For - details see above. - - - - RequiresOverridable= - - Similar to - Requires=. - Dependencies listed in - RequiresOverridable= - which cannot be fulfilled or fail to - start are ignored if the startup was - explicitly requested by the user. If - the start-up was pulled in indirectly - by some dependency or automatic - start-up of units that is not - requested by the user, this dependency - must be fulfilled and otherwise the - transaction fails. Hence, this option - may be used to configure dependencies - that are normally honored unless the - user explicitly starts up the unit, in - which case whether they failed or not - is irrelevant. - - - - Requisite= - RequisiteOverridable= - - Similar to - Requires= and - RequiresOverridable=, - respectively. However, if the units - listed here are not started already, - they will not be started and the - transaction will fail immediately. - - - - - Wants= - - A weaker version of - Requires=. Units - listed in this option will be started - if the configuring unit is. However, - if the listed units fail to start - or cannot be added to the transaction, - this has no impact on the validity of - the transaction as a whole. This is - the recommended way to hook start-up - of one unit to the start-up of another - unit. - - Note that dependencies of this - type may also be configured outside of - the unit configuration file by adding - symlinks to a - .wants/ directory - accompanying the unit file. For - details, see above. - - - - BindsTo= - - Configures requirement - dependencies, very similar in style to - Requires=, however - in addition to this behavior, it also - declares that this unit is stopped - when any of the units listed suddenly - disappears. Units can suddenly, - unexpectedly disappear if a service - terminates on its own choice, a device - is unplugged or a mount point - unmounted without involvement of - systemd. - - - - PartOf= - - Configures dependencies - similar to Requires=, - but limited to stopping and restarting - of units. When systemd stops or restarts - the units listed here, the action is - propagated to this unit. - Note that this is a one-way dependency — - changes to this unit do not affect the - listed units. - - - - - Conflicts= - - A space-separated list - of unit names. Configures negative - requirement dependencies. If a unit - has a Conflicts= - setting on another unit, starting the - former will stop the latter and vice - versa. Note that this setting is - independent of and orthogonal to the - After= and - Before= ordering - dependencies. - - If a unit A that conflicts with - a unit B is scheduled to be started at - the same time as B, the transaction - will either fail (in case both are - required part of the transaction) or - be modified to be fixed (in case one - or both jobs are not a required part - of the transaction). In the latter - case, the job that is not the required - will be removed, or in case both are - not required, the unit that conflicts - will be started and the unit that is - conflicted is - stopped. - - - - Before= - After= - - A space-separated list - of unit names. Configures ordering - dependencies between units. If a unit - foo.service - contains a setting - - and both units are being started, - bar.service's - start-up is delayed until - foo.service is - started up. Note that this setting is - independent of and orthogonal to the - requirement dependencies as configured - by Requires=. It is - a common pattern to include a unit - name in both the - After= and - Requires= option, in - which case the unit listed will be - started before the unit that is - configured with these options. This - option may be specified more than - once, in which case ordering - dependencies for all listed names are - created. After= is - the inverse of - Before=, i.e. while - After= ensures that - the configured unit is started after - the listed unit finished starting up, - Before= ensures the - opposite, i.e. that the configured - unit is fully started up before the - listed unit is started. Note that when - two units with an ordering dependency - between them are shut down, the - inverse of the start-up order is - applied. i.e. if a unit is configured - with After= on - another unit, the former is stopped - before the latter if both are shut - down. If one unit with an ordering - dependency on another unit is shut - down while the latter is started up, - the shut down is ordered before the - start-up regardless of whether the - ordering dependency is actually of - type After= or - Before=. If two - units have no ordering dependencies - between them, they are shut down or - started up simultaneously, and no - ordering takes - place. - - - - OnFailure= - - A space-separated list - of one or more units that are - activated when this unit enters the - failed - state. - - - - PropagatesReloadTo= - ReloadPropagatedFrom= - - A space-separated list - of one or more units where reload - requests on this unit will be - propagated to, or reload requests on - the other unit will be propagated to - this unit, respectively. Issuing a - reload request on a unit will - automatically also enqueue a reload - request on all units that the reload - request shall be propagated to via - these two settings. - - - - JoinsNamespaceOf= - - For units that start - processes (such as service units), - lists one or more other units whose - network and/or temporary file - namespace to join. This only applies - to unit types which support the - PrivateNetwork= and - PrivateTmp= - directives (see - systemd.exec5 - for details). If a unit that has this - setting set is started, its processes - will see the same - /tmp, - /tmp/var and - network namespace as one listed unit - that is started. If multiple listed - units are already started, it is not - defined which namespace is - joined. Note that this setting only - has an effect if - PrivateNetwork= - and/or PrivateTmp= - is enabled for both the unit that - joins the namespace and the unit whose - namespace is joined. - - - - RequiresMountsFor= - - Takes a - space-separated list of absolute - paths. Automatically adds dependencies - of type Requires= - and After= for all - mount units required to access the - specified path. - - Mount points marked with - are not - mounted automatically and will be - ignored for the purposes of this - option. If such a mount should be a - requirement for this unit, - direct dependencies on the mount - units may be added - (Requires= and - After= or - some other combination). - - - - - OnFailureJobMode= - - Takes a value of - fail, - replace, - replace-irreversibly, - isolate, - flush, - ignore-dependencies - or - ignore-requirements. Defaults - to - replace. Specifies - how the units listed in - OnFailure= will be - enqueued. See - systemctl1's - option - for details on the possible values. If - this is set to - isolate, only a - single unit may be listed in - OnFailure=.. - - - - IgnoreOnIsolate= - - Takes a boolean - argument. If , - this unit will not be stopped when - isolating another unit. Defaults to - . - - - - IgnoreOnSnapshot= - - Takes a boolean - argument. If , - this unit will not be included in - snapshots. Defaults to - for device and - snapshot units, - for the others. - - - - StopWhenUnneeded= - - Takes a boolean - argument. If , - this unit will be stopped when it is - no longer used. Note that in order to - minimize the work to be executed, - systemd will not stop units by default - unless they are conflicting with other - units, or the user explicitly - requested their shut down. If this - option is set, a unit will be - automatically cleaned up if no other - active unit requires it. Defaults to - . - - - - RefuseManualStart= - RefuseManualStop= - - Takes a boolean - argument. If , - this unit can only be activated - or deactivated indirectly. In - this case, explicit start-up - or termination requested by the - user is denied, however if it is - started or stopped as a - dependency of another unit, start-up - or termination will succeed. This - is mostly a safety feature to ensure - that the user does not accidentally - activate units that are not intended - to be activated explicitly, and not - accidentally deactivate units that are - not intended to be deactivated. - These options default to - . - - - - AllowIsolate= - - Takes a boolean - argument. If , - this unit may be used with the - systemctl isolate - command. Otherwise, this will be - refused. It probably is a good idea to - leave this disabled except for target - units that shall be used similar to - runlevels in SysV init systems, just - as a precaution to avoid unusable - system states. This option defaults to - . - - - - DefaultDependencies= - - Takes a boolean - argument. If , - (the default), a few default - dependencies will implicitly be - created for the unit. The actual - dependencies created depend on the - unit type. For example, for service - units, these dependencies ensure that - the service is started only after - basic system initialization is - completed and is properly terminated on - system shutdown. See the respective - man pages for details. Generally, only - services involved with early boot or - late shutdown should set this option - to . It is - highly recommended to leave this - option enabled for the majority of - common units. If set to - , this option - does not disable all implicit - dependencies, just non-essential - ones. - - - - JobTimeoutSec= - JobTimeoutAction= - JobTimeoutRebootArgument= - - When a job for this - unit is queued a time-out may be - configured. If this time limit is - reached, the job will be cancelled, - the unit however will not change state - or even enter the - failed mode. This - value defaults to 0 (job timeouts - disabled), except for device - units. NB: this timeout is independent - from any unit-specific timeout (for - example, the timeout set with - StartTimeoutSec= in service - units) as the job timeout has no - effect on the unit itself, only on the - job that might be pending for it. Or - in other words: unit-specific timeouts - are useful to abort unit state - changes, and revert them. The job - timeout set with this option however - is useful to abort only the job - waiting for the unit state to - change. - - JobTimeoutAction= - optionally configures an additional - action to take when the time-out is - hit. It takes the same values as the - per-service - StartLimitAction= - setting, see - systemd.service5 - for details. Defaults to - . JobTimeoutRebootArgument= - configures an optional reboot string - to pass to the - reboot2 - system call. - - - - ConditionArchitecture= - ConditionVirtualization= - ConditionHost= - ConditionKernelCommandLine= - ConditionSecurity= - ConditionCapability= - ConditionACPower= - ConditionNeedsUpdate= - ConditionFirstBoot= - ConditionPathExists= - ConditionPathExistsGlob= - ConditionPathIsDirectory= - ConditionPathIsSymbolicLink= - ConditionPathIsMountPoint= - ConditionPathIsReadWrite= - ConditionDirectoryNotEmpty= - ConditionFileNotEmpty= - ConditionFileIsExecutable= - - - - Before starting a unit - verify that the specified condition is - true. If it is not true, the starting - of the unit will be skipped, however - all ordering dependencies of it are - still respected. A failing condition - will not result in the unit being - moved into a failure state. The - condition is checked at the time the - queued start job is to be - executed. - - ConditionArchitecture= - may be used to check whether the - system is running on a specific - architecture. Takes one of - x86, - x86-64, - ppc, - ppc-le, - ppc64, - ppc64-le, - ia64, - parisc, - parisc64, - s390, - s390x, - sparc, - sparc64, - mips, - mips-le, - mips64, - mips64-le, - alpha, - arm, - arm-be, - arm64, - arm64-be, - sh, - sh64, - m86k, - tilegx, - cris to test - against a specific architecture. The - architecture is determined from the - information returned by - uname2 - and is thus subject to - personality2. Note - that a Personality= - setting in the same unit file has no - effect on this condition. A special - architecture name - native is mapped to - the architecture the system manager - itself is compiled for. The test may - be negated by prepending an - exclamation mark. - - ConditionVirtualization= - may be used to check whether the - system is executed in a virtualized - environment and optionally test - whether it is a specific - implementation. Takes either boolean - value to check if being executed in - any virtualized environment, or one of - vm and - container to test - against a generic type of - virtualization solution, or one of - qemu, - kvm, - zvm, - vmware, - microsoft, - oracle, - xen, - bochs, - uml, - openvz, - lxc, - lxc-libvirt, - systemd-nspawn, - docker to test - against a specific implementation. See - systemd-detect-virt1 - for a full list of known - virtualization technologies and their - identifiers. If multiple - virtualization technologies are - nested, only the innermost is - considered. The test may be negated by - prepending an exclamation mark. - - ConditionHost= - may be used to match against the - hostname or machine ID of the - host. This either takes a hostname - string (optionally with shell style - globs) which is tested against the - locally set hostname as returned by - gethostname2, - or a machine ID formatted as string - (see - machine-id5). - The test may be negated by prepending - an exclamation mark. - - ConditionKernelCommandLine= - may be used to check whether a - specific kernel command line option is - set (or if prefixed with the - exclamation mark unset). The argument - must either be a single word, or an - assignment (i.e. two words, separated - =). In the former - case the kernel command line is - searched for the word appearing as is, - or as left hand side of an - assignment. In the latter case, the - exact assignment is looked for with - right and left hand side - matching. - - ConditionSecurity= - may be used to check whether the given - security module is enabled on the - system. Currently the recognized - values values are - selinux, - apparmor, - ima, - smack and - audit. The test may - be negated by prepending an - exclamation mark. - - ConditionCapability= - may be used to check whether the given - capability exists in the capability - bounding set of the service manager - (i.e. this does not check whether - capability is actually available in - the permitted or effective sets, see - capabilities7 - for details). Pass a capability name - such as CAP_MKNOD, - possibly prefixed with an exclamation - mark to negate the check. - - ConditionACPower= - may be used to check whether the - system has AC power, or is exclusively - battery powered at the time of - activation of the unit. This takes a - boolean argument. If set to - true, the condition - will hold only if at least one AC - connector of the system is connected - to a power source, or if no AC - connectors are known. Conversely, if - set to false, the - condition will hold only if there is - at least one AC connector known and - all AC connectors are disconnected - from a power source. - - ConditionNeedsUpdate= - takes one of /var - or /etc as - argument, possibly prefixed with a - ! (for inverting - the condition). This condition may be - used to conditionalize units on - whether the specified directory - requires an update because - /usr's - modification time is newer than the - stamp file - .updated in the - specified directory. This is useful to - implement offline updates of the - vendor operating system resources in - /usr that require - updating of /etc - or /var on the - next following boot. Units making use - of this condition should order - themselves before - systemd-update-done.service8, - to make sure they run before the stamp - files's modification time gets reset - indicating a completed update. - - ConditionFirstBoot= - takes a boolean argument. This - condition may be used to - conditionalize units on whether the - system is booting up with an - unpopulated /etc - directory. This may be used to - populate /etc on - the first boot after factory reset, or - when a new system instances boots up - for the first time. - - With - ConditionPathExists= - a file existence condition is - checked before a unit is started. If - the specified absolute path name does - not exist, the condition will - fail. If the absolute path name passed - to - ConditionPathExists= - is prefixed with an exclamation mark - (!), the test is negated, and the unit - is only started if the path does not - exist. - - ConditionPathExistsGlob= - is similar to - ConditionPathExists=, - but checks for the existence of at - least one file or directory matching - the specified globbing pattern. - - ConditionPathIsDirectory= - is similar to - ConditionPathExists= - but verifies whether a certain path - exists and is a - directory. - - ConditionPathIsSymbolicLink= - is similar to - ConditionPathExists= - but verifies whether a certain path - exists and is a symbolic - link. - - ConditionPathIsMountPoint= - is similar to - ConditionPathExists= - but verifies whether a certain path - exists and is a mount - point. - - ConditionPathIsReadWrite= - is similar to - ConditionPathExists= - but verifies whether the underlying - file system is readable and writable - (i.e. not mounted - read-only). - - ConditionDirectoryNotEmpty= - is similar to - ConditionPathExists= - but verifies whether a certain path - exists and is a non-empty - directory. - - ConditionFileNotEmpty= - is similar to - ConditionPathExists= - but verifies whether a certain path - exists and refers to a regular file - with a non-zero size. - - ConditionFileIsExecutable= - is similar to - ConditionPathExists= - but verifies whether a certain path - exists, is a regular file and marked - executable. - - If multiple conditions are - specified, the unit will be executed if - all of them apply (i.e. a logical AND - is applied). Condition checks can be - prefixed with a pipe symbol (|) in - which case a condition becomes a - triggering condition. If at least one - triggering condition is defined for a - unit, then the unit will be executed if - at least one of the triggering - conditions apply and all of the - non-triggering conditions. If you - prefix an argument with the pipe - symbol and an exclamation mark, the - pipe symbol must be passed first, the - exclamation second. Except for - ConditionPathIsSymbolicLink=, - all path checks follow symlinks. If - any of these options is assigned the - empty string, the list of conditions is - reset completely, all previous - condition settings (of any kind) will - have no effect. - - - - AssertArchitecture= - AssertVirtualization= - AssertHost= - AssertKernelCommandLine= - AssertSecurity= - AssertCapability= - AssertACPower= - AssertNeedsUpdate= - AssertFirstBoot= - AssertPathExists= - AssertPathExistsGlob= - AssertPathIsDirectory= - AssertPathIsSymbolicLink= - AssertPathIsMountPoint= - AssertPathIsReadWrite= - AssertDirectoryNotEmpty= - AssertFileNotEmpty= - AssertFileIsExecutable= - - Similar to the - ConditionArchitecture=, - ConditionVirtualization=, - ... condition settings described above - these settings add assertion checks to - the start-up of the unit. However, - unlike the conditions settings any - assertion setting that is not met - results in failure of the start - job it was triggered by. - - - - SourcePath= - A path to a - configuration file this unit has been - generated from. This is primarily - useful for implementation of generator - tools that convert configuration from - an external configuration file format - into native unit files. This - functionality should not be used in - normal units. - - - - - - - [Install] Section Options - - Unit file may include an - [Install] section, which carries - installation information for the unit. This section is - not interpreted by - systemd1 - during runtime. It is used exclusively by the - enable and - disable commands of the - systemctl1 - tool during installation of a unit: - - - - Alias= - - A space-separated list - of additional names this unit shall be - installed under. The names listed here - must have the same suffix (i.e. type) - as the unit file name. This option may - be specified more than once, in which - case all listed names are used. At - installation time, systemctl - enable will create symlinks - from these names to the unit - filename. - - - - WantedBy= - RequiredBy= - - This option may be - used more than once, or a - space-separated list of unit names may - be given. A symbolic link is created - in the .wants/ or - .requires/ - directory of each of the listed units - when this unit is installed by - systemctl enable. - This has the effect that a dependency - of type Wants= or - Requires= is added - from the listed unit to the current - unit. The primary result is that the - current unit will be started when the - listed unit is started. See the - description of - Wants= and - Requires= in the - [Unit] section for details. - - WantedBy=foo.service - in a service - bar.service is - mostly equivalent to - Alias=foo.service.wants/bar.service - in the same file. In case of template - units, systemctl enable - must be called with an instance name, and - this instance will be added to the - .wants/ or - .requires/ list - of the listed unit. - E.g. WantedBy=getty.target - in a service - getty@.service - will result in systemctl - enable getty@tty2.service - creating a - getty.target.wants/getty@tty2.service - link to getty@.service. - - - - - Also= - - Additional units to - install/deinstall when this unit is - installed/deinstalled. If the user - requests installation/deinstallation - of a unit with this option configured, - systemctl enable - and systemctl - disable will automatically - install/uninstall units listed in this option as - well. - - This option may be used more - than once, or a space-separated list - of unit names may be - given. - - - - DefaultInstance= - - In template unit files, - this specifies for which instance the - unit shall be enabled if the template - is enabled without any explicitly set - instance. This option has no effect in - non-template unit files. The specified - string must be usable as instance - identifier. - - - - The following specifiers are interpreted in the - Install section: %n, %N, %p, %i, %U, %u, %m, %H, %b, %v. - For their meaning see the next section. - - - - - Specifiers - - Many settings resolve specifiers which may be - used to write generic unit files referring to runtime - or unit parameters that are replaced when the unit - files are loaded. The following specifiers are - understood: - - - Specifiers available in unit files - - - - - - - Specifier - Meaning - Details - - - - - %n - Full unit name - - - - %N - Unescaped full unit name - Same as %n, but with escaping undone - - - %p - Prefix name - For instantiated units, this refers to the string before the @ character of the unit name. For non-instantiated units, this refers to the name of the unit with the type suffix removed. - - - %P - Unescaped prefix name - Same as %p, but with escaping undone - - - %i - Instance name - For instantiated units: this is the string between the @ character and the suffix of the unit name. - - - %I - Unescaped instance name - Same as %i, but with escaping undone - - - %f - Unescaped filename - This is either the unescaped instance name (if applicable) with / prepended (if applicable), or the prefix name prepended with /. - - - %c - Control group path of the unit - This path does not include the /sys/fs/cgroup/systemd/ prefix. - - - %r - Control group path of the slice the unit is placed in - This usually maps to the parent cgroup path of %c. - - - %R - Root control group path below which slices and units are placed - For system instances, this resolves to /, except in containers, where this maps to the container's root control group path. - - - %t - Runtime directory - This is either /run (for the system manager) or the path $XDG_RUNTIME_DIR resolves to (for user managers). - - - %u - User name - This is the name of the configured user of the unit, or (if none is set) the user running the systemd instance. - - - %U - User UID - This is the numeric UID of the configured user of the unit, or (if none is set) the user running the systemd user instance. Note that this specifier is not available for units run by the systemd system instance (as opposed to those run by a systemd user instance), unless the user has been configured as a numeric UID in the first place or the configured user is the root user. - - - %h - User home directory - This is the home directory of the configured user of the unit, or (if none is set) the user running the systemd user instance. Similar to %U, this specifier is not available for units run by the systemd system instance, unless the configured user is the root user. - - - %s - User shell - This is the shell of the configured user of the unit, or (if none is set) the user running the systemd user instance. Similar to %U, this specifier is not available for units run by the systemd system instance, unless the configured user is the root user. - - - %m - Machine ID - The machine ID of the running system, formatted as string. See machine-id5 for more information. - - - %b - Boot ID - The boot ID of the running system, formatted as string. See random4 for more information. - - - %H - Host name - The hostname of the running system at the point in time the unit configuation is loaded. - - - %v - Kernel release - Identical to uname -r output - - - %% - Single percent sign - Use %% in place of % to specify a single percent sign. - - - -
- - Please note that specifiers - %U, %h, - %s are mostly useless when systemd - is running in system mode. PID 1 cannot query the - user account database for information, so the - specifiers only work as shortcuts for things which are - already specified in a different way in the unit - file. They are fully functional when systemd is - running in mode. - - - - Examples - - - Allowing units to be enabled - - The following snippet (highlighted) - allows a unit (e.g. - foo.service) to be - enabled via - systemctl enable: - - [Unit] + + + + + Description + + A unit configuration file encodes information about a + service, a socket, a device, a mount point, an automount point, a + swap file or partition, a start-up target, a watched file system + path, a timer controlled and supervised by + systemd1, + a temporary system state snapshot, a resource management slice or + a group of externally created processes. The syntax is inspired by + XDG + Desktop Entry Specification .desktop + files, which are in turn inspired by Microsoft Windows + .ini files. + + This man page lists the common configuration options of all + the unit types. These options need to be configured in the [Unit] + or [Install] sections of the unit files. + + In addition to the generic [Unit] and [Install] sections + described here, each unit may have a type-specific section, e.g. + [Service] for a service unit. See the respective man pages for + more information: + systemd.service5, + systemd.socket5, + systemd.device5, + systemd.mount5, + systemd.automount5, + systemd.swap5, + systemd.target5, + systemd.path5, + systemd.timer5, + systemd.snapshot5. + systemd.slice5. + systemd.scope5. + + + Various settings are allowed to be specified more than once, + in which case the interpretation depends on the setting. Often, + multiple settings form a list, and setting to an empty value + "resets", which means that previous assignments are ignored. When + this is allowed, it is mentioned in the description of the + setting. Note that using multiple assignments to the same value + makes the unit file incompatible with parsers for the XDG + .desktop file format. + + Unit files are loaded from a set of paths determined during + compilation, described in the next section. + + Unit files may contain additional options on top of those + listed here. If systemd encounters an unknown option, it will + write a warning log message but continue loading the unit. If an + option or section name is prefixed with , it is + ignored completely by systemd. Options within an ignored section + do not need the prefix. Applications may use this to include + additional information in the unit files. + + Boolean arguments used in unit files can be written in + various formats. For positive settings the strings + , , + and are equivalent. For negative settings, the + strings , , + and are + equivalent. + + Time span values encoded in unit files can be written in + various formats. A stand-alone number specifies a time in seconds. + If suffixed with a time unit, the unit is honored. A concatenation + of multiple values with units is supported, in which case the + values are added up. Example: "50" refers to 50 seconds; "2min + 200ms" refers to 2 minutes plus 200 milliseconds, i.e. 120200ms. + The following time units are understood: s, min, h, d, w, ms, us. + For details see + systemd.time7. + + Empty lines and lines starting with # or ; are + ignored. This may be used for commenting. Lines ending + in a backslash are concatenated with the following + line while reading and the backslash is replaced by a + space character. This may be used to wrap long lines. + + Along with a unit file foo.service, the + directory foo.service.wants/ may exist. All + unit files symlinked from such a directory are implicitly added as + dependencies of type Wants= to the unit. This + is useful to hook units into the start-up of other units, without + having to modify their unit files. For details about the semantics + of Wants=, see below. The preferred way to + create symlinks in the .wants/ directory of a + unit file is with the enable command of the + systemctl1 + tool which reads information from the [Install] section of unit + files (see below). A similar functionality exists for + Requires= type dependencies as well, the + directory suffix is .requires/ in this + case. + + Along with a unit file foo.service, a + directory foo.service.d/ may exist. All files + with the suffix .conf from this directory will + be parsed after the file itself is parsed. This is useful to alter + or add configuration settings to a unit, without having to modify + their unit files. Make sure that the file that is included has the + appropriate section headers before any directive. Note that for + instanced units this logic will first look for the instance + .d/ subdirectory and read its + .conf files, followed by the template + .d/ subdirectory and reads its + .conf files. + + + + Note that while systemd offers a flexible dependency system + between units it is recommended to use this functionality only + sparingly and instead rely on techniques such as bus-based or + socket-based activation which make dependencies implicit, + resulting in a both simpler and more flexible system. + + Some unit names reflect paths existing in the file system + namespace. Example: a device unit + dev-sda.device refers to a device with the + device node /dev/sda in the + file system namespace. If this applies, a special way to escape + the path name is used, so that the result is usable as part of a + filename. Basically, given a path, "/" is replaced by "-" and all + other characters which are not ASCII alphanumerics are replaced by + C-style "\x2d" escapes (except that "_" is never replaced and "." + is only replaced when it would be the first character in the + escaped path). The root directory "/" is encoded as single dash, + while otherwise the initial and ending "/" are removed from all + paths during transformation. This escaping is reversible. Properly + escaped paths can be generated using the + systemd-escape1 + command. + + Optionally, units may be instantiated from a + template file at runtime. This allows creation of + multiple units from a single configuration file. If + systemd looks for a unit configuration file, it will + first search for the literal unit name in the + file system. If that yields no success and the unit + name contains an @ character, systemd will look for a + unit template that shares the same name but with the + instance string (i.e. the part between the @ character + and the suffix) removed. Example: if a service + getty@tty3.service is requested + and no file by that name is found, systemd will look + for getty@.service and + instantiate a service from that configuration file if + it is found. + + To refer to the instance string from within the + configuration file you may use the special %i + specifier in many of the configuration options. See below for + details. + + If a unit file is empty (i.e. has the file size 0) or is + symlinked to /dev/null, its configuration + will not be loaded and it appears with a load state of + masked, and cannot be activated. Use this as an + effective way to fully disable a unit, making it impossible to + start it even manually. + + The unit file format is covered by the + Interface + Stability Promise. + + + + + Unit Load Path + + Unit files are loaded from a set of paths determined during + compilation, described in the two tables below. Unit files found + in directories listed earlier override files with the same name in + directories lower in the list. + + When systemd is running in user mode + () and the variable + $SYSTEMD_UNIT_PATH is set, the contents of this + variable overrides the unit load path. If + $SYSTEMD_UNIT_PATH ends with an empty component + (:), the usual unit load path will be appended + to the contents of the variable. + + + + Load path when running in system mode (<option>--system</option>). + + + + + + + + Path + Description + + + + + /etc/systemd/system + Local configuration + + + /run/systemd/system + Runtime units + + + /usr/lib/systemd/system + Units of installed packages + + + +
+ + + + Load path when running in user mode (<option>--user</option>). + + + + + + + + Path + Description + + + + + $XDG_CONFIG_HOME/systemd/user + User configuration (only used when $XDG_CONFIG_HOME is set) + + + $HOME/.config/systemd/user + User configuration (only used when $XDG_CONFIG_HOME is not set) + + + /etc/systemd/user + Local configuration + + + $XDG_RUNTIME_DIR/systemd/user + Runtime units (only used when $XDG_RUNTIME_DIR is set) + + + /run/systemd/user + Runtime units + + + $XDG_DATA_HOME/systemd/user + Units of packages that have been installed in the home directory (only used when $XDG_DATA_HOME is set) + + + $HOME/.local/share/systemd/user + Units of packages that have been installed in the home directory (only used when $XDG_DATA_HOME is not set) + + + /usr/lib/systemd/user + Units of packages that have been installed system-wide + + + +
+ + Additional units might be loaded into systemd ("linked") + from directories not on the unit load path. See the + link command for + systemctl1. + Also, some units are dynamically created via generators Generators. + + + + + [Unit] Section Options + + Unit file may include a [Unit] section, which carries + generic information about the unit that is not dependent on the + type of unit: + + + + + Description= + A free-form string describing the unit. This + is intended for use in UIs to show descriptive information + along with the unit name. The description should contain a + name that means something to the end user. Apache2 + Web Server is a good example. Bad examples are + high-performance light-weight HTTP server + (too generic) or Apache2 (too specific and + meaningless for people who do not know + Apache). + + + + Documentation= + A space-separated list of URIs referencing + documentation for this unit or its configuration. Accepted are + only URIs of the types http://, + https://, file:, + info:, man:. For more + information about the syntax of these URIs, see uri7. + The URIs should be listed in order of relevance, starting with + the most relevant. It is a good idea to first reference + documentation that explains what the unit's purpose is, + followed by how it is configured, followed by any other + related documentation. This option may be specified more than + once, in which case the specified list of URIs is merged. If + the empty string is assigned to this option, the list is reset + and all prior assignments will have no + effect. + + + + Requires= + + Configures requirement dependencies on other + units. If this unit gets activated, the units listed here will + be activated as well. If one of the other units gets + deactivated or its activation fails, this unit will be + deactivated. This option may be specified more than once or + multiple space-separated units may be specified in one option + in which case requirement dependencies for all listed names + will be created. Note that requirement dependencies do not + influence the order in which services are started or stopped. + This has to be configured independently with the + After= or Before= + options. If a unit foo.service requires a + unit bar.service as configured with + Requires= and no ordering is configured + with After= or Before=, + then both units will be started simultaneously and without any + delay between them if foo.service is + activated. Often it is a better choice to use + Wants= instead of + Requires= in order to achieve a system that + is more robust when dealing with failing services. + + Note that dependencies of this type may also be + configured outside of the unit configuration file by adding a + symlink to a .requires/ directory + accompanying the unit file. For details see + above. + + + + RequiresOverridable= + + Similar to Requires=. + Dependencies listed in RequiresOverridable= + which cannot be fulfilled or fail to start are ignored if the + startup was explicitly requested by the user. If the start-up + was pulled in indirectly by some dependency or automatic + start-up of units that is not requested by the user, this + dependency must be fulfilled and otherwise the transaction + fails. Hence, this option may be used to configure + dependencies that are normally honored unless the user + explicitly starts up the unit, in which case whether they + failed or not is irrelevant. + + + + Requisite= + RequisiteOverridable= + + Similar to Requires= and + RequiresOverridable=, respectively. + However, if the units listed here are not started already, + they will not be started and the transaction will fail + immediately. + + + + Wants= + + A weaker version of + Requires=. Units listed in this option will + be started if the configuring unit is. However, if the listed + units fail to start or cannot be added to the transaction, + this has no impact on the validity of the transaction as a + whole. This is the recommended way to hook start-up of one + unit to the start-up of another unit. + + Note that dependencies of this type may also be + configured outside of the unit configuration file by adding + symlinks to a .wants/ directory + accompanying the unit file. For details, see + above. + + + + BindsTo= + + Configures requirement dependencies, very + similar in style to Requires=, however in + addition to this behavior, it also declares that this unit is + stopped when any of the units listed suddenly disappears. + Units can suddenly, unexpectedly disappear if a service + terminates on its own choice, a device is unplugged or a mount + point unmounted without involvement of + systemd. + + + + PartOf= + + Configures dependencies similar to + Requires=, but limited to stopping and + restarting of units. When systemd stops or restarts the units + listed here, the action is propagated to this unit. Note that + this is a one-way dependency — changes to this unit do not + affect the listed units. + + + + Conflicts= + + A space-separated list of unit names. + Configures negative requirement dependencies. If a unit has a + Conflicts= setting on another unit, + starting the former will stop the latter and vice versa. Note + that this setting is independent of and orthogonal to the + After= and Before= + ordering dependencies. + + If a unit A that conflicts with a unit B is scheduled to + be started at the same time as B, the transaction will either + fail (in case both are required part of the transaction) or be + modified to be fixed (in case one or both jobs are not a + required part of the transaction). In the latter case, the job + that is not the required will be removed, or in case both are + not required, the unit that conflicts will be started and the + unit that is conflicted is stopped. + + + + Before= + After= + + A space-separated list of unit names. + Configures ordering dependencies between units. If a unit + foo.service contains a setting + and both units are being + started, bar.service's start-up is + delayed until foo.service is started up. + Note that this setting is independent of and orthogonal to the + requirement dependencies as configured by + Requires=. It is a common pattern to + include a unit name in both the After= and + Requires= option, in which case the unit + listed will be started before the unit that is configured with + these options. This option may be specified more than once, in + which case ordering dependencies for all listed names are + created. After= is the inverse of + Before=, i.e. while + After= ensures that the configured unit is + started after the listed unit finished starting up, + Before= ensures the opposite, i.e. that the + configured unit is fully started up before the listed unit is + started. Note that when two units with an ordering dependency + between them are shut down, the inverse of the start-up order + is applied. i.e. if a unit is configured with + After= on another unit, the former is + stopped before the latter if both are shut down. If one unit + with an ordering dependency on another unit is shut down while + the latter is started up, the shut down is ordered before the + start-up regardless of whether the ordering dependency is + actually of type After= or + Before=. If two units have no ordering + dependencies between them, they are shut down or started up + simultaneously, and no ordering takes place. + + + + + OnFailure= + + A space-separated list of one or more units + that are activated when this unit enters the + failed state. + + + + PropagatesReloadTo= + ReloadPropagatedFrom= + + A space-separated list of one or more units + where reload requests on this unit will be propagated to, or + reload requests on the other unit will be propagated to this + unit, respectively. Issuing a reload request on a unit will + automatically also enqueue a reload request on all units that + the reload request shall be propagated to via these two + settings. + + + + JoinsNamespaceOf= + + For units that start processes (such as + service units), lists one or more other units whose network + and/or temporary file namespace to join. This only applies to + unit types which support the + PrivateNetwork= and + PrivateTmp= directives (see + systemd.exec5 + for details). If a unit that has this setting set is started, + its processes will see the same /tmp, + /tmp/var and network namespace as one + listed unit that is started. If multiple listed units are + already started, it is not defined which namespace is joined. + Note that this setting only has an effect if + PrivateNetwork= and/or + PrivateTmp= is enabled for both the unit + that joins the namespace and the unit whose namespace is + joined. + + + + RequiresMountsFor= + + Takes a space-separated list of absolute + paths. Automatically adds dependencies of type + Requires= and After= for + all mount units required to access the specified path. + + Mount points marked with are not + mounted automatically and will be ignored for the purposes of + this option. If such a mount should be a requirement for this + unit, direct dependencies on the mount units may be added + (Requires= and After= or + some other combination). + + + + OnFailureJobMode= + + Takes a value of + fail, + replace, + replace-irreversibly, + isolate, + flush, + ignore-dependencies or + ignore-requirements. Defaults to + replace. Specifies how the units listed in + OnFailure= will be enqueued. See + systemctl1's + option for details on the + possible values. If this is set to isolate, + only a single unit may be listed in + OnFailure=.. + + + + IgnoreOnIsolate= + + Takes a boolean argument. If + , this unit will not be stopped when + isolating another unit. Defaults to + . + + + + IgnoreOnSnapshot= + + Takes a boolean argument. If + , this unit will not be included in + snapshots. Defaults to for device and + snapshot units, for the + others. + + + + StopWhenUnneeded= + + Takes a boolean argument. If + , this unit will be stopped when it is no + longer used. Note that in order to minimize the work to be + executed, systemd will not stop units by default unless they + are conflicting with other units, or the user explicitly + requested their shut down. If this option is set, a unit will + be automatically cleaned up if no other active unit requires + it. Defaults to . + + + + RefuseManualStart= + RefuseManualStop= + + Takes a boolean argument. If + , this unit can only be activated or + deactivated indirectly. In this case, explicit start-up or + termination requested by the user is denied, however if it is + started or stopped as a dependency of another unit, start-up + or termination will succeed. This is mostly a safety feature + to ensure that the user does not accidentally activate units + that are not intended to be activated explicitly, and not + accidentally deactivate units that are not intended to be + deactivated. These options default to + . + + + + AllowIsolate= + + Takes a boolean argument. If + , this unit may be used with the + systemctl isolate command. Otherwise, this + will be refused. It probably is a good idea to leave this + disabled except for target units that shall be used similar to + runlevels in SysV init systems, just as a precaution to avoid + unusable system states. This option defaults to + . + + + + DefaultDependencies= + + Takes a boolean argument. If + , (the default), a few default + dependencies will implicitly be created for the unit. The + actual dependencies created depend on the unit type. For + example, for service units, these dependencies ensure that the + service is started only after basic system initialization is + completed and is properly terminated on system shutdown. See + the respective man pages for details. Generally, only services + involved with early boot or late shutdown should set this + option to . It is highly recommended to + leave this option enabled for the majority of common units. If + set to , this option does not disable + all implicit dependencies, just non-essential + ones. + + + + JobTimeoutSec= + JobTimeoutAction= + JobTimeoutRebootArgument= + + When a job for this unit is queued a time-out + may be configured. If this time limit is reached, the job will + be cancelled, the unit however will not change state or even + enter the failed mode. This value defaults + to 0 (job timeouts disabled), except for device units. NB: + this timeout is independent from any unit-specific timeout + (for example, the timeout set with + StartTimeoutSec= in service units) as the + job timeout has no effect on the unit itself, only on the job + that might be pending for it. Or in other words: unit-specific + timeouts are useful to abort unit state changes, and revert + them. The job timeout set with this option however is useful + to abort only the job waiting for the unit state to + change. + + JobTimeoutAction= + optionally configures an additional + action to take when the time-out is + hit. It takes the same values as the + per-service + StartLimitAction= + setting, see + systemd.service5 + for details. Defaults to + . JobTimeoutRebootArgument= + configures an optional reboot string + to pass to the + reboot2 + system call. + + + + ConditionArchitecture= + ConditionVirtualization= + ConditionHost= + ConditionKernelCommandLine= + ConditionSecurity= + ConditionCapability= + ConditionACPower= + ConditionNeedsUpdate= + ConditionFirstBoot= + ConditionPathExists= + ConditionPathExistsGlob= + ConditionPathIsDirectory= + ConditionPathIsSymbolicLink= + ConditionPathIsMountPoint= + ConditionPathIsReadWrite= + ConditionDirectoryNotEmpty= + ConditionFileNotEmpty= + ConditionFileIsExecutable= + + + + Before starting a unit verify that the + specified condition is true. If it is not true, the starting + of the unit will be skipped, however all ordering dependencies + of it are still respected. A failing condition will not result + in the unit being moved into a failure state. The condition is + checked at the time the queued start job is to be + executed. + + ConditionArchitecture= may be used to + check whether the system is running on a specific + architecture. Takes one of + x86, + x86-64, + ppc, + ppc-le, + ppc64, + ppc64-le, + ia64, + parisc, + parisc64, + s390, + s390x, + sparc, + sparc64, + mips, + mips-le, + mips64, + mips64-le, + alpha, + arm, + arm-be, + arm64, + arm64-be, + sh, + sh64, + m86k, + tilegx, + cris to test + against a specific architecture. The architecture is + determined from the information returned by + uname2 + and is thus subject to + personality2. + Note that a Personality= setting in the + same unit file has no effect on this condition. A special + architecture name native is mapped to the + architecture the system manager itself is compiled for. The + test may be negated by prepending an exclamation mark. + + ConditionVirtualization= may be used + to check whether the system is executed in a virtualized + environment and optionally test whether it is a specific + implementation. Takes either boolean value to check if being + executed in any virtualized environment, or one of + vm and + container to test against a generic type of + virtualization solution, or one of + qemu, + kvm, + zvm, + vmware, + microsoft, + oracle, + xen, + bochs, + uml, + openvz, + lxc, + lxc-libvirt, + systemd-nspawn, + docker to test + against a specific implementation. See + systemd-detect-virt1 + for a full list of known virtualization technologies and their + identifiers. If multiple virtualization technologies are + nested, only the innermost is considered. The test may be + negated by prepending an exclamation mark. + + ConditionHost= may be used to match + against the hostname or machine ID of the host. This either + takes a hostname string (optionally with shell style globs) + which is tested against the locally set hostname as returned + by + gethostname2, + or a machine ID formatted as string (see + machine-id5). + The test may be negated by prepending an exclamation + mark. + + ConditionKernelCommandLine= may be + used to check whether a specific kernel command line option is + set (or if prefixed with the exclamation mark unset). The + argument must either be a single word, or an assignment (i.e. + two words, separated =). In the former case + the kernel command line is searched for the word appearing as + is, or as left hand side of an assignment. In the latter case, + the exact assignment is looked for with right and left hand + side matching. + + ConditionSecurity= may be used to + check whether the given security module is enabled on the + system. Currently the recognized values values are + selinux, + apparmor, + ima, + smack and + audit. The test may be negated by + prepending an exclamation mark. + + ConditionCapability= may be used to + check whether the given capability exists in the capability + bounding set of the service manager (i.e. this does not check + whether capability is actually available in the permitted or + effective sets, see + capabilities7 + for details). Pass a capability name such as + CAP_MKNOD, possibly prefixed with an + exclamation mark to negate the check. + + ConditionACPower= may be used to + check whether the system has AC power, or is exclusively + battery powered at the time of activation of the unit. This + takes a boolean argument. If set to true, + the condition will hold only if at least one AC connector of + the system is connected to a power source, or if no AC + connectors are known. Conversely, if set to + false, the condition will hold only if + there is at least one AC connector known and all AC connectors + are disconnected from a power source. + + ConditionNeedsUpdate= takes one of + /var or /etc as + argument, possibly prefixed with a ! (for + inverting the condition). This condition may be used to + conditionalize units on whether the specified directory + requires an update because /usr's + modification time is newer than the stamp file + .updated in the specified directory. This + is useful to implement offline updates of the vendor operating + system resources in /usr that require + updating of /etc or + /var on the next following boot. Units + making use of this condition should order themselves before + systemd-update-done.service8, + to make sure they run before the stamp files's modification + time gets reset indicating a completed update. + + ConditionFirstBoot= takes a boolean + argument. This condition may be used to conditionalize units + on whether the system is booting up with an unpopulated + /etc directory. This may be used to + populate /etc on the first boot after + factory reset, or when a new system instances boots up for the + first time. + + With ConditionPathExists= a file + existence condition is checked before a unit is started. If + the specified absolute path name does not exist, the condition + will fail. If the absolute path name passed to + ConditionPathExists= is prefixed with an + exclamation mark (!), the test is negated, + and the unit is only started if the path does not + exist. + + ConditionPathExistsGlob= is similar + to ConditionPathExists=, but checks for the + existence of at least one file or directory matching the + specified globbing pattern. + + ConditionPathIsDirectory= is similar + to ConditionPathExists= but verifies + whether a certain path exists and is a directory. + + ConditionPathIsSymbolicLink= is + similar to ConditionPathExists= but + verifies whether a certain path exists and is a symbolic + link. + + ConditionPathIsMountPoint= is similar + to ConditionPathExists= but verifies + whether a certain path exists and is a mount point. + + ConditionPathIsReadWrite= is similar + to ConditionPathExists= but verifies + whether the underlying file system is readable and writable + (i.e. not mounted read-only). + + ConditionDirectoryNotEmpty= is + similar to ConditionPathExists= but + verifies whether a certain path exists and is a non-empty + directory. + + ConditionFileNotEmpty= is similar to + ConditionPathExists= but verifies whether a + certain path exists and refers to a regular file with a + non-zero size. + + ConditionFileIsExecutable= is similar + to ConditionPathExists= but verifies + whether a certain path exists, is a regular file and marked + executable. + + If multiple conditions are specified, the unit will be + executed if all of them apply (i.e. a logical AND is applied). + Condition checks can be prefixed with a pipe symbol (|) in + which case a condition becomes a triggering condition. If at + least one triggering condition is defined for a unit, then the + unit will be executed if at least one of the triggering + conditions apply and all of the non-triggering conditions. If + you prefix an argument with the pipe symbol and an exclamation + mark, the pipe symbol must be passed first, the exclamation + second. Except for + ConditionPathIsSymbolicLink=, all path + checks follow symlinks. If any of these options is assigned + the empty string, the list of conditions is reset completely, + all previous condition settings (of any kind) will have no + effect. + + + + AssertArchitecture= + AssertVirtualization= + AssertHost= + AssertKernelCommandLine= + AssertSecurity= + AssertCapability= + AssertACPower= + AssertNeedsUpdate= + AssertFirstBoot= + AssertPathExists= + AssertPathExistsGlob= + AssertPathIsDirectory= + AssertPathIsSymbolicLink= + AssertPathIsMountPoint= + AssertPathIsReadWrite= + AssertDirectoryNotEmpty= + AssertFileNotEmpty= + AssertFileIsExecutable= + + Similar to the + ConditionArchitecture=, + ConditionVirtualization=, ... condition + settings described above these settings add assertion checks + to the start-up of the unit. However, unlike the conditions + settings any assertion setting that is not met results in + failure of the start job it was triggered + by. + + + + SourcePath= + A path to a configuration file this unit has + been generated from. This is primarily useful for + implementation of generator tools that convert configuration + from an external configuration file format into native unit + files. This functionality should not be used in normal + units. + + + + + + + [Install] Section Options + + Unit file may include an [Install] + section, which carries installation information for the unit. This + section is not interpreted by + systemd1 + during runtime. It is used exclusively by the + enable and disable commands + of the + systemctl1 + tool during installation of a unit: + + + + Alias= + + A space-separated list of additional names + this unit shall be installed under. The names listed here must + have the same suffix (i.e. type) as the unit file name. This + option may be specified more than once, in which case all + listed names are used. At installation time, + systemctl enable will create symlinks from + these names to the unit filename. + + + + WantedBy= + RequiredBy= + + This option may be used more than once, or a + space-separated list of unit names may be given. A symbolic + link is created in the .wants/ or + .requires/ directory of each of the + listed units when this unit is installed by systemctl + enable. This has the effect that a dependency of + type Wants= or Requires= + is added from the listed unit to the current unit. The primary + result is that the current unit will be started when the + listed unit is started. See the description of + Wants= and Requires= in + the [Unit] section for details. + + WantedBy=foo.service in a service + bar.service is mostly equivalent to + Alias=foo.service.wants/bar.service in the + same file. In case of template units, systemctl + enable must be called with an instance name, and + this instance will be added to the + .wants/ or + .requires/ list of the listed unit. E.g. + WantedBy=getty.target in a service + getty@.service will result in + systemctl enable getty@tty2.service + creating a + getty.target.wants/getty@tty2.service + link to getty@.service. + + + + + Also= + + Additional units to install/deinstall when + this unit is installed/deinstalled. If the user requests + installation/deinstallation of a unit with this option + configured, systemctl enable and + systemctl disable will automatically + install/uninstall units listed in this option as well. + + This option may be used more than once, or a + space-separated list of unit names may be + given. + + + + DefaultInstance= + + In template unit files, this specifies for + which instance the unit shall be enabled if the template is + enabled without any explicitly set instance. This option has + no effect in non-template unit files. The specified string + must be usable as instance identifier. + + + + The following specifiers are interpreted in the Install + section: %n, %N, %p, %i, %U, %u, %m, %H, %b, %v. For their meaning + see the next section. + + + + + Specifiers + + Many settings resolve specifiers which may be used to write + generic unit files referring to runtime or unit parameters that + are replaced when the unit files are loaded. The following + specifiers are understood: + + + Specifiers available in unit files + + + + + + + Specifier + Meaning + Details + + + + + %n + Full unit name + + + + %N + Unescaped full unit name + Same as %n, but with escaping undone + + + %p + Prefix name + For instantiated units, this refers to the string before the @ character of the unit name. For non-instantiated units, this refers to the name of the unit with the type suffix removed. + + + %P + Unescaped prefix name + Same as %p, but with escaping undone + + + %i + Instance name + For instantiated units: this is the string between the @ character and the suffix of the unit name. + + + %I + Unescaped instance name + Same as %i, but with escaping undone + + + %f + Unescaped filename + This is either the unescaped instance name (if applicable) with / prepended (if applicable), or the prefix name prepended with /. + + + %c + Control group path of the unit + This path does not include the /sys/fs/cgroup/systemd/ prefix. + + + %r + Control group path of the slice the unit is placed in + This usually maps to the parent cgroup path of %c. + + + %R + Root control group path below which slices and units are placed + For system instances, this resolves to /, except in containers, where this maps to the container's root control group path. + + + %t + Runtime directory + This is either /run (for the system manager) or the path $XDG_RUNTIME_DIR resolves to (for user managers). + + + %u + User name + This is the name of the configured user of the unit, or (if none is set) the user running the systemd instance. + + + %U + User UID + This is the numeric UID of the configured user of the unit, or (if none is set) the user running the systemd user instance. Note that this specifier is not available for units run by the systemd system instance (as opposed to those run by a systemd user instance), unless the user has been configured as a numeric UID in the first place or the configured user is the root user. + + + %h + User home directory + This is the home directory of the configured user of the unit, or (if none is set) the user running the systemd user instance. Similar to %U, this specifier is not available for units run by the systemd system instance, unless the configured user is the root user. + + + %s + User shell + This is the shell of the configured user of the unit, or (if none is set) the user running the systemd user instance. Similar to %U, this specifier is not available for units run by the systemd system instance, unless the configured user is the root user. + + + %m + Machine ID + The machine ID of the running system, formatted as string. See machine-id5 for more information. + + + %b + Boot ID + The boot ID of the running system, formatted as string. See random4 for more information. + + + %H + Host name + The hostname of the running system at the point in time the unit configuation is loaded. + + + %v + Kernel release + Identical to uname -r output + + + %% + Single percent sign + Use %% in place of % to specify a single percent sign. + + + +
+ + Please note that specifiers %U, + %h, %s are mostly useless + when systemd is running in system mode. PID 1 cannot query the + user account database for information, so the specifiers only work + as shortcuts for things which are already specified in a different + way in the unit file. They are fully functional when systemd is + running in mode. + + + + Examples + + + Allowing units to be enabled + + The following snippet (highlighted) allows a unit (e.g. + foo.service) to be enabled via + systemctl enable: + + [Unit] Description=Foo [Service] @@ -1594,70 +1294,59 @@ ExecStart=/usr/sbin/foo-daemon [Install] WantedBy=multi-user.target - After running - systemctl enable, a symlink - /etc/systemd/system/multi-user.target.wants/foo.service - linking to the actual unit will be created. It - tells systemd to pull in the unit when starting - multi-user.target. The - inverse systemctl disable - will remove that symlink again. - - - - Overriding vendor settings - - There are two methods of overriding - vendor settings in unit files: copying the unit - file from - /usr/lib/systemd/system - to /etc/systemd/system and - modifying the chosen settings. Alternatively, - one can create a directory named - unit.d/ - within - /etc/systemd/system and - place a drop-in file - name.conf - there that only changes the specific settings - one is interested in. Note that multiple such - drop-in files are read if present. - - The advantage of the first method is - that one easily overrides the complete unit, - the vendor unit is not parsed at all anymore. - It has the disadvantage that improvements to - the unit file by the vendor are not - automatically incorporated on updates. - - The advantage of the second method is - that one only overrides the settings one - specifically wants, where updates to the unit - by the vendor automatically apply. This has the - disadvantage that some future updates by the - vendor might be incompatible with the local - changes. - - Note that for drop-in files, if one wants - to remove entries from a setting that is parsed - as a list (and is not a dependency), such as - ConditionPathExists= (or - e.g. ExecStart= in service - units), one needs to first clear the list - before re-adding all entries except the one - that is to be removed. See below for an - example. - - This also applies for user instances of - systemd, but with different locations for the - unit files. See the section on unit load paths - for further details. - - Suppose there is a vendor-supplied unit - /usr/lib/systemd/system/httpd.service - with the following contents: - - [Unit] + After running systemctl enable, a + symlink + /etc/systemd/system/multi-user.target.wants/foo.service + linking to the actual unit will be created. It tells systemd to + pull in the unit when starting + multi-user.target. The inverse + systemctl disable will remove that symlink + again. + + + + Overriding vendor settings + + There are two methods of overriding vendor settings in + unit files: copying the unit file from + /usr/lib/systemd/system to + /etc/systemd/system and modifying the + chosen settings. Alternatively, one can create a directory named + unit.d/ within + /etc/systemd/system and place a drop-in + file name.conf + there that only changes the specific settings one is interested + in. Note that multiple such drop-in files are read if + present. + + The advantage of the first method is that one easily + overrides the complete unit, the vendor unit is not parsed at + all anymore. It has the disadvantage that improvements to the + unit file by the vendor are not automatically incorporated on + updates. + + The advantage of the second method is that one only + overrides the settings one specifically wants, where updates to + the unit by the vendor automatically apply. This has the + disadvantage that some future updates by the vendor might be + incompatible with the local changes. + + Note that for drop-in files, if one wants to remove + entries from a setting that is parsed as a list (and is not a + dependency), such as ConditionPathExists= (or + e.g. ExecStart= in service units), one needs + to first clear the list before re-adding all entries except the + one that is to be removed. See below for an example. + + This also applies for user instances of systemd, but with + different locations for the unit files. See the section on unit + load paths for further details. + + Suppose there is a vendor-supplied unit + /usr/lib/systemd/system/httpd.service with + the following contents: + + [Unit] Description=Some HTTP server After=remote-fs.target sqldb.service Requires=sqldb.service @@ -1671,34 +1360,25 @@ Nice=5 [Install] WantedBy=multi-user.target - Now one wants to change some settings as - an administrator: firstly, in the local setup, - /srv/webserver might not - exit, because the HTTP server is configured to - use /srv/www instead. - Secondly, the local configuration makes the - HTTP server also depend on a memory cache - service, - memcached.service, that - should be pulled in - (Requires=) and also be - ordered appropriately - (After=). Thirdly, in order - to harden the service a bit more, the - administrator would like to set the - PrivateTmp= - setting (see - systemd.service5 - for details). And lastly, the administrator - would like to reset the niceness of the service - to its default value of 0. - - The first possibility is to copy the unit - file to - /etc/systemd/system/httpd.service - and change the chosen settings: - - [Unit] + Now one wants to change some settings as an administrator: + firstly, in the local setup, /srv/webserver + might not exit, because the HTTP server is configured to use + /srv/www instead. Secondly, the local + configuration makes the HTTP server also depend on a memory + cache service, memcached.service, that + should be pulled in (Requires=) and also be + ordered appropriately (After=). Thirdly, in + order to harden the service a bit more, the administrator would + like to set the PrivateTmp= setting (see + systemd.service5 + for details). And lastly, the administrator would like to reset + the niceness of the service to its default value of 0. + + The first possibility is to copy the unit file to + /etc/systemd/system/httpd.service and + change the chosen settings: + + [Unit] Description=Some HTTP server After=remote-fs.target sqldb.service memcached.service Requires=sqldb.service memcached.service @@ -1713,12 +1393,12 @@ ExecStart=/usr/sbin/some-fancy-httpd-server [Install] WantedBy=multi-user.target - Alternatively, the administrator could - create a drop-in file - /etc/systemd/system/httpd.service.d/local.conf - with the following contents: + Alternatively, the administrator could create a drop-in + file + /etc/systemd/system/httpd.service.d/local.conf + with the following contents: - [Unit] + [Unit] After=memcached.service Requires=memcached.service # Reset all assertions and then re-add the condition we want @@ -1729,39 +1409,37 @@ AssertPathExists=/srv/www Nice=0 PrivateTmp=yes - Note that dependencies - (After=, etc.) cannot be - reset to an empty list, so dependencies can - only be added in drop-ins. If you want to - remove dependencies, you have to override the - entire unit. - - - - - See Also - - systemd1, - systemctl1, - systemd.special7, - systemd.service5, - systemd.socket5, - systemd.device5, - systemd.mount5, - systemd.automount5, - systemd.swap5, - systemd.target5, - systemd.path5, - systemd.timer5, - systemd.snapshot5, - systemd.scope5, - systemd.slice5, - systemd.time7, - systemd-analyze1, - capabilities7, - systemd.directives7, - uname1 - - + Note that dependencies (After=, etc.) + cannot be reset to an empty list, so dependencies can only be + added in drop-ins. If you want to remove dependencies, you have + to override the entire unit. + + + + + See Also + + systemd1, + systemctl1, + systemd.special7, + systemd.service5, + systemd.socket5, + systemd.device5, + systemd.mount5, + systemd.automount5, + systemd.swap5, + systemd.target5, + systemd.path5, + systemd.timer5, + systemd.snapshot5, + systemd.scope5, + systemd.slice5, + systemd.time7, + systemd-analyze1, + capabilities7, + systemd.directives7, + uname1 + + diff --git a/man/systemd.xml b/man/systemd.xml index d020582b539..80591dc732a 100644 --- a/man/systemd.xml +++ b/man/systemd.xml @@ -1,6 +1,6 @@ + "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd"> - - - systemd - systemd - - - - Developer - Lennart - Poettering - lennart@poettering.net - - - - - - systemd - 1 - - - - systemd - init - systemd system and service manager - - - - - systemd OPTIONS - - - init OPTIONS COMMAND - - - - - Description - - systemd is a system and service manager for - Linux operating systems. When run as first process on - boot (as PID 1), it acts as init system that brings - up and maintains userspace services. - - For compatibility with SysV, if systemd is called - as init and a PID that is not - 1, it will execute telinit and pass - all command line arguments unmodified. That means - init and telinit - are mostly equivalent when invoked from normal login sessions. See - telinit8 - for more information. - - When run as a system instance, systemd interprets the - configuration file system.conf and the - files in system.conf.d directories; when - run as a user instance, systemd interprets the configuration - file user.conf and the files in - user.conf.d directories. See - systemd-system.conf5 - for more information. - - - - Options - - The following options are understood: - - - - - - Determine startup - sequence, dump it and exit. This is an - option useful for debugging - only. - - - - - Dump understood unit - configuration items. This outputs a - terse but complete list of - configuration items understood in unit - definition files. - - - - - Set default unit to - activate on startup. If not specified, - defaults to - default.target. - - - - - - For , - tell systemd to run a - system instance, even if the process ID is - not 1, i.e. systemd is not run as init process. - does the opposite, - running a user instance even if the process - ID is 1. - Normally it should not be necessary to - pass these options, as systemd - automatically detects the mode it is - started in. These options are hence of - little use except for debugging. Note - that it is not supported booting and - maintaining a full system with systemd - running in - mode, but PID not 1. In practice, - passing explicitly is - only useful in conjunction with - . - - - - - Dump core on - crash. This switch has no effect when - run as user - instance. - - - - - Run shell on - crash. This switch has no effect when - run as user - instance. - - - - - Ask for confirmation - when spawning processes. This switch - has no effect when run as user - instance. - - - - - Show terse service - status information while booting. This - switch has no effect when run as user - instance. Takes a boolean argument - which may be omitted which is - interpreted as - . - - - - - Set log - target. Argument must be one of - , - , - , - , - . - - - - - Set log level. As - argument this accepts a numerical log - level or the well-known syslog3 - symbolic names (lowercase): - , - , - , - , - , - , - , - . - - - - - Highlight important - log messages. Argument is a boolean - value. If the argument is omitted, it - defaults to - . - - - - - Include code location - in log messages. This is mostly - relevant for debugging - purposes. Argument is a boolean - value. If the argument is omitted - it defaults to - . - - - - - - Sets the default - output or error output for all - services and sockets, respectively. That is, controls - the default for - - and - (see - systemd.exec5 - for details). Takes one of - , - , - , - , - , - , - , - , - . If the - argument is omitted - - defaults to - and - - to - . - - - - - - - - - Concepts - - systemd provides a dependency system between - various entities called "units" of 12 different - types. Units encapsulate various objects that are - relevant for system boot-up and maintenance. The - majority of units are configured in unit configuration - files, whose syntax and basic set of options is - described in - systemd.unit5, - however some are created automatically from other - configuration, dynamically from system state or - programmatically at runtime. Units may be "active" - (meaning started, bound, plugged in, ..., depending on - the unit type, see below), or "inactive" (meaning - stopped, unbound, unplugged, ...), as well as in the - process of being activated or deactivated, - i.e. between the two states (these states are called - "activating", "deactivating"). A special "failed" - state is available as well, which is very similar to - "inactive" and is entered when the service failed in - some way (process returned error code on exit, or - crashed, or an operation timed out). If this state is - entered, the cause will be logged, for later - reference. Note that the various unit types may have a - number of additional substates, which are mapped to - the five generalized unit states described - here. - - The following unit types are available: - - - Service units, which start and control - daemons and the processes they consist of. For - details see - systemd.service5. - - Socket units, which - encapsulate local IPC or network sockets in - the system, useful for socket-based - activation. For details about socket units see - systemd.socket5, - for details on socket-based activation and - other forms of activation, see - daemon7. - - Target units are useful to - group units, or provide well-known - synchronization points during boot-up, see - systemd.target5. - - Device units expose kernel - devices in systemd and may be used to - implement device-based activation. For details - see - systemd.device5. - - Mount units control mount - points in the file system, for details see - systemd.mount5. - - Automount units provide - automount capabilities, for on-demand mounting - of file systems as well as parallelized - boot-up. See - systemd.automount5. - - Snapshot units can be used to - temporarily save the state of the set of - systemd units, which later may be restored by - activating the saved snapshot unit. For more - information see - systemd.snapshot5. - - Timer units are useful for - triggering activation of other units based on - timers. You may find details in - systemd.timer5. - - Swap units are very similar to - mount units and encapsulate memory swap - partitions or files of the operating - system. They are described in systemd.swap5. - - Path units may be used - to activate other services when file system - objects change or are modified. See - systemd.path5. - - Slice units may be used to - group units which manage system processes - (such as service and scope units) in a - hierarchical tree for resource management - purposes. See - systemd.slice5. - - Scope units are similar to - service units, but manage foreign processes - instead of starting them as well. See - systemd.scope5. - - - - Units are named as their configuration - files. Some units have special semantics. A detailed - list is available in - systemd.special7. - - systemd knows various kinds of dependencies, - including positive and negative requirement - dependencies (i.e. Requires= and - Conflicts=) as well as ordering - dependencies (After= and - Before=). NB: ordering and - requirement dependencies are orthogonal. If only a - requirement dependency exists between two units - (e.g. foo.service requires - bar.service), but no ordering - dependency (e.g. foo.service - after bar.service) and both are - requested to start, they will be started in - parallel. It is a common pattern that both requirement - and ordering dependencies are placed between two - units. Also note that the majority of dependencies are - implicitly created and maintained by systemd. In most - cases, it should be unnecessary to declare additional - dependencies manually, however it is possible to do - this. - - Application programs and units (via - dependencies) may request state changes of units. In - systemd, these requests are encapsulated as 'jobs' and - maintained in a job queue. Jobs may succeed or can - fail, their execution is ordered based on the ordering - dependencies of the units they have been scheduled - for. - - On boot systemd activates the target unit - default.target whose job is to - activate on-boot services and other on-boot units by - pulling them in via dependencies. Usually the unit - name is just an alias (symlink) for either - graphical.target (for - fully-featured boots into the UI) or - multi-user.target (for limited - console-only boots for use in embedded or server - environments, or similar; a subset of - graphical.target). However, it is at the discretion of - the administrator to configure it as an alias to any - other target unit. See - systemd.special7 - for details about these target units. - - Processes systemd spawns are placed in - individual Linux control groups named after the unit - which they belong to in the private systemd - hierarchy. (see cgroups.txt - for more information about control groups, or short - "cgroups"). systemd uses this to effectively keep - track of processes. Control group information is - maintained in the kernel, and is accessible via the - file system hierarchy (beneath - /sys/fs/cgroup/systemd/), or in tools - such as - ps1 - (ps xawf -eo pid,user,cgroup,args - is particularly useful to list all processes and the - systemd units they belong to.). - - systemd is compatible with the SysV init system - to a large degree: SysV init scripts are supported and - simply read as an alternative (though limited) - configuration file format. The SysV - /dev/initctl interface is - provided, and compatibility implementations of the - various SysV client tools are available. In addition to - that, various established Unix functionality such as - /etc/fstab or the - utmp database are - supported. - - systemd has a minimal transaction system: if a - unit is requested to start up or shut down it will add - it and all its dependencies to a temporary - transaction. Then, it will verify if the transaction - is consistent (i.e. whether the ordering of all units - is cycle-free). If it is not, systemd will try to fix - it up, and removes non-essential jobs from the - transaction that might remove the loop. Also, systemd - tries to suppress non-essential jobs in the - transaction that would stop a running service. Finally - it is checked whether the jobs of the transaction - contradict jobs that have already been queued, and - optionally the transaction is aborted then. If all - worked out and the transaction is consistent and - minimized in its impact it is merged with all already - outstanding jobs and added to the run - queue. Effectively this means that before executing a - requested operation, systemd will verify that it makes - sense, fixing it if possible, and only failing if it - really cannot work. - - Systemd contains native implementations of - various tasks that need to be executed as part of the - boot process. For example, it sets the hostname or - configures the loopback network device. It also sets - up and mounts various API file systems, such as - /sys or - /proc. - - For more information about the concepts and - ideas behind systemd, please refer to the Original - Design Document. - - Note that some but not all interfaces provided - by systemd are covered by the Interface - Stability Promise. - - Units may be generated dynamically at boot and - system manager reload time, for example based on other - configuration files or parameters passed on the kernel - command line. For details see the Generators - Specification. - - Systems which invoke systemd in a container - or initrd environment should implement the - Container - Interface or initrd - Interface specifications, respectively. - - - - Directories - - - - System unit directories - - The systemd system - manager reads unit configuration from - various directories. Packages that - want to install unit files shall place - them in the directory returned by - pkg-config systemd - --variable=systemdsystemunitdir. Other - directories checked are - /usr/local/lib/systemd/system - and - /usr/lib/systemd/system. User - configuration always takes - precedence. pkg-config - systemd - --variable=systemdsystemconfdir - returns the path of the system - configuration directory. Packages - should alter the content of these - directories only with the - enable and - disable commands of - the - systemctl1 - tool. Full list of directories is provided in - systemd.unit5. - - - - - - - User unit directories - - Similar rules apply - for the user unit - directories. However, here the XDG - Base Directory specification - is followed to find - units. Applications should place their - unit files in the directory returned - by pkg-config systemd - --variable=systemduserunitdir. Global - configuration is done in the directory - reported by pkg-config - systemd - --variable=systemduserconfdir. The - enable and - disable commands of - the - systemctl1 - tool can handle both global (i.e. for - all users) and private (for one user) - enabling/disabling of - units. Full list of directories is provided in - systemd.unit5. - - - - - - - SysV init scripts directory - - The location of the - SysV init script directory varies - between distributions. If systemd - cannot find a native unit file for a - requested service, it will look for a - SysV init script of the same name - (with the - .service suffix - removed). - - - - - - SysV runlevel link farm directory - - The location of the - SysV runlevel link farm directory - varies between distributions. systemd - will take the link farm into account - when figuring out whether a service - shall be enabled. Note that a service - unit with a native unit configuration - file cannot be started by activating it - in the SysV runlevel link - farm. - - - - - - Signals - - - - SIGTERM - - Upon receiving this - signal the systemd system manager - serializes its state, reexecutes - itself and deserializes the saved - state again. This is mostly equivalent - to systemctl - daemon-reexec. - - systemd user managers will - start the - exit.target unit - when this signal is received. This is - mostly equivalent to - systemctl --user start - exit.target. - - - - SIGINT - - Upon receiving this - signal the systemd system manager will - start the - ctrl-alt-del.target - unit. This is mostly equivalent to - systemctl start - ctl-alt-del.target. If this - signal is received more often than 7 - times per 2s an immediate reboot is - triggered. Note that pressing - Ctrl-Alt-Del on the console will - trigger this signal. Hence, if a - reboot is hanging pressing - Ctrl-Alt-Del more than 7 times in 2s - is a relatively safe way to trigger an - immediate reboot. - - systemd user managers - treat this signal the same way as - SIGTERM. - - - - SIGWINCH - - When this signal is - received the systemd system manager - will start the - kbrequest.target - unit. This is mostly equivalent to - systemctl start - kbrequest.target. - - This signal is ignored by - systemd user - managers. - - - - SIGPWR - - When this signal is - received the systemd manager - will start the - sigpwr.target - unit. This is mostly equivalent to - systemctl start - sigpwr.target. - - - - SIGUSR1 - - When this signal is - received the systemd manager will try - to reconnect to the D-Bus - bus. - - - - SIGUSR2 - - When this signal is - received the systemd manager will log - its complete state in human readable - form. The data logged is the same as - printed by systemd-analyze - dump. - - - - SIGHUP - - Reloads the complete - daemon configuration. This is mostly - equivalent to systemctl - daemon-reload. - - - - SIGRTMIN+0 - - Enters default mode, starts the - default.target - unit. This is mostly equivalent to - systemctl start - default.target. - - - - SIGRTMIN+1 - - Enters rescue mode, - starts the - rescue.target - unit. This is mostly equivalent to - systemctl isolate - rescue.target. - - - - SIGRTMIN+2 - - Enters emergency mode, - starts the - emergency.service - unit. This is mostly equivalent to - systemctl isolate - emergency.service. - - - - SIGRTMIN+3 - - Halts the machine, - starts the - halt.target - unit. This is mostly equivalent to - systemctl start - halt.target. - - - - SIGRTMIN+4 - - Powers off the machine, - starts the - poweroff.target - unit. This is mostly equivalent to - systemctl start - poweroff.target. - - - - SIGRTMIN+5 - - Reboots the machine, - starts the - reboot.target - unit. This is mostly equivalent to - systemctl start - reboot.target. - - - - SIGRTMIN+6 - - Reboots the machine via kexec, - starts the - kexec.target - unit. This is mostly equivalent to - systemctl start - kexec.target. - - - - SIGRTMIN+13 - - Immediately halts the machine. - - - - SIGRTMIN+14 - - Immediately powers off the machine. - - - - SIGRTMIN+15 - - Immediately reboots the machine. - - - - SIGRTMIN+16 - - Immediately reboots the machine with kexec. - - - - SIGRTMIN+20 - - Enables display of - status messages on the console, as - controlled via - systemd.show_status=1 - on the kernel command - line. - - - - SIGRTMIN+21 - - Disables display of - status messages on the console, as - controlled via - systemd.show_status=0 - on the kernel command - line. - - - - SIGRTMIN+22 - SIGRTMIN+23 - - Sets the log level to - debug - (or info on - SIGRTMIN+23), as - controlled via - systemd.log_level=debug - (or systemd.log_level=info - on SIGRTMIN+23) on - the kernel command - line. - - - - SIGRTMIN+24 - - Immediately exits the - manager (only available for --user - instances). - - - - SIGRTMIN+26 - SIGRTMIN+27 - SIGRTMIN+28 - - Sets the log level to - journal-or-kmsg (or - console on - SIGRTMIN+27, - kmsg on - SIGRTMIN+28), as - controlled via - systemd.log_target=journal-or-kmsg - (or - systemd.log_target=console - on SIGRTMIN+27 or - systemd.log_target=kmsg - on SIGRTMIN+28) - on the kernel command - line. - - - - - - Environment - - - - $SYSTEMD_LOG_LEVEL - systemd reads the - log level from this environment - variable. This can be overridden with - . - - - - $SYSTEMD_LOG_TARGET - systemd reads the - log target from this environment - variable. This can be overridden with - . - - - - $SYSTEMD_LOG_COLOR - Controls whether - systemd highlights important log - messages. This can be overridden with - . - - - - $SYSTEMD_LOG_LOCATION - Controls whether - systemd prints the code location along - with log messages. This can be - overridden with - . - - - - $XDG_CONFIG_HOME - $XDG_CONFIG_DIRS - $XDG_DATA_HOME - $XDG_DATA_DIRS - - The systemd user - manager uses these variables in - accordance to the XDG - Base Directory specification - to find its configuration. - - - - $SYSTEMD_UNIT_PATH - - Controls where systemd - looks for unit - files. - - - - $SYSTEMD_SYSVINIT_PATH - - Controls where systemd - looks for SysV init scripts. - - - - $SYSTEMD_SYSVRCND_PATH - - Controls where systemd - looks for SysV init script runlevel link - farms. - - - - $LISTEN_PID - $LISTEN_FDS - - Set by systemd for - supervised processes during - socket-based activation. See - sd_listen_fds3 - for more information. - - - - - $NOTIFY_SOCKET - - Set by systemd for - supervised processes for status and - start-up completion notification. See - sd_notify3 - for more information. - - - - - - - Kernel Command Line - - When run as system instance systemd parses a - number of kernel command line - argumentsIf run inside a Linux - container these arguments may be passed as command - line arguments to systemd itself, next to any of the - command line options listed in the Options section - above. If run outside of Linux containers, these - arguments are parsed from - /proc/cmdline - instead.: - - - - systemd.unit= - rd.systemd.unit= - - Overrides the unit to - activate on boot. Defaults to - default.target. This - may be used to temporarily boot into a - different boot unit, for example - rescue.target or - emergency.service. See - systemd.special7 - for details about these units. The - option prefixed with - rd. is honored - only in the initial RAM disk (initrd), - while the one that is not prefixed only - in the main system. - - - - systemd.dump_core= - - Takes a boolean - argument. If , - systemd dumps core when it - crashes. Otherwise, no core dump is - created. Defaults to - . - - - - systemd.crash_shell= - - Takes a boolean - argument. If , - systemd spawns a shell when it - crashes. Otherwise, no shell is - spawned. Defaults to - , for security - reasons, as the shell is not protected - by any password - authentication. - - - - systemd.crash_chvt= - - Takes an integer - argument. If positive systemd - activates the specified virtual - terminal when it crashes. Defaults to - -1. - - - - systemd.confirm_spawn= - - Takes a boolean - argument. If , - asks for confirmation when spawning - processes. Defaults to - . - - - - systemd.show_status= - - Takes a boolean - argument or the constant - auto. If - , shows terse - service status updates on the console - during bootup. - auto behaves like - until a service - fails or there is a significant delay - in boot. Defaults to - , unless - is passed as - kernel command line option in which - case it defaults to - auto. - - - - systemd.log_target= - systemd.log_level= - systemd.log_color= - systemd.log_location= - - Controls log output, - with the same effect as the - $SYSTEMD_LOG_TARGET, $SYSTEMD_LOG_LEVEL, $SYSTEMD_LOG_COLOR, $SYSTEMD_LOG_LOCATION - environment variables described above. - - - - systemd.default_standard_output= - systemd.default_standard_error= - Controls default - standard output and error output for - services, with the same effect as the - - and - command line arguments described - above, respectively. - - - - systemd.setenv= - - Takes a string - argument in the form VARIABLE=VALUE. - May be used to set default environment - variables to add to forked child processes. - May be used more than once to set multiple - variables. - - - - quiet - - Turn off - status output at boot, much like - systemd.show_status=false - would. Note that this option is also - read by the kernel itself and disables - kernel log output. Passing this option - hence turns off the usual output from - both the system manager and the kernel. - - - - - debug - - Turn on debugging - output. This is equivalent to - systemd.log_level=debug. - Note that this option is also read by - the kernel itself and enables kernel - debug output. Passing this option - hence turns on the debug output from - both the system manager and the - kernel. - - - - emergency - -b - - Boot into emergency - mode. This is equivalent to - systemd.unit=emergency.target - and provided for compatibility reasons - and to be easier to - type. - - - - rescue - single - s - S - 1 - - Boot into rescue - mode. This is equivalent to - systemd.unit=rescue.target - and provided for compatibility reasons - and to be easier to - type. - - - - 2 - 3 - 4 - 5 - - Boot into the - specified legacy SysV runlevel. These - are equivalent to - systemd.unit=runlevel2.target, - systemd.unit=runlevel3.target, - systemd.unit=runlevel4.target, - and systemd.unit=runlevel5.target, respectively, - and provided for compatibility reasons - and to be easier to - type. - - - - locale.LANG= - locale.LANGUAGE= - locale.LC_CTYPE= - locale.LC_NUMERIC= - locale.LC_TIME= - locale.LC_COLLATE= - locale.LC_MONETARY= - locale.LC_MESSAGES= - locale.LC_PAPER= - locale.LC_NAME= - locale.LC_ADDRESS= - locale.LC_TELEPHONE= - locale.LC_MEASUREMENT= - locale.LC_IDENTIFICATION= - - Set the system locale - to use. This overrides the settings in - /etc/locale.conf. For - more information see - locale.conf5 - and - locale7. - - - - - For other kernel command line parameters - understood by components of the core OS, please refer - to - kernel-command-line7. - - - - Sockets and FIFOs - - - - /run/systemd/notify - - Daemon status - notification socket. This is an - AF_UNIX datagram socket and is used to - implement the daemon notification - logic as implemented by - sd_notify3. - - - - - /run/systemd/shutdownd - - Used internally by the - shutdown8 - tool to implement delayed - shutdowns. This is an AF_UNIX datagram - socket. - - - - /run/systemd/private - - Used internally as - communication channel between - systemctl1 - and the systemd process. This is an - AF_UNIX stream socket. This interface - is private to systemd and should not - be used in external - projects. - - - - /dev/initctl - - Limited compatibility - support for the SysV client interface, - as implemented by the - systemd-initctl.service - unit. This is a named pipe in the file - system. This interface is obsolete and - should not be used in new - applications. - - - - - - See Also - - The systemd Homepage, - systemd-system.conf5, - locale.conf5, - systemctl1, - journalctl1, - systemd-notify1, - daemon7, - sd-daemon3, - systemd.unit5, - systemd.special5, - pkg-config1, - kernel-command-line7, - bootup7, - systemd.directives7 - - + xmlns:xi="http://www.w3.org/2001/XInclude"> + + + systemd + systemd + + + + Developer + Lennart + Poettering + lennart@poettering.net + + + + + + systemd + 1 + + + + systemd + init + systemd system and service manager + + + + + systemd OPTIONS + + + init OPTIONS COMMAND + + + + + Description + + systemd is a system and service manager for Linux operating + systems. When run as first process on boot (as PID 1), it acts as + init system that brings up and maintains userspace + services. + + For compatibility with SysV, if systemd is called as + init and a PID that is not 1, it will execute + telinit and pass all command line arguments + unmodified. That means init and + telinit are mostly equivalent when invoked from + normal login sessions. See + telinit8 + for more information. + + When run as a system instance, systemd interprets the + configuration file system.conf and the files + in system.conf.d directories; when run as a + user instance, systemd interprets the configuration file + user.conf and the files in + user.conf.d directories. See + systemd-system.conf5 + for more information. + + + + Options + + The following options are understood: + + + + + + Determine startup sequence, dump it and exit. + This is an option useful for debugging only. + + + + + Dump understood unit configuration items. This + outputs a terse but complete list of configuration items + understood in unit definition files. + + + + + Set default unit to activate on startup. If + not specified, defaults to + default.target. + + + + + + For , tell systemd to + run a system instance, even if the process ID is not 1, i.e. + systemd is not run as init process. + does the opposite, running a user instance even if the process + ID is 1. Normally it should not be necessary to pass these + options, as systemd automatically detects the mode it is + started in. These options are hence of little use except for + debugging. Note that it is not supported booting and + maintaining a full system with systemd running in + mode, but PID not 1. In practice, + passing explicitly is only useful in + conjunction with . + + + + + Dump core on crash. This switch has no effect + when run as user instance. + + + + + Run shell on + crash. This switch has no effect when + run as user + instance. + + + + + Ask for confirmation when spawning processes. + This switch has no effect when run as user + instance. + + + + + Show terse service status information while + booting. This switch has no effect when run as user instance. + Takes a boolean argument which may be omitted which is + interpreted as . + + + + + Set log target. Argument must be one of + , + , + , + , + . + + + + + Set log level. As + argument this accepts a numerical log + level or the well-known syslog3 + symbolic names (lowercase): + , + , + , + , + , + , + , + . + + + + + Highlight important log messages. Argument is + a boolean value. If the argument is omitted, it defaults to + . + + + + + Include code location in log messages. This is + mostly relevant for debugging purposes. Argument is a boolean + value. If the argument is omitted it defaults to + . + + + + + + Sets the default output or error output for + all services and sockets, respectively. That is, controls the + default for and + (see + systemd.exec5 + for details). Takes one of + , + , + , + , + , + , + , + , + . If the + argument is omitted + defaults to + and + to + . + + + + + + + + + Concepts + + systemd provides a dependency system between various + entities called "units" of 12 different types. Units encapsulate + various objects that are relevant for system boot-up and + maintenance. The majority of units are configured in unit + configuration files, whose syntax and basic set of options is + described in + systemd.unit5, + however some are created automatically from other configuration, + dynamically from system state or programmatically at runtime. + Units may be "active" (meaning started, bound, plugged in, ..., + depending on the unit type, see below), or "inactive" (meaning + stopped, unbound, unplugged, ...), as well as in the process of + being activated or deactivated, i.e. between the two states (these + states are called "activating", "deactivating"). A special + "failed" state is available as well, which is very similar to + "inactive" and is entered when the service failed in some way + (process returned error code on exit, or crashed, or an operation + timed out). If this state is entered, the cause will be logged, + for later reference. Note that the various unit types may have a + number of additional substates, which are mapped to the five + generalized unit states described here. + + The following unit types are available: + + + Service units, which start and control daemons + and the processes they consist of. For details see + systemd.service5. + + Socket units, which encapsulate local IPC or + network sockets in the system, useful for socket-based + activation. For details about socket units see + systemd.socket5, + for details on socket-based activation and other forms of + activation, see + daemon7. + + Target units are useful to group units, or + provide well-known synchronization points during boot-up, see + systemd.target5. + + Device units expose kernel devices in systemd + and may be used to implement device-based activation. For + details see + systemd.device5. + + Mount units control mount points in the file + system, for details see + systemd.mount5. + + Automount units provide automount capabilities, + for on-demand mounting of file systems as well as parallelized + boot-up. See + systemd.automount5. + + Snapshot units can be used to temporarily save + the state of the set of systemd units, which later may be + restored by activating the saved snapshot unit. For more + information see + systemd.snapshot5. + + Timer units are useful for triggering activation + of other units based on timers. You may find details in + systemd.timer5. + + Swap units are very similar to mount units and + encapsulate memory swap partitions or files of the operating + system. They are described in + systemd.swap5. + + Path units may be used to activate other + services when file system objects change or are modified. See + systemd.path5. + + Slice units may be used to group units which + manage system processes (such as service and scope units) in a + hierarchical tree for resource management purposes. See + systemd.slice5. + + Scope units are similar to service units, but + manage foreign processes instead of starting them as well. See + systemd.scope5. + + + + Units are named as their configuration files. Some units + have special semantics. A detailed list is available in + systemd.special7. + + systemd knows various kinds of dependencies, including + positive and negative requirement dependencies (i.e. + Requires= and Conflicts=) as + well as ordering dependencies (After= and + Before=). NB: ordering and requirement + dependencies are orthogonal. If only a requirement dependency + exists between two units (e.g. foo.service + requires bar.service), but no ordering + dependency (e.g. foo.service after + bar.service) and both are requested to start, + they will be started in parallel. It is a common pattern that both + requirement and ordering dependencies are placed between two + units. Also note that the majority of dependencies are implicitly + created and maintained by systemd. In most cases, it should be + unnecessary to declare additional dependencies manually, however + it is possible to do this. + + Application programs and units (via dependencies) may + request state changes of units. In systemd, these requests are + encapsulated as 'jobs' and maintained in a job queue. Jobs may + succeed or can fail, their execution is ordered based on the + ordering dependencies of the units they have been scheduled + for. + + On boot systemd activates the target unit + default.target whose job is to activate + on-boot services and other on-boot units by pulling them in via + dependencies. Usually the unit name is just an alias (symlink) for + either graphical.target (for fully-featured + boots into the UI) or multi-user.target (for + limited console-only boots for use in embedded or server + environments, or similar; a subset of graphical.target). However, + it is at the discretion of the administrator to configure it as an + alias to any other target unit. See + systemd.special7 + for details about these target units. + + Processes systemd spawns are placed in individual Linux + control groups named after the unit which they belong to in the + private systemd hierarchy. (see cgroups.txt + for more information about control groups, or short "cgroups"). + systemd uses this to effectively keep track of processes. Control + group information is maintained in the kernel, and is accessible + via the file system hierarchy (beneath + /sys/fs/cgroup/systemd/), or in tools such as + ps1 + (ps xawf -eo pid,user,cgroup,args is + particularly useful to list all processes and the systemd units + they belong to.). + + systemd is compatible with the SysV init system to a large + degree: SysV init scripts are supported and simply read as an + alternative (though limited) configuration file format. The SysV + /dev/initctl interface is provided, and + compatibility implementations of the various SysV client tools are + available. In addition to that, various established Unix + functionality such as /etc/fstab or the + utmp database are supported. + + systemd has a minimal transaction system: if a unit is + requested to start up or shut down it will add it and all its + dependencies to a temporary transaction. Then, it will verify if + the transaction is consistent (i.e. whether the ordering of all + units is cycle-free). If it is not, systemd will try to fix it up, + and removes non-essential jobs from the transaction that might + remove the loop. Also, systemd tries to suppress non-essential + jobs in the transaction that would stop a running service. Finally + it is checked whether the jobs of the transaction contradict jobs + that have already been queued, and optionally the transaction is + aborted then. If all worked out and the transaction is consistent + and minimized in its impact it is merged with all already + outstanding jobs and added to the run queue. Effectively this + means that before executing a requested operation, systemd will + verify that it makes sense, fixing it if possible, and only + failing if it really cannot work. + + Systemd contains native implementations of various tasks + that need to be executed as part of the boot process. For example, + it sets the hostname or configures the loopback network device. It + also sets up and mounts various API file systems, such as + /sys or /proc. + + For more information about the concepts and + ideas behind systemd, please refer to the + Original Design Document. + + Note that some but not all interfaces provided + by systemd are covered by the + Interface + Stability Promise. + + Units may be generated dynamically at boot and system + manager reload time, for example based on other configuration + files or parameters passed on the kernel command line. For details + see the + Generators Specification. + + Systems which invoke systemd in a container or initrd + environment should implement the + Container Interface or + initrd Interface + specifications, respectively. + + + + Directories + + + + System unit directories + + The systemd system manager reads unit + configuration from various directories. Packages that want to + install unit files shall place them in the directory returned + by pkg-config systemd + --variable=systemdsystemunitdir. Other directories + checked are /usr/local/lib/systemd/system + and /usr/lib/systemd/system. User + configuration always takes precedence. pkg-config + systemd --variable=systemdsystemconfdir returns the + path of the system configuration directory. Packages should + alter the content of these directories only with the + enable and disable + commands of the + systemctl1 + tool. Full list of directories is provided in + systemd.unit5. + + + + + + + User unit directories + + Similar rules apply for the user unit + directories. However, here the + XDG + Base Directory specification is followed to find + units. Applications should place their unit files in the + directory returned by pkg-config systemd + --variable=systemduserunitdir. Global configuration + is done in the directory reported by pkg-config + systemd --variable=systemduserconfdir. The + enable and disable + commands of the + systemctl1 + tool can handle both global (i.e. for all users) and private + (for one user) enabling/disabling of units. Full list of + directories is provided in + systemd.unit5. + + + + + + + SysV init scripts directory + + The location of the SysV init script directory + varies between distributions. If systemd cannot find a native + unit file for a requested service, it will look for a SysV + init script of the same name (with the + .service suffix + removed). + + + + + + SysV runlevel link farm directory + + The location of the SysV runlevel link farm + directory varies between distributions. systemd will take the + link farm into account when figuring out whether a service + shall be enabled. Note that a service unit with a native unit + configuration file cannot be started by activating it in the + SysV runlevel link farm. + + + + + + Signals + + + + SIGTERM + + Upon receiving this signal the systemd system + manager serializes its state, reexecutes itself and + deserializes the saved state again. This is mostly equivalent + to systemctl daemon-reexec. + + systemd user managers will start the + exit.target unit when this signal is + received. This is mostly equivalent to systemctl + --user start exit.target. + + + + SIGINT + + Upon receiving this signal the systemd system + manager will start the + ctrl-alt-del.target unit. This is mostly + equivalent to systemctl start + ctl-alt-del.target. If this signal is received more + often than 7 times per 2s an immediate reboot is triggered. + Note that pressing Ctrl-Alt-Del on the console will trigger + this signal. Hence, if a reboot is hanging pressing + Ctrl-Alt-Del more than 7 times in 2s is a relatively safe way + to trigger an immediate reboot. + + systemd user managers treat this signal the same way as + SIGTERM. + + + + SIGWINCH + + When this signal is received the systemd + system manager will start the + kbrequest.target unit. This is mostly + equivalent to systemctl start + kbrequest.target. + + This signal is ignored by systemd user + managers. + + + + SIGPWR + + When this signal is received the systemd + manager will start the sigpwr.target + unit. This is mostly equivalent to systemctl start + sigpwr.target. + + + + SIGUSR1 + + When this signal is received the systemd + manager will try to reconnect to the D-Bus + bus. + + + + SIGUSR2 + + When this signal is received the systemd + manager will log its complete state in human readable form. + The data logged is the same as printed by + systemd-analyze dump. + + + + SIGHUP + + Reloads the complete daemon configuration. + This is mostly equivalent to systemctl + daemon-reload. + + + + SIGRTMIN+0 + + Enters default mode, starts the + default.target unit. This is mostly + equivalent to systemctl start + default.target. + + + + SIGRTMIN+1 + + Enters rescue mode, starts the + rescue.target unit. This is mostly + equivalent to systemctl isolate + rescue.target. + + + + SIGRTMIN+2 + + Enters emergency mode, starts the + emergency.service unit. This is mostly + equivalent to systemctl isolate + emergency.service. + + + + SIGRTMIN+3 + + Halts the machine, starts the + halt.target unit. This is mostly + equivalent to systemctl start + halt.target. + + + + SIGRTMIN+4 + + Powers off the machine, starts the + poweroff.target unit. This is mostly + equivalent to systemctl start + poweroff.target. + + + + SIGRTMIN+5 + + Reboots the machine, starts the + reboot.target unit. This is mostly + equivalent to systemctl start + reboot.target. + + + + SIGRTMIN+6 + + Reboots the machine via kexec, starts the + kexec.target unit. This is mostly + equivalent to systemctl start + kexec.target. + + + + SIGRTMIN+13 + + Immediately halts the machine. + + + + SIGRTMIN+14 + + Immediately powers off the machine. + + + + SIGRTMIN+15 + + Immediately reboots the machine. + + + + SIGRTMIN+16 + + Immediately reboots the machine with kexec. + + + + SIGRTMIN+20 + + Enables display of status messages on the + console, as controlled via + systemd.show_status=1 on the kernel command + line. + + + + SIGRTMIN+21 + + Disables display of + status messages on the console, as + controlled via + systemd.show_status=0 + on the kernel command + line. + + + + SIGRTMIN+22 + SIGRTMIN+23 + + Sets the log level to debug + (or info on + SIGRTMIN+23), as controlled via + systemd.log_level=debug (or + systemd.log_level=info on + SIGRTMIN+23) on the kernel command + line. + + + + SIGRTMIN+24 + + Immediately exits the manager (only available + for --user instances). + + + + SIGRTMIN+26 + SIGRTMIN+27 + SIGRTMIN+28 + + Sets the log level to + journal-or-kmsg (or + console on + SIGRTMIN+27, kmsg on + SIGRTMIN+28), as controlled via + systemd.log_target=journal-or-kmsg (or + systemd.log_target=console on + SIGRTMIN+27 or + systemd.log_target=kmsg on + SIGRTMIN+28) on the kernel command + line. + + + + + + Environment + + + + $SYSTEMD_LOG_LEVEL + systemd reads the log level from this + environment variable. This can be overridden with + . + + + + $SYSTEMD_LOG_TARGET + systemd reads the log target from this + environment variable. This can be overridden with + . + + + + $SYSTEMD_LOG_COLOR + Controls whether systemd highlights important + log messages. This can be overridden with + . + + + + $SYSTEMD_LOG_LOCATION + Controls whether systemd prints the code + location along with log messages. This can be overridden with + . + + + + $XDG_CONFIG_HOME + $XDG_CONFIG_DIRS + $XDG_DATA_HOME + $XDG_DATA_DIRS + + The systemd user manager uses these variables + in accordance to the XDG + Base Directory specification to find its + configuration. + + + + $SYSTEMD_UNIT_PATH + + Controls where systemd looks for unit + files. + + + + $SYSTEMD_SYSVINIT_PATH + + Controls where systemd looks for SysV init + scripts. + + + + $SYSTEMD_SYSVRCND_PATH + + Controls where systemd looks for SysV init + script runlevel link farms. + + + + $LISTEN_PID + $LISTEN_FDS + + Set by systemd for supervised processes during + socket-based activation. See + sd_listen_fds3 + for more information. + + + + $NOTIFY_SOCKET + + Set by systemd for supervised processes for + status and start-up completion notification. See + sd_notify3 + for more information. + + + + + + Kernel Command Line + + When run as system instance systemd parses a number of + kernel command line argumentsIf run inside a Linux + container these arguments may be passed as command line arguments + to systemd itself, next to any of the command line options listed + in the Options section above. If run outside of Linux containers, + these arguments are parsed from /proc/cmdline + instead.: + + + + systemd.unit= + rd.systemd.unit= + + Overrides the unit to activate on boot. + Defaults to default.target. This may be + used to temporarily boot into a different boot unit, for + example rescue.target or + emergency.service. See + systemd.special7 + for details about these units. The option prefixed with + rd. is honored only in the initial RAM disk + (initrd), while the one that is not prefixed only in the main + system. + + + + systemd.dump_core= + + Takes a boolean argument. If + , systemd dumps core when it crashes. + Otherwise, no core dump is created. Defaults to + . + + + + systemd.crash_shell= + + Takes a boolean argument. If + , systemd spawns a shell when it crashes. + Otherwise, no shell is spawned. Defaults to + , for security reasons, as the shell is + not protected by any password + authentication. + + + + systemd.crash_chvt= + + Takes an integer argument. If positive systemd + activates the specified virtual terminal when it crashes. + Defaults to -1. + + + + systemd.confirm_spawn= + + Takes a boolean argument. If + , asks for confirmation when spawning + processes. Defaults to + . + + + + systemd.show_status= + + Takes a boolean argument or the constant + auto. If , shows + terse service status updates on the console during bootup. + auto behaves like + until a service fails or there is a significant delay in boot. + Defaults to , unless + is passed as kernel command line option + in which case it defaults to + auto. + + + + systemd.log_target= + systemd.log_level= + systemd.log_color= + systemd.log_location= + + Controls log output, with the same effect as + the $SYSTEMD_LOG_TARGET, + $SYSTEMD_LOG_LEVEL, + $SYSTEMD_LOG_COLOR, + $SYSTEMD_LOG_LOCATION environment variables + described above. + + + + systemd.default_standard_output= + systemd.default_standard_error= + Controls default standard output and error + output for services, with the same effect as the + and + command line + arguments described above, respectively. + + + + systemd.setenv= + + Takes a string argument in the form + VARIABLE=VALUE. May be used to set default environment + variables to add to forked child processes. May be used more + than once to set multiple variables. + + + + quiet + + Turn off status output at boot, much like + systemd.show_status=false would. Note that + this option is also read by the kernel itself and disables + kernel log output. Passing this option hence turns off the + usual output from both the system manager and the kernel. + + + + + debug + + Turn on debugging output. This is equivalent + to systemd.log_level=debug. Note that this + option is also read by the kernel itself and enables kernel + debug output. Passing this option hence turns on the debug + output from both the system manager and the + kernel. + + + + emergency + -b + + Boot into emergency mode. This is equivalent + to systemd.unit=emergency.target and + provided for compatibility reasons and to be easier to + type. + + + + rescue + single + s + S + 1 + + Boot into rescue mode. This is equivalent to + systemd.unit=rescue.target and provided for + compatibility reasons and to be easier to + type. + + + + 2 + 3 + 4 + 5 + + Boot into the specified legacy SysV runlevel. + These are equivalent to + systemd.unit=runlevel2.target, + systemd.unit=runlevel3.target, + systemd.unit=runlevel4.target, and + systemd.unit=runlevel5.target, + respectively, and provided for compatibility reasons and to be + easier to type. + + + + locale.LANG= + locale.LANGUAGE= + locale.LC_CTYPE= + locale.LC_NUMERIC= + locale.LC_TIME= + locale.LC_COLLATE= + locale.LC_MONETARY= + locale.LC_MESSAGES= + locale.LC_PAPER= + locale.LC_NAME= + locale.LC_ADDRESS= + locale.LC_TELEPHONE= + locale.LC_MEASUREMENT= + locale.LC_IDENTIFICATION= + + Set the system locale to use. This overrides + the settings in /etc/locale.conf. For + more information see + locale.conf5 + and + locale7. + + + + + For other kernel command line parameters understood by + components of the core OS, please refer to + kernel-command-line7. + + + + Sockets and FIFOs + + + + /run/systemd/notify + + Daemon status notification socket. This is an + AF_UNIX datagram socket and is used to + implement the daemon notification logic as implemented by + sd_notify3. + + + + + /run/systemd/shutdownd + + Used internally by the + shutdown8 + tool to implement delayed shutdowns. This is an + AF_UNIX datagram + socket. + + + + /run/systemd/private + + Used internally as communication channel + between + systemctl1 + and the systemd process. This is an + AF_UNIX stream socket. This interface is + private to systemd and should not be used in external + projects. + + + + /dev/initctl + + Limited compatibility support for the SysV + client interface, as implemented by the + systemd-initctl.service unit. This is a + named pipe in the file system. This interface is obsolete and + should not be used in new applications. + + + + + + See Also + + The systemd Homepage, + systemd-system.conf5, + locale.conf5, + systemctl1, + journalctl1, + systemd-notify1, + daemon7, + sd-daemon3, + systemd.unit5, + systemd.special5, + pkg-config1, + kernel-command-line7, + bootup7, + systemd.directives7 + + diff --git a/man/sysusers.d.xml b/man/sysusers.d.xml index ac2db98853a..99aa07a1ccb 100644 --- a/man/sysusers.d.xml +++ b/man/sysusers.d.xml @@ -20,245 +20,204 @@ along with systemd; If not, see . --> - - - sysusers.d - systemd - - - - Developer - Lennart - Poettering - lennart@poettering.net - - - - - - sysusers.d - 5 - - - - sysusers.d - Declarative allocation of system users and groups - - - - /usr/lib/sysusers.d/*.conf - - - - Description - - systemd-sysusers uses the - files from sysusers.d directory - to create system users and groups at package - installation or boot time. This tool may be used to - allocate system users and groups only, it is not - useful for creating non-system users and groups, as it - accesses /etc/passwd and - /etc/group directly, bypassing - any more complex user databases, for example any - database involving NIS or LDAP. - - - - Configuration Format - - Each configuration file shall be named in the - style of - package.conf - or - package-part.conf. - The second variant should be used when it is desirable - to make it easy to override just this part of - configuration. - - The file format is one line per user or group - containing name, ID, GECOS field description and home directory: - - # Type Name ID GECOS + xmlns:xi="http://www.w3.org/2001/XInclude"> + + + sysusers.d + systemd + + + + Developer + Lennart + Poettering + lennart@poettering.net + + + + + + sysusers.d + 5 + + + + sysusers.d + Declarative allocation of system users and groups + + + + /usr/lib/sysusers.d/*.conf + + + + Description + + systemd-sysusers uses the files from + sysusers.d directory to create system users + and groups at package installation or boot time. This tool may be + used to allocate system users and groups only, it is not useful + for creating non-system users and groups, as it accesses + /etc/passwd and + /etc/group directly, bypassing any more + complex user databases, for example any database involving NIS or + LDAP. + + + + Configuration Format + + Each configuration file shall be named in the style of + package.conf or + package-part.conf. + The second variant should be used when it is desirable to make it + easy to override just this part of configuration. + + The file format is one line per user or group containing + name, ID, GECOS field description and home directory: + + # Type Name ID GECOS u httpd 440 "HTTP User" u authd /usr/bin/authd "Authorization user" g input - - m authd input u root 0 "Superuser" /root - - Type - - The type consists of a single - letter. The following line types are - understood: - - - - u - Create a - system user and group of the - specified name should they not - exist yet. The user's primary - group will be set to the group - bearing the same name. The - user's shell will be set to - /sbin/nologin, - the home directory to the - specified home directory, or - / if none - is given. The account will be - created disabled, so that - logins are not - allowed. - - - - g - Create a - system group of the specified - name should it not exist - yet. Note that - u - implicitly create a matching - group. The group will be - created with no password - set. - - - - m - Add a user to - a group. If the user or group - are not existing yet, they - will be implicitly - created. - - - - r - Add a range of - numeric UIDs/GIDs to the pool - to allocate new UIDs and GIDs - from. If no line of this type - is specified the range of - UIDs/GIDs is set to some - compiled-in default. Note that - both UIDs and GIDs are - allocated from the same pool, - in order to ensure that users - and groups of the same name - are likely to carry the same - numeric UID and - GID. - - - - - - - Name - - The name field specifies the user or - group name. It should be shorter than 31 - characters and avoid any non-ASCII characters, - and not begin with a numeric character. It is - strongly recommended to pick user and group - names that are unlikely to clash with normal - users created by the administrator. A good - scheme to guarantee this is by prefixing all - system and group names with the underscore, - and avoiding too generic names. - - For m lines this - field should contain the user name to add to a - group. - - For lines of type r - this field should be set to - -. - - - - ID - - For u and - g the numeric 32bit UID or - GID of the user/group. Do not use IDs 65535 or - 4294967295, as they have special placeholder - meanings. Specify - for - automatic UID/GID allocation for the user or - group. Alternatively, specify an absolute path - in the file system. In this case the UID/GID - is read from the path's owner/group. This is - useful to create users whose UID/GID match the - owners of pre-existing files (such as SUID or - SGID binaries). - - For m lines this - field should contain the group name to add to - a user to. - - For lines of type r - this field should be set to a UID/GID range in - the format FROM-TO where - both values are formatted as decimal ASCII - numbers. Alternatively, a single UID/GID may - be specified formatted as decimal ASCII - numbers. - - - - GECOS - - A short, descriptive string for users to - be created, enclosed in quotation marks. Note - that this field may not contain colons. - - Only applies to lines of type - u and should otherwise be - left unset, or be set to - -. - - - - Home Directory - - The home directory for a new system - user. If omitted defaults to the root - directory. It is recommended to not - unnecessarily specify home directories for - system users, unless software strictly - requires one to be set. - - Only applies to lines of type - u and should otherwise be - left unset, or be set to - -. - - - - - - - - Idempotence - - Note that systemd-sysusers - will do nothing if the specified users or groups - already exist, so normally there no reason to override - sysusers.d vendor configuration, - except to block certain users or groups from being - created. - - - - See Also - - systemd1, - systemd-sysusers8 - - + + Type + + The type consists of a single letter. The following line + types are understood: + + + + u + Create a system user and group of the + specified name should they not exist yet. The user's primary + group will be set to the group bearing the same name. The + user's shell will be set to + /sbin/nologin, the home directory to + the specified home directory, or / if + none is given. The account will be created disabled, so that + logins are not allowed. + + + + g + Create a system group of the specified name + should it not exist yet. Note that u + implicitly create a matching group. The group will be + created with no password set. + + + + m + Add a user to a group. If the user or group + are not existing yet, they will be implicitly + created. + + + + r + Add a range of numeric UIDs/GIDs to the pool + to allocate new UIDs and GIDs from. If no line of this type + is specified the range of UIDs/GIDs is set to some + compiled-in default. Note that both UIDs and GIDs are + allocated from the same pool, in order to ensure that users + and groups of the same name are likely to carry the same + numeric UID and GID. + + + + + + + Name + + The name field specifies the user or group name. It should + be shorter than 31 characters and avoid any non-ASCII + characters, and not begin with a numeric character. It is + strongly recommended to pick user and group names that are + unlikely to clash with normal users created by the + administrator. A good scheme to guarantee this is by prefixing + all system and group names with the underscore, and avoiding too + generic names. + + For m lines this field should contain + the user name to add to a group. + + For lines of type r this field should + be set to -. + + + + ID + + For u and g the + numeric 32bit UID or GID of the user/group. Do not use IDs 65535 + or 4294967295, as they have special placeholder meanings. + Specify - for automatic UID/GID allocation + for the user or group. Alternatively, specify an absolute path + in the file system. In this case the UID/GID is read from the + path's owner/group. This is useful to create users whose UID/GID + match the owners of pre-existing files (such as SUID or SGID + binaries). + + For m lines this field should contain + the group name to add to a user to. + + For lines of type r this field should + be set to a UID/GID range in the format + FROM-TO where both values are formatted as + decimal ASCII numbers. Alternatively, a single UID/GID may be + specified formatted as decimal ASCII numbers. + + + + GECOS + + A short, descriptive string for users to be created, + enclosed in quotation marks. Note that this field may not + contain colons. + + Only applies to lines of type u and + should otherwise be left unset, or be set to + -. + + + + Home Directory + + The home directory for a new system user. If omitted + defaults to the root directory. It is recommended to not + unnecessarily specify home directories for system users, unless + software strictly requires one to be set. + + Only applies to lines of type u and + should otherwise be left unset, or be set to + -. + + + + + + + + Idempotence + + Note that systemd-sysusers will do + nothing if the specified users or groups already exist, so + normally there no reason to override + sysusers.d vendor configuration, except to + block certain users or groups from being created. + + + + See Also + + systemd1, + systemd-sysusers8 + + diff --git a/man/telinit.xml b/man/telinit.xml index 33ea118bcb5..02d31fbd464 100644 --- a/man/telinit.xml +++ b/man/telinit.xml @@ -1,6 +1,6 @@ + "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd"> - - - telinit - systemd - - - - Developer - Lennart - Poettering - lennart@poettering.net - - - - - - telinit - 8 - - - - telinit - Change SysV runlevel - - - - - telinit OPTIONS COMMAND - - - - - Description - - telinit may be used to change - the SysV system runlevel. Since the concept of SysV - runlevels is obsolete the runlevel requests - will be transparently translated into systemd unit - activation requests. - - - - - Options - - The following options are understood: - - - - - - - - - - - - Do not send wall - message before - reboot/halt/power-off. - - - - The following commands are understood: - - - - 0 - - Power-off the - machine. This is translated into an - activation request for - poweroff.target - and is equivalent to - systemctl - poweroff. - - - - 6 - - Reboot the - machine. This is translated into an - activation request for - reboot.target and - is equivalent to systemctl - reboot. - - - - 2 - 3 - 4 - 5 - - Change the SysV - runlevel. This is translated into an - activation request for - runlevel2.target, - runlevel3.target, - ... and is equivalent to - systemctl isolate - runlevel2.target, - systemctl isolate - runlevel3.target, - ... - - - - 1 - s - S - - Change into system - rescue mode. This is translated into - an activation request for - rescue.target and - is equivalent to systemctl - rescue. - - - - q - Q - - Reload daemon - configuration. This is equivalent to - systemctl - daemon-reload. - - - - u - U - - Serialize state, - reexecute daemon and deserialize state - again. This is equivalent to - systemctl - daemon-reexec. - - - - - - - Exit status - - On success, 0 is returned, a non-zero failure - code otherwise. - - - - Notes - - This is a legacy command available for compatibility - only. It should not be used anymore, as the concept of - runlevels is obsolete. - - - - See Also - - systemd1, - systemctl1, - wall1 - - + xmlns:xi="http://www.w3.org/2001/XInclude"> + + + telinit + systemd + + + + Developer + Lennart + Poettering + lennart@poettering.net + + + + + + telinit + 8 + + + + telinit + Change SysV runlevel + + + + + telinit OPTIONS COMMAND + + + + + Description + + telinit may be used to change the SysV + system runlevel. Since the concept of SysV runlevels is obsolete + the runlevel requests will be transparently translated into + systemd unit activation requests. + + + + + Options + + The following options are understood: + + + + + + + + + + + + Do not send wall message before + reboot/halt/power-off. + + + + The following commands are understood: + + + + 0 + + Power-off the machine. This is translated into + an activation request for poweroff.target + and is equivalent to systemctl + poweroff. + + + + 6 + + Reboot the machine. This is translated into an + activation request for reboot.target and + is equivalent to systemctl + reboot. + + + + 2 + 3 + 4 + 5 + + Change the SysV runlevel. This is translated + into an activation request for + runlevel2.target, + runlevel3.target, ... and is equivalent + to systemctl isolate runlevel2.target, + systemctl isolate runlevel3.target, + ... + + + + 1 + s + S + + Change into system rescue mode. This is + translated into an activation request for + rescue.target and is equivalent to + systemctl rescue. + + + + q + Q + + Reload daemon configuration. This is + equivalent to systemctl + daemon-reload. + + + + u + U + + Serialize state, reexecute daemon and + deserialize state again. This is equivalent to + systemctl daemon-reexec. + + + + + + + Exit status + + On success, 0 is returned, a non-zero failure + code otherwise. + + + + Notes + + This is a legacy command available for compatibility only. + It should not be used anymore, as the concept of runlevels is + obsolete. + + + + See Also + + systemd1, + systemctl1, + wall1 + + diff --git a/man/timedatectl.xml b/man/timedatectl.xml index f3edb8d61ad..98ec013ebb8 100644 --- a/man/timedatectl.xml +++ b/man/timedatectl.xml @@ -1,6 +1,6 @@ + "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd"> - - - timedatectl - systemd - - - - Developer - Lennart - Poettering - lennart@poettering.net - - - - - - timedatectl - 1 - - - - timedatectl - Control the system time and date - - - - - timedatectl OPTIONS COMMAND - - - - - Description - - timedatectl may be used to - query and change the system clock and its - settings. - - Use - systemd-firstboot1 - to initialize the system time zone for mounted (but not - booted) system images. - - - - Options - - The following options are understood: - - - - - - Do not query the user - for authentication for privileged - operations. - - - - - - If - set-local-rtc is - invoked and this option is passed, the - system clock is synchronized from the - RTC again, taking the new setting into - account. Otherwise, the RTC is - synchronized from the system - clock. - - - - - - - - - - - The following commands are understood: - - - - status - - Show current settings - of the system clock and - RTC. - - - - set-time [TIME] - - Set the system clock - to the specified time. This will also - update the RTC time accordingly. The time - may be specified in the format - "2012-10-30 - 18:17:16". - - - - set-timezone [TIMEZONE] - - Set the system time - zone to the specified value. Available - timezones can be listed with - list-timezones. If - the RTC is configured to be in the - local time, this will also update the - RTC time. This call will alter the - /etc/localtime - symlink. See - localtime5 - for more - information. - - - - list-timezones - - List available time - zones, one per line. Entries from the - list can be set as the system - timezone with - set-timezone. - - - - set-local-rtc [BOOL] - - Takes a boolean - argument. If 0, the - system is configured to maintain the - RTC in universal time. If - 1, it will maintain - the RTC in local time instead. Note - that maintaining the RTC in the local - timezone is not fully supported and - will create various problems with time - zone changes and daylight saving - adjustments. If at all possible, keep the - RTC in UTC mode. Note that invoking this - will also synchronize the RTC from the - system clock, unless - is - passed (see above). This command will - change the 3rd line of - /etc/adjtime, as - documented in - hwclock8. - - - - set-ntp [BOOL] - - Takes a boolean - argument. Controls whether NTP based - network time synchronization is - enabled (if - available). - - - - - - - - Exit status - - On success, 0 is returned, a non-zero failure - code otherwise. - - - - - - Examples - Show current settings: - $ timedatectl + xmlns:xi="http://www.w3.org/2001/XInclude"> + + + timedatectl + systemd + + + + Developer + Lennart + Poettering + lennart@poettering.net + + + + + + timedatectl + 1 + + + + timedatectl + Control the system time and date + + + + + timedatectl OPTIONS COMMAND + + + + + Description + + timedatectl may be used to query and + change the system clock and its settings. + + Use + systemd-firstboot1 + to initialize the system time zone for mounted (but not booted) + system images. + + + + Options + + The following options are understood: + + + + + + Do not query the user for authentication for + privileged operations. + + + + + + If set-local-rtc is invoked + and this option is passed, the system clock is synchronized + from the RTC again, taking the new setting into account. + Otherwise, the RTC is synchronized from the system + clock. + + + + + + + + + + + The following commands are understood: + + + + status + + Show current settings + of the system clock and + RTC. + + + + set-time [TIME] + + Set the system clock to the specified time. + This will also update the RTC time accordingly. The time may + be specified in the format "2012-10-30 + 18:17:16". + + + + set-timezone [TIMEZONE] + + Set the system time zone to the specified + value. Available timezones can be listed with + list-timezones. If the RTC is configured to + be in the local time, this will also update the RTC time. This + call will alter the /etc/localtime + symlink. See + localtime5 + for more information. + + + + list-timezones + + List available time zones, one per line. + Entries from the list can be set as the system timezone with + set-timezone. + + + + set-local-rtc [BOOL] + + Takes a boolean argument. If + 0, the system is configured to maintain the + RTC in universal time. If 1, it will + maintain the RTC in local time instead. Note that maintaining + the RTC in the local timezone is not fully supported and will + create various problems with time zone changes and daylight + saving adjustments. If at all possible, keep the RTC in UTC + mode. Note that invoking this will also synchronize the RTC + from the system clock, unless + is passed (see above). + This command will change the 3rd line of + /etc/adjtime, as documented in + hwclock8. + + + + + set-ntp [BOOL] + + Takes a boolean argument. Controls whether NTP + based network time synchronization is enabled (if + available). + + + + + + + + Exit status + + On success, 0 is returned, a non-zero failure + code otherwise. + + + + + + Examples + Show current settings: + $ timedatectl Local time: Fri, 2012-11-02 09:26:46 CET Universal time: Fri, 2012-11-02 08:26:46 UTC - RTC time: Fri, 2012-11-02 08:26:45 - Timezone: Europe/Warsaw + RTC time: Fri, 2012-11-02 08:26:45 + Timezone: Europe/Warsaw UTC offset: +0100 NTP enabled: no NTP synchronized: no RTC in local TZ: no DST active: no Last DST change: CEST → CET, DST became inactive - Sun, 2012-10-28 02:59:59 CEST - Sun, 2012-10-28 02:00:00 CET + Sun, 2012-10-28 02:59:59 CEST + Sun, 2012-10-28 02:00:00 CET Next DST change: CET → CEST, DST will become active - the clock will jump one hour forward - Sun, 2013-03-31 01:59:59 CET - Sun, 2013-03-31 03:00:00 CEST - + the clock will jump one hour forward + Sun, 2013-03-31 01:59:59 CET + Sun, 2013-03-31 03:00:00 CEST + - Enable an NTP daemon (chronyd): - $ timedatectl set-ntp true + Enable an NTP daemon (chronyd): + $ timedatectl set-ntp true ==== AUTHENTICATING FOR org.freedesktop.timedate1.set-ntp === Authentication is required to control whether network time synchronization shall be enabled. Authenticating as: user Password: ******** ==== AUTHENTICATION COMPLETE === - $ systemctl status chronyd.service + $ systemctl status chronyd.service chronyd.service - NTP client/server - Loaded: loaded (/usr/lib/systemd/system/chronyd.service; enabled) - Active: active (running) since Fri, 2012-11-02 09:36:25 CET; 5s ago + Loaded: loaded (/usr/lib/systemd/system/chronyd.service; enabled) + Active: active (running) since Fri, 2012-11-02 09:36:25 CET; 5s ago ... - - - - - See Also - - systemd1, - hwclock8, - date1, - localtime5, - systemctl1, - systemd-timedated.service8, - systemd-firstboot1 - - + + + + + See Also + + systemd1, + hwclock8, + date1, + localtime5, + systemctl1, + systemd-timedated.service8, + systemd-firstboot1 + + diff --git a/man/timesyncd.conf.xml b/man/timesyncd.conf.xml index 1a56c2c5c45..805374a5f94 100644 --- a/man/timesyncd.conf.xml +++ b/man/timesyncd.conf.xml @@ -1,7 +1,7 @@ + "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd"> - - timesyncd.conf - systemd - - - - Developer - Lennart - Poettering - lennart@poettering.net - - - - - - timesyncd.conf - 5 - - - - timesyncd.conf - timesyncd.conf.d - Network Time Synchronization configuration files - - - - /etc/systemd/timesyncd.conf - /etc/systemd/timesyncd.conf.d/*.conf - /run/systemd/timesyncd.conf.d/*.conf - /usr/lib/systemd/timesyncd.conf.d/*.conf - - - - Description - - These configuration files control NTP network time - synchronization. - - - - - - - - Options - - - - - NTP= - A space separated list - of NTP servers host names or IP - addresses. During runtime this list is - combined with any per-interface NTP - servers acquired from - systemd-networkd.service8. systemd-timesyncd - will contact all configured system or - per-interface servers in turn until - one is found that responds. This - setting defaults to the empty - list. - - - - FallbackNTP= - A space separated list - of NTP server host names or IP - addresses to be used as the fallback - NTP servers. Any per-interface NTP - servers obtained from - systemd-networkd.service8 - take precedence over this setting, as - do any servers set via - NTP= above. This - setting is hence only used if no other - NTP server information is known. If - this option is not given, a - compiled-in list of NTP servers is - used instead. - - - - - - - See Also - - systemd1, - systemd-timesyncd.service8, - systemd-networkd.service8 - - + xmlns:xi="http://www.w3.org/2001/XInclude"> + + timesyncd.conf + systemd + + + + Developer + Lennart + Poettering + lennart@poettering.net + + + + + + timesyncd.conf + 5 + + + + timesyncd.conf + timesyncd.conf.d + Network Time Synchronization configuration files + + + + /etc/systemd/timesyncd.conf + /etc/systemd/timesyncd.conf.d/*.conf + /run/systemd/timesyncd.conf.d/*.conf + /usr/lib/systemd/timesyncd.conf.d/*.conf + + + + Description + + These configuration files control NTP network time + synchronization. + + + + + + + + Options + + + + + NTP= + A space separated list of NTP servers host + names or IP addresses. During runtime this list is combined + with any per-interface NTP servers acquired from + systemd-networkd.service8. + systemd-timesyncd will contact all configured system or + per-interface servers in turn until one is found that + responds. This setting defaults to the empty + list. + + + + FallbackNTP= + A space separated list of NTP server host + names or IP addresses to be used as the fallback NTP servers. + Any per-interface NTP servers obtained from + systemd-networkd.service8 + take precedence over this setting, as do any servers set via + NTP= above. This setting is hence only used + if no other NTP server information is known. If this option is + not given, a compiled-in list of NTP servers is used + instead. + + + + + + + See Also + + systemd1, + systemd-timesyncd.service8, + systemd-networkd.service8 + + diff --git a/man/vconsole.conf.xml b/man/vconsole.conf.xml index 02df2e810ae..a29075a1612 100644 --- a/man/vconsole.conf.xml +++ b/man/vconsole.conf.xml @@ -1,7 +1,7 @@ + "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd"> - - vconsole.conf - systemd - - - - Developer - Lennart - Poettering - lennart@poettering.net - - - - - - vconsole.conf - 5 - - - - vconsole.conf - Configuration file for the virtual console - - - - /etc/vconsole.conf - - - - Description - - The /etc/vconsole.conf file - configures the virtual console, i.e. keyboard mapping - and console font. It is applied at boot by - systemd-vconsole-setup.service8. - - The basic file format of the - vconsole.conf is a - newline-separated list of environment-like - shell-compatible variable assignments. It is possible - to source the configuration from shell scripts, - however, beyond mere variable assignments no shell - features are supported, allowing applications to read - the file without implementing a shell compatible - execution engine. - - Note that the kernel command line options - vconsole.keymap=, - vconsole.keymap.toggle=, - vconsole.font=, - vconsole.font.map=, - vconsole.font.unimap= may be used - to override the console settings at boot. - - Depending on the operating system other - configuration files might be checked for configuration - of the virtual console as well, however only as - fallback. - - - - Options - - The following options are understood: - - - - - KEYMAP= - KEYMAP_TOGGLE= - - Configures the key - mapping table for the - keyboard. KEYMAP= - defaults to us if - not set. The - KEYMAP_TOGGLE= can - be used to configure a second toggle - keymap and is by default - unset. - - - - FONT= - FONT_MAP= - FONT_UNIMAP= - - Configures the console - font, the console map and the unicode - font map. - - - - - - - Example - - - German keyboard and console - - /etc/vconsole.conf: - - KEYMAP=de-latin1 + + vconsole.conf + systemd + + + + Developer + Lennart + Poettering + lennart@poettering.net + + + + + + vconsole.conf + 5 + + + + vconsole.conf + Configuration file for the virtual console + + + + /etc/vconsole.conf + + + + Description + + The /etc/vconsole.conf file configures + the virtual console, i.e. keyboard mapping and console font. It is + applied at boot by + systemd-vconsole-setup.service8. + + The basic file format of the + vconsole.conf is a newline-separated list of + environment-like shell-compatible variable assignments. It is + possible to source the configuration from shell scripts, however, + beyond mere variable assignments no shell features are supported, + allowing applications to read the file without implementing a + shell compatible execution engine. + + Note that the kernel command line options + vconsole.keymap=, + vconsole.keymap.toggle=, + vconsole.font=, + vconsole.font.map=, + vconsole.font.unimap= may be used + to override the console settings at boot. + + Depending on the operating system other configuration files + might be checked for configuration of the virtual console as well, + however only as fallback. + + + + Options + + The following options are understood: + + + + + KEYMAP= + KEYMAP_TOGGLE= + + Configures the key mapping table for the + keyboard. KEYMAP= defaults to + us if not set. The + KEYMAP_TOGGLE= can be used to configure a + second toggle keymap and is by default + unset. + + + + FONT= + FONT_MAP= + FONT_UNIMAP= + + Configures the console font, the console map + and the unicode font map. + + + + + + + Example + + + German keyboard and console + + /etc/vconsole.conf: + + KEYMAP=de-latin1 FONT=eurlatgr - - - - - - See Also - - systemd1, - systemd-vconsole-setup.service8, - loadkeys1, - setfont8, - locale.conf5, - systemd-localed.service8 - - + + + + + + See Also + + systemd1, + systemd-vconsole-setup.service8, + loadkeys1, + setfont8, + locale.conf5, + systemd-localed.service8 + + -- 2.39.2