From 7d4a62f8c1404ed426500b97af03d4ef8d034a71 Mon Sep 17 00:00:00 2001 From: "Anthony G. Basile" Date: Thu, 15 Nov 2012 10:33:16 -0500 Subject: Isolation of udev code from remaining systemd This commit is a first attempt to isolate the udev code from the remaining code base. It intentionally does not modify any files but purely delete files which, on a first examination, appear to not be needed. This is a sweeping commit which may easily have missed needed code. Files can be retrieved by doing a checkout from the previous commit: git checkout 2944f347d0 -- --- man/.gitignore | 1 - man/Makefile | 1 - man/binfmt.d.xml | 124 --- man/bootup.xml | 226 ----- man/crypttab.xml | 313 ------- man/custom-html.xsl | 50 - man/daemon.xml | 949 ------------------- man/halt.xml | 172 ---- man/hostname.xml | 102 --- man/hostnamectl.xml | 228 ----- man/journalctl.xml | 533 ----------- man/journald.conf.xml | 411 --------- man/kernel-command-line.xml | 295 ------ man/locale.conf.xml | 149 --- man/localectl.xml | 259 ------ man/localtime.xml | 103 --- man/loginctl.xml | 474 ---------- man/logind.conf.xml | 298 ------ man/machine-id.xml | 145 --- man/machine-info.xml | 154 ---- man/modules-load.d.xml | 120 --- man/os-release.xml | 350 ------- man/pam_systemd.xml | 319 ------- man/runlevel.xml | 154 ---- man/sd-daemon.xml | 180 ---- man/sd-id128.xml | 181 ---- man/sd-journal.xml | 130 --- man/sd-login.xml | 146 --- man/sd-readahead.xml | 117 --- man/sd_booted.xml | 128 --- man/sd_get_seats.xml | 129 --- man/sd_id128_get_machine.xml | 138 --- man/sd_id128_randomize.xml | 118 --- man/sd_id128_to_string.xml | 131 --- man/sd_is_fifo.xml | 217 ----- man/sd_journal_add_match.xml | 189 ---- man/sd_journal_get_cursor.xml | 151 --- man/sd_journal_get_cutoff_realtime_usec.xml | 142 --- man/sd_journal_get_data.xml | 201 ---- man/sd_journal_get_fd.xml | 272 ------ man/sd_journal_get_realtime_usec.xml | 146 --- man/sd_journal_get_usage.xml | 104 --- man/sd_journal_next.xml | 214 ----- man/sd_journal_open.xml | 184 ---- man/sd_journal_print.xml | 251 ----- man/sd_journal_query_unique.xml | 214 ----- man/sd_journal_seek_head.xml | 178 ---- man/sd_journal_stream_fd.xml | 171 ---- man/sd_listen_fds.xml | 204 ----- man/sd_login_monitor_new.xml | 173 ---- man/sd_notify.xml | 319 ------- man/sd_pid_get_session.xml | 160 ---- man/sd_readahead.xml | 178 ---- man/sd_seat_get_active.xml | 180 ---- man/sd_session_is_active.xml | 240 ----- man/sd_uid_get_state.xml | 190 ---- man/shutdown.xml | 188 ---- man/sysctl.d.xml | 127 --- man/systemctl.xml | 1268 ------------------------- man/systemd-analyze.xml | 138 --- man/systemd-ask-password-console.service.xml | 96 -- man/systemd-ask-password.xml | 183 ---- man/systemd-binfmt.service.xml | 76 -- man/systemd-cat.xml | 205 ----- man/systemd-cgls.xml | 141 --- man/systemd-cgtop.xml | 276 ------ man/systemd-coredumpctl.xml | 214 ----- man/systemd-cryptsetup-generator.xml | 147 --- man/systemd-cryptsetup@.service.xml | 87 -- man/systemd-delta.xml | 181 ---- man/systemd-detect-virt.xml | 151 --- man/systemd-fsck@.service.xml | 110 --- man/systemd-fstab-generator.xml | 118 --- man/systemd-getty-generator.xml | 90 -- man/systemd-halt.service.xml | 119 --- man/systemd-hostnamed.service.xml | 87 -- man/systemd-inhibit.xml | 205 ----- man/systemd-initctl.service.xml | 76 -- man/systemd-journald.service.xml | 173 ---- man/systemd-localed.service.xml | 89 -- man/systemd-logind.service.xml | 133 --- man/systemd-machine-id-setup.xml | 132 --- man/systemd-modules-load.service.xml | 101 -- man/systemd-notify.xml | 218 ----- man/systemd-nspawn.xml | 331 ------- man/systemd-quotacheck.service.xml | 102 --- man/systemd-random-seed-load.service.xml | 80 -- man/systemd-readahead-replay.service.xml | 113 --- man/systemd-remount-fs.service.xml | 87 -- man/systemd-shutdownd.service.xml | 77 -- man/systemd-suspend.service.xml | 126 --- man/systemd-sysctl.service.xml | 78 -- man/systemd-system-update-generator.xml | 79 -- man/systemd-timedated.service.xml | 88 -- man/systemd-tmpfiles.xml | 162 ---- man/systemd-tty-ask-password-agent.xml | 166 ---- man/systemd-udevd.service.xml | 168 ---- man/systemd-update-utmp-runlevel.service.xml | 76 -- man/systemd-user-sessions.service.xml | 77 -- man/systemd-vconsole-setup.service.xml | 118 --- man/systemd.automount.xml | 167 ---- man/systemd.conf.xml | 284 ------ man/systemd.device.xml | 168 ---- man/systemd.exec.xml | 1154 ----------------------- man/systemd.journal-fields.xml | 450 --------- man/systemd.kill.xml | 170 ---- man/systemd.mount.xml | 282 ------ man/systemd.path.xml | 220 ----- man/systemd.preset.xml | 204 ----- man/systemd.service.xml | 924 ------------------- man/systemd.snapshot.xml | 87 -- man/systemd.socket.xml | 685 -------------- man/systemd.special.xml | 817 ----------------- man/systemd.swap.xml | 213 ----- man/systemd.target.xml | 108 --- man/systemd.timer.xml | 192 ---- man/systemd.unit.xml | 1084 ---------------------- man/systemd.xml | 1272 -------------------------- man/telinit.xml | 195 ---- man/timedatectl.xml | 293 ------ man/tmpfiles.d.xml | 321 ------- man/vconsole.conf.xml | 147 --- 122 files changed, 28100 deletions(-) delete mode 100644 man/.gitignore delete mode 120000 man/Makefile delete mode 100644 man/binfmt.d.xml delete mode 100644 man/bootup.xml delete mode 100644 man/crypttab.xml delete mode 100644 man/custom-html.xsl delete mode 100644 man/daemon.xml delete mode 100644 man/halt.xml delete mode 100644 man/hostname.xml delete mode 100644 man/hostnamectl.xml delete mode 100644 man/journalctl.xml delete mode 100644 man/journald.conf.xml delete mode 100644 man/kernel-command-line.xml delete mode 100644 man/locale.conf.xml delete mode 100644 man/localectl.xml delete mode 100644 man/localtime.xml delete mode 100644 man/loginctl.xml delete mode 100644 man/logind.conf.xml delete mode 100644 man/machine-id.xml delete mode 100644 man/machine-info.xml delete mode 100644 man/modules-load.d.xml delete mode 100644 man/os-release.xml delete mode 100644 man/pam_systemd.xml delete mode 100644 man/runlevel.xml delete mode 100644 man/sd-daemon.xml delete mode 100644 man/sd-id128.xml delete mode 100644 man/sd-journal.xml delete mode 100644 man/sd-login.xml delete mode 100644 man/sd-readahead.xml delete mode 100644 man/sd_booted.xml delete mode 100644 man/sd_get_seats.xml delete mode 100644 man/sd_id128_get_machine.xml delete mode 100644 man/sd_id128_randomize.xml delete mode 100644 man/sd_id128_to_string.xml delete mode 100644 man/sd_is_fifo.xml delete mode 100644 man/sd_journal_add_match.xml delete mode 100644 man/sd_journal_get_cursor.xml delete mode 100644 man/sd_journal_get_cutoff_realtime_usec.xml delete mode 100644 man/sd_journal_get_data.xml delete mode 100644 man/sd_journal_get_fd.xml delete mode 100644 man/sd_journal_get_realtime_usec.xml delete mode 100644 man/sd_journal_get_usage.xml delete mode 100644 man/sd_journal_next.xml delete mode 100644 man/sd_journal_open.xml delete mode 100644 man/sd_journal_print.xml delete mode 100644 man/sd_journal_query_unique.xml delete mode 100644 man/sd_journal_seek_head.xml delete mode 100644 man/sd_journal_stream_fd.xml delete mode 100644 man/sd_listen_fds.xml delete mode 100644 man/sd_login_monitor_new.xml delete mode 100644 man/sd_notify.xml delete mode 100644 man/sd_pid_get_session.xml delete mode 100644 man/sd_readahead.xml delete mode 100644 man/sd_seat_get_active.xml delete mode 100644 man/sd_session_is_active.xml delete mode 100644 man/sd_uid_get_state.xml delete mode 100644 man/shutdown.xml delete mode 100644 man/sysctl.d.xml delete mode 100644 man/systemctl.xml delete mode 100644 man/systemd-analyze.xml delete mode 100644 man/systemd-ask-password-console.service.xml delete mode 100644 man/systemd-ask-password.xml delete mode 100644 man/systemd-binfmt.service.xml delete mode 100644 man/systemd-cat.xml delete mode 100644 man/systemd-cgls.xml delete mode 100644 man/systemd-cgtop.xml delete mode 100644 man/systemd-coredumpctl.xml delete mode 100644 man/systemd-cryptsetup-generator.xml delete mode 100644 man/systemd-cryptsetup@.service.xml delete mode 100644 man/systemd-delta.xml delete mode 100644 man/systemd-detect-virt.xml delete mode 100644 man/systemd-fsck@.service.xml delete mode 100644 man/systemd-fstab-generator.xml delete mode 100644 man/systemd-getty-generator.xml delete mode 100644 man/systemd-halt.service.xml delete mode 100644 man/systemd-hostnamed.service.xml delete mode 100644 man/systemd-inhibit.xml delete mode 100644 man/systemd-initctl.service.xml delete mode 100644 man/systemd-journald.service.xml delete mode 100644 man/systemd-localed.service.xml delete mode 100644 man/systemd-logind.service.xml delete mode 100644 man/systemd-machine-id-setup.xml delete mode 100644 man/systemd-modules-load.service.xml delete mode 100644 man/systemd-notify.xml delete mode 100644 man/systemd-nspawn.xml delete mode 100644 man/systemd-quotacheck.service.xml delete mode 100644 man/systemd-random-seed-load.service.xml delete mode 100644 man/systemd-readahead-replay.service.xml delete mode 100644 man/systemd-remount-fs.service.xml delete mode 100644 man/systemd-shutdownd.service.xml delete mode 100644 man/systemd-suspend.service.xml delete mode 100644 man/systemd-sysctl.service.xml delete mode 100644 man/systemd-system-update-generator.xml delete mode 100644 man/systemd-timedated.service.xml delete mode 100644 man/systemd-tmpfiles.xml delete mode 100644 man/systemd-tty-ask-password-agent.xml delete mode 100644 man/systemd-udevd.service.xml delete mode 100644 man/systemd-update-utmp-runlevel.service.xml delete mode 100644 man/systemd-user-sessions.service.xml delete mode 100644 man/systemd-vconsole-setup.service.xml delete mode 100644 man/systemd.automount.xml delete mode 100644 man/systemd.conf.xml delete mode 100644 man/systemd.device.xml delete mode 100644 man/systemd.exec.xml delete mode 100644 man/systemd.journal-fields.xml delete mode 100644 man/systemd.kill.xml delete mode 100644 man/systemd.mount.xml delete mode 100644 man/systemd.path.xml delete mode 100644 man/systemd.preset.xml delete mode 100644 man/systemd.service.xml delete mode 100644 man/systemd.snapshot.xml delete mode 100644 man/systemd.socket.xml delete mode 100644 man/systemd.special.xml delete mode 100644 man/systemd.swap.xml delete mode 100644 man/systemd.target.xml delete mode 100644 man/systemd.timer.xml delete mode 100644 man/systemd.unit.xml delete mode 100644 man/systemd.xml delete mode 100644 man/telinit.xml delete mode 100644 man/timedatectl.xml delete mode 100644 man/tmpfiles.d.xml delete mode 100644 man/vconsole.conf.xml (limited to 'man') diff --git a/man/.gitignore b/man/.gitignore deleted file mode 100644 index cf8c17cb95..0000000000 --- a/man/.gitignore +++ /dev/null @@ -1 +0,0 @@ -/systemd.directives.xml diff --git a/man/Makefile b/man/Makefile deleted file mode 120000 index bd1047548b..0000000000 --- a/man/Makefile +++ /dev/null @@ -1 +0,0 @@ -../src/Makefile \ No newline at end of file diff --git a/man/binfmt.d.xml b/man/binfmt.d.xml deleted file mode 100644 index 07ae0ac231..0000000000 --- a/man/binfmt.d.xml +++ /dev/null @@ -1,124 +0,0 @@ - - - - - - - - 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. - - Each configuration file shall be named in the - style of <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 configuration files in - /usr/lib/, files in - /etc/ are reserved for the local - administrator, who may use this logic to override the - configuration files installed from vendor - packages. All files are sorted by their filename in - alphabetical order, regardless in which of the - directories they reside, to guarantee that a specific - configuration file takes precedence over another file - with an alphabetically later name. - - If the administrator wants to disable a - configuration file supplied by the vendor the - recommended way is to place a symlink to - /dev/null in - /etc/binfmt.d/ bearing the - same file name. - - - - 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 - - - - diff --git a/man/bootup.xml b/man/bootup.xml deleted file mode 100644 index 4cc4bafab7..0000000000 --- a/man/bootup.xml +++ /dev/null @@ -1,226 +0,0 @@ - - - - - - - - - bootup - systemd - - - - Developer - Lennart - Poettering - lennart@poettering.net - - - - - - bootup - 7 - - - - bootup - System bootup process - - - - Description - - A number of different components are involved in the - system boot. Immediately after power-up, the system - BIOS will do minimal hardware initialization, and hand - control over to a boot loader stored on a persistent - storage device. This boot loader will then invoke an - OS kernel from disk (or the network). In the Linux - case this kernel now (optionally) extracts and - executes an initial RAM disk image (initrd) such as - dracut8 - which looks for the root file system. After the root - file system is found and mounted the initrd hands over - control to the system manager (such as - systemd1) - stored on the OS image which is then responsible for - probing all remaining hardware, mounting all necessary - file systems and spawning all configured - services. - - On shutdown the system manager stops all - services, unmounts all file systems (detaching the - storage technologies backing them), and then - (optionally) jumps back into the initrd code which - unmounts/detaches the root file system and the storage - it resides on. As last step the system is powered down. - - Additional information about the system boot - process may be found in - boot7. - - - - System Manager Bootup - - At boot, the system manager on the OS image is - responsible for initializing the required file - systems, services and drivers that are necessary for - operation of the system. On - systemd1 - systems this process is split up in various discrete - steps which are exposed as target units. (See - systemd.target5 - for detailed information about target units.) The - boot-up process is highly parallelized so that the - order in which specific target units are reached is not - deterministic, but still adheres to a limited amount - of ordering structure. - - When systemd starts up the system it will - activate all units that are dependencies of - default.target (as well as - recursively all dependencies of these - dependencies). Usually - default.target is simply an alias - of graphical.target or - multi-user.target depending on - whether the system is configured for a graphical UI or - only for a text console. To enforce minimal ordering - between the units pulled in a number of well-known - target units are available, as listed on - systemd.special7. - - The following chart is a structural overview of - these well-known units and their position in the - boot-up logic. The arrows describe which units are - pulled in and ordered before which other units. Units - near the top are started before units nearer to the - bottom of the chart. - -local-fs-pre.target - | - v -(various mounts and (various swap (various cryptsetup - fsck services...) devices...) devices...) (various low-level (various low-level - | | | services: udevd, API VFS mounts: - v v v tmpfiles, random mqueue, configfs, - local-fs.target swap.target cryptsetup.target seed, sysctl, ...) debugfs, ...) - | | | | | - \__________________|_________________ | ___________________|____________________/ - \|/ - v - sysinit.target - | - _________________/|\___________________ - / | \ - | | | - v | v - (various | rescue.service - sockets...) | | - | | v - v | rescue.target - sockets.target | - | | - \_________________ | - \| - v - basic.target - | - __________________________________/| emergency.service - / | | | - | | | v - v v v emergency.target - display- (various system (various system - manager.service services services) - | required for | - | graphical UIs) v - | | multi-user.target - | | | - \_______________ | _________________/ - \|/ - v - graphical.target - - Target units that are commonly used as boot - targets are emphasized. These - units are good choices as goal targets, for - example by passing them to the - systemd.unit= kernel command line - option (see - systemd1) - or by symlinking default.target - to them. - - - - System Manager Shutdown - - System shutdown also consists of various target - units with some minimal ordering structure - applied: - - - - - (conflicts with (conflicts with - all system all file system - services) mounts, swaps, - | cryptsetup - | devices, ...) - | | - v v - shutdown.target umount.target - | | - \_______ ______/ - \ / - v - (various low-level - services) - | - v - final.target - | - _____________________________________/ \_________________________________ - / | | \ - | | | | - v v v v -systemd-reboot.service systemd-poweroff.service systemd-halt.service systemd-kexec.service - | | | | - v v v v - reboot.target poweroff.target halt.target kexec.target - - Commonly used system shutdown targets are emphasized. - - - - See Also - - systemd1, - boot7, - systemd.special7, - systemd.target5 - - - - diff --git a/man/crypttab.xml b/man/crypttab.xml deleted file mode 100644 index 2a839944dc..0000000000 --- a/man/crypttab.xml +++ /dev/null @@ -1,313 +0,0 @@ - - - - - - - - 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. - - 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 a specification of a block - device via UUID= followed by the - UUID. If the block device contains a LUKS signature, - it is opened as a LUKS encrypted partition; otherwise - it is assumed to be a raw dm-crypt partition. - - The third field specifies the encryption - password. If the field is not present or the password - is set to none, the password has to be manually - entered during system boot. Otherwise the field is - interpreted as a 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: - - - - cipher= - - 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. - - - - - size= - - Specifies the key size - in bits; see - cryptsetup8 - for possible values and the default - value of this - option. - - - - - keyfile-size= - - Specifies the maximum number - of bytes to read from the keyfile; see - cryptsetup8 - for possible values and the default - value of this option. This option is ignored - in plain encryption mode, as the keyfile-size is then given by the key size. - - - - - keyfile-offset= - - Specifies the number - of bytes to skip at the start of - the keyfile; see - cryptsetup8 - for possible values and the default - value of this option. - - - - - hash= - - Specifies the hash to - use for password hashing; see - cryptsetup8 for possible values and - the default value of this - option. - - - - tries= - - Specifies the maximum - number of times the user is queried - for a password. - - - - verify - - If the encryption - password is read from console, it has - to be entered twice (to prevent - typos). - - - - read-only - - Set up the encrypted - block device in read-only - mode. - - - - allow-discards - - Allow discard requests - to be passed through the encrypted - block device. This improves - performance on SSD storage but has - security - implications. - - - - luks - - Force LUKS mode. - - - - plain - - Force plain encryption - mode. - - - - timeout= - - Specify the timeout - for querying for a password. If no - unit is specified seconds is used. - Supported units are s, ms, - us, min, h, d. - - - - noauto - - This device will not - be automatically unlocked on - boot. - - - - nofail - - The system will not - wait for the device to show up and be - unlocked at boot, and not fail the - boot if it doesn't show - up. - - - - swap - - The encrypted block - device will be used as a swap - partition, and will be formatted as a - swap partition after setting up the - encrypted block device, with - mkswap8. - - WARNING: Using the - swap option will - destroy the contents of the named - partition during every boot, so make - sure the underlying block device is - specified - correctly. - - - - tmp - - The encrypted block - device will be prepared for using it - as /tmp - partition: it will be formatted using - mke2fs8. - - WARNING: Using the - tmp option will - destroy the contents of the named - partition during every boot, so make - sure the underlying block device is - specified - correctly. - - - - 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 two encrypted block devices with - LUKS: one normal one for storage, and another - one for usage as swap device. - - luks-2505567a-9e27-4efe-a4d5-15ad146c258b UUID=2505567a-9e27-4efe-a4d5-15ad146c258b - timeout=0 -swap /dev/sda7 /dev/urandom swap - - - - - See Also - - systemd1, - systemd-cryptsetup@.service8, - systemd-cryptsetup-generator8, - cryptsetup8, - mkswap8, - mke2fs8 - - - - diff --git a/man/custom-html.xsl b/man/custom-html.xsl deleted file mode 100644 index 906ddc5572..0000000000 --- a/man/custom-html.xsl +++ /dev/null @@ -1,50 +0,0 @@ - - - - - - - - - - - - - .html - - - - - - - - - - index.html - - Index - -
- - - - - - diff --git a/man/daemon.xml b/man/daemon.xml deleted file mode 100644 index 197138e51d..0000000000 --- a/man/daemon.xml +++ /dev/null @@ -1,949 +0,0 @@ - - - - - - - - - daemon - systemd - - - - Developer - Lennart - Poettering - lennart@poettering.net - - - - - - daemon - 7 - - - - daemon - Writing and packaging system daemons - - - - Description - - A daemon is a service process that runs in the - background and supervises the system or provides - functionality to other processes. Traditionally, - daemons are implemented following a scheme originating - in SysV Unix. Modern daemons should follow a simpler - yet more powerful scheme (here called "new-style" - daemons), as implemented by - systemd1. This - manual page covers both schemes, and in - particular includes recommendations for daemons that - shall be included in the systemd init system. - - - SysV Daemons - - When a traditional SysV daemon - starts, it should execute the following steps - as part of the initialization. Note that these - steps are unnecessary for new-style daemons (see below), - and should only be implemented if compatibility - with SysV is essential. - - - Close all open file - descriptors except STDIN, STDOUT, - STDERR (i.e. the first three file - descriptors 0, 1, 2). This ensures - that no accidentally passed file - descriptor stays around in the daemon - process. On Linux this is best - implemented by iterating through - /proc/self/fd, - with a fallback of iterating from file - descriptor 3 to the value returned by - getrlimit() for - RLIMIT_NOFILE. - - Reset all signal - handlers to their default. This is - best done by iterating through the - available signals up to the limit of - _NSIG and resetting them to - SIG_DFL. - - Reset the signal mask - using - sigprocmask(). - - Sanitize the - environment block, removing or - resetting environment variables that - might negatively impact daemon - runtime. - - Call fork(), - to create a background - process. - - In the child, call - setsid() to - detach from any terminal and create an - independent session. - - In the child, call - fork() again, to - ensure the daemon can never re-acquire - a terminal again. - - Call exit() in the - first child, so that only the second - child (the actual daemon process) - stays around. This ensures that the - daemon process is reparented to - init/PID 1, as all daemons should - be. - - In the daemon process, - connect /dev/null - to STDIN, STDOUT, - STDERR. - - In the daemon process, - reset the umask to 0, so that the file - modes passed to open(), mkdir() and - suchlike directly control the access - mode of the created files and - directories. - - In the daemon process, - change the current directory to the - root directory (/), in order to avoid - that the daemon involuntarily - blocks mount points from being - unmounted. - - In the daemon process, - write the daemon PID (as returned by - getpid()) to a - PID file, for example - /var/run/foobar.pid - (for a hypothetical daemon "foobar"), - to ensure that the daemon cannot be - started more than once. This must be - implemented in race-free fashion so - that the PID file is only updated when - at the same time it is verified that - the PID previously stored in the PID - file no longer exists or belongs to a - foreign process. Commonly some kind of - file locking is employed to implement - this logic. - - In the daemon process, - drop privileges, if possible and - applicable. - - From the daemon - process notify the original process - started that initialization is - complete. This can be implemented via - an unnamed pipe or similar - communication channel that is created - before the first - fork() and hence - available in both the original and the - daemon process. - - Call - exit() in the - original process. The process that - invoked the daemon must be able to - rely on that this - exit() happens - after initialization is complete and - all external communication channels - are established and - accessible. - - - The BSD daemon() function should not be - used, as it implements only a subset of these steps. - - A daemon that needs to provide - compatibility with SysV systems should - implement the scheme pointed out - above. However, it is recommended to make this - behavior optional and configurable via a - command line argument, to ease debugging as - well as to simplify integration into systems - using systemd. - - - - New-Style Daemons - - Modern services for Linux should be - implemented as new-style daemons. This makes it - easier to supervise and control them at - runtime and simplifies their - implementation. - - For developing a new-style daemon none - of the initialization steps recommended for - SysV daemons need to be implemented. New-style - init systems such as systemd make all of them - redundant. Moreover, since some of these steps - interfere with process monitoring, file - descriptor passing and other functionality of - the init system it is recommended not to - execute them when run as new-style - service. - - Note that new-style init systems - guarantee execution of daemon processes in - clean process contexts: it is guaranteed that - the environment block is sanitized, that the - signal handlers and mask is reset and that no - left-over file descriptors are passed. Daemons - will be executed in their own session, and - STDIN/STDOUT/STDERR connected to - /dev/null unless - otherwise configured. The umask is reset. - - It is recommended for new-style daemons - to implement the following: - - - If SIGTERM is - received, shut down the daemon and - exit cleanly. - - If SIGHUP is received, - reload the configuration files, if - this applies. - - Provide a correct exit - code from the main daemon process, as - this is used by the init system to - detect service errors and problems. It - is recommended to follow the exit code - scheme as defined in the LSB - recommendations for SysV init - scripts. - - If possible and - applicable expose the daemon's control - interface via the D-Bus IPC system and - grab a bus name as last step of - initialization. - - For integration in - systemd, provide a - .service unit - file that carries information about - starting, stopping and otherwise - maintaining the daemon. See - systemd.service5 - for details. - - As much as possible, - rely on the init system's - functionality to limit the access of - the daemon to files, services and - other resources. i.e. in the case of - systemd, rely on systemd's resource - limit control instead of implementing - your own, rely on systemd's privilege - dropping code instead of implementing - it in the daemon, and similar. See - systemd.exec5 - for the available - controls. - - If D-Bus is used, make - your daemon bus-activatable, via - supplying a D-Bus service activation - configuration file. This has multiple - advantages: your daemon may be started - lazily on-demand; it may be started in - parallel to other daemons requiring it - -- which maximizes parallelization and - boot-up speed; your daemon can be - restarted on failure, without losing - any bus requests, as the bus queues - requests for activatable services. See - below for details. - - If your daemon - provides services to other local - processes or remote clients via a - socket, it should be made - socket-activatable following the - scheme pointed out below. Like D-Bus - activation this enables on-demand - starting of services as well as it - allows improved parallelization of - service start-up. Also, for state-less - protocols (such as syslog, DNS) a - daemon implementing socket-based - activation can be restarted without - losing a single request. See below for - details. - - If applicable a daemon - should notify the init system about - startup completion or status updates - via the - sd_notify3 - interface. - - Instead of using the - syslog() call to log directly to the - system syslog service, a new-style daemon may - choose to simply log to STDERR via - fprintf(), which is then forwarded to - syslog by the init system. If log - priorities are necessary these can be - encoded by prefixing individual log - lines with strings like "<4>" - (for log priority 4 "WARNING" in the - syslog priority scheme), following a - similar style as the Linux kernel's - printk() priority system. In fact, - using this style of logging also - enables the init system to optionally - direct all application logging to the - kernel log buffer (kmsg), as - accessible via - dmesg1. This - kind of logging may be enabled by - setting - StandardError=syslog - in the service unit file. For details - see - sd-daemon3 - and - systemd.exec5. - - - - These recommendations are similar but - not identical to the Apple - MacOS X Daemon Requirements. - - - - - Activation - - New-style init systems provide multiple - additional mechanisms to activate services, as - detailed below. It is common that services are - configured to be activated via more than one mechanism - at the same time. An example for systemd: - bluetoothd.service might get - activated either when Bluetooth hardware is plugged - in, or when an application accesses its programming - interfaces via D-Bus. Or, a print server daemon might - get activated when traffic arrives at an IPP port, or - when a printer is plugged in, or when a file is queued - in the printer spool directory. Even for services that - are intended to be started on system bootup - unconditionally it is a good idea to implement some of - the various activation schemes outlined below, in - order to maximize parallelization: if a daemon - implements a D-Bus service or listening socket, - implementing the full bus and socket activation scheme - allows starting of the daemon with its clients in - parallel (which speeds up boot-up), since all its - communication channels are established already, and no - request is lost because client requests will be queued - by the bus system (in case of D-Bus) or the kernel (in - case of sockets), until the activation is - completed. - - - Activation on Boot - - Old-style daemons are usually activated - exclusively on boot (and manually by the - administrator) via SysV init scripts, as - detailed in the LSB - Linux Standard Base Core - Specification. This method of - activation is supported ubiquitously on Linux - init systems, both old-style and new-style - systems. Among other issues SysV init scripts - have the disadvantage of involving shell - scripts in the boot process. New-style init - systems generally employ updated versions of - activation, both during boot-up and during - runtime and using more minimal service - description files. - - In systemd, if the developer or - administrator wants to make sure a service or - other unit is activated automatically on boot - it is recommended to place a symlink to the - unit file in the .wants/ - directory of either - multi-user.target or - graphical.target, which - are normally used as boot targets at system - startup. See - systemd.unit5 - for details about the - .wants/ directories, and - systemd.special7 - for details about the two boot targets. - - - - - Socket-Based Activation - - In order to maximize the possible - parallelization and robustness and simplify - configuration and development, it is - recommended for all new-style daemons that - communicate via listening sockets to employ - socket-based activation. In a socket-based - activation scheme the creation and binding of - the listening socket as primary communication - channel of daemons to local (and sometimes - remote) clients is moved out of the daemon - code and into the init system. Based on - per-daemon configuration the init system - installs the sockets and then hands them off - to the spawned process as soon as the - respective daemon is to be started. - Optionally activation of the service can be - delayed until the first inbound traffic - arrives at the socket, to implement on-demand - activation of daemons. However, the primary - advantage of this scheme is that all providers - and all consumers of the sockets can be - started in parallel as soon as all sockets - are established. In addition to that daemons - can be restarted with losing only a minimal - number of client transactions or even any - client request at all (the latter is - particularly true for state-less protocols, - such as DNS or syslog), because the socket - stays bound and accessible during the restart, - and all requests are queued while the daemon - cannot process them. - - New-style daemons which support socket - activation must be able to receive their - sockets from the init system, instead of - creating and binding them themselves. For - details about the programming interfaces for - this scheme provided by systemd see - sd_listen_fds3 - and - sd-daemon3. For - details about porting existing daemons to - socket-based activation see below. With - minimal effort it is possible to implement - socket-based activation in addition to - traditional internal socket creation in the - same codebase in order to support both - new-style and old-style init systems from the - same daemon binary. - - systemd implements socket-based - activation via .socket - units, which are described in - systemd.socket5. When - configuring socket units for socket-based - activation it is essential that all listening - sockets are pulled in by the special target - unit sockets.target. It - is recommended to place a - WantedBy=sockets.target - directive in the [Install] - section, to automatically add such a - dependency on installation of a socket - unit. Unless - DefaultDependencies=no is - set the necessary ordering dependencies are - implicitly created for all socket units. For - more information about - sockets.target see - systemd.special7. It - is not necessary or recommended to place any - additional dependencies on socket units (for - example from - multi-user.target or - suchlike) when one is installed in - sockets.target. - - - - Bus-Based Activation - - When the D-Bus IPC system is used for - communication with clients, new-style daemons - should employ bus activation so that they are - automatically activated when a client - application accesses their IPC - interfaces. This is configured in D-Bus - service files (not to be confused with systemd - service unit files!). To ensure that D-Bus - uses systemd to start-up and maintain the - daemon use the - SystemdService= directive - in these service files, to configure the - matching systemd service for a D-Bus - service. e.g.: for a D-Bus service whose D-Bus - activation file is named - org.freedesktop.RealtimeKit.service, - make sure to set - SystemdService=rtkit-daemon.service - in that file, to bind it to the systemd - service - rtkit-daemon.service. This - is needed to make sure that the daemon is - started in a race-free fashion when activated - via multiple mechanisms simultaneously. - - - - Device-Based Activation - - Often, daemons that manage a particular - type of hardware should be activated only when - the hardware of the respective kind is plugged - in or otherwise becomes available. In a - new-style init system it is possible to bind - activation to hardware plug/unplug events. In - systemd, kernel devices appearing in the - sysfs/udev device tree can be exposed as units - if they are tagged with the string - "systemd". Like any other - kind of unit they may then pull in other units - when activated (i.e. Plugged in) and thus - implement device-based activation. Systemd - dependencies may be encoded in the udev - database via the - SYSTEMD_WANTS= - property. See - systemd.device5 - for details. Often it is nicer to pull in - services from devices only indirectly via - dedicated targets. Example: instead of pulling - in bluetoothd.service - from all the various bluetooth dongles and - other hardware available, pull in - bluetooth.target from them and - bluetoothd.service from - that target. This provides for nicer - abstraction and gives administrators the - option to enable - bluetoothd.service via - controlling a - bluetooth.target.wants/ - symlink uniformly with a command like - enable of - systemctl1 - instead of manipulating the udev - ruleset. - - - - Path-Based Activation - - Often, runtime of daemons processing - spool files or directories (such as a printing - system) can be delayed until these file system - objects change state, or become - non-empty. New-style init systems provide a - way to bind service activation to file system - changes. systemd implements this scheme via - path-based activation configured in - .path units, as outlined - in - systemd.path5. - - - - Timer-Based Activation - - Some daemons that implement clean-up - jobs that are intended to be executed in - regular intervals benefit from timer-based - activation. In systemd, this is implemented - via .timer units, as - described in - systemd.timer5. - - - - Other Forms of Activation - - Other forms of activation have been - suggested and implemented in some - systems. However, often there are simpler or - better alternatives, or they can be put - together of combinations of the schemes - above. Example: sometimes it appears useful to - start daemons or .socket - units when a specific IP address is configured - on a network interface, because network - sockets shall be bound to the - address. However, an alternative to implement - this is by utilizing the Linux IP_FREEBIND - socket option, as accessible via - FreeBind=yes in systemd - socket files (see - systemd.socket5 - for details). This option, when enabled, - allows sockets to be bound to a non-local, not - configured IP address, and hence allows - bindings to a particular IP address before it - actually becomes available, making such an - explicit dependency to the configured address - redundant. Another often suggested trigger for - service activation is low system - load. However, here too, a more convincing - approach might be to make proper use of - features of the operating system: in - particular, the CPU or IO scheduler of - Linux. Instead of scheduling jobs from - userspace based on monitoring the OS - scheduler, it is advisable to leave the - scheduling of processes to the OS scheduler - itself. systemd provides fine-grained access - to the CPU and IO schedulers. If a process - executed by the init system shall not - negatively impact the amount of CPU or IO - bandwidth available to other processes, it - should be configured with - CPUSchedulingPolicy=idle - and/or - IOSchedulingClass=idle. Optionally, - this may be combined with timer-based - activation to schedule background jobs during - runtime and with minimal impact on the system, - and remove it from the boot phase - itself. - - - - - Integration with Systemd - - - Writing Systemd Unit Files - - When writing systemd unit files, it is - recommended to consider the following - suggestions: - - - If possible do not use - the Type=forking - setting in service files. But if you - do, make sure to set the PID file path - using PIDFile=. See - systemd.service5 - for details. - - If your daemon - registers a D-Bus name on the bus, - make sure to use - Type=dbus in the - service file if - possible. - - Make sure to set a - good human-readable description string - with - Description=. - - Do not disable - DefaultDependencies=, - unless you really know what you do and - your unit is involved in early boot or - late system shutdown. - - Normally, little if - any dependencies should need to - be defined explicitly. However, if you - do configure explicit dependencies, only refer to - unit names listed on - systemd.special7 - or names introduced by your own - package to keep the unit file - operating - system-independent. - - Make sure to include - an [Install] - section including installation - information for the unit file. See - systemd.unit5 - for details. To activate your service - on boot make sure to add a - WantedBy=multi-user.target - or - WantedBy=graphical.target - directive. To activate your socket on - boot, make sure to add - WantedBy=sockets.target. Usually - you also want to make sure that when - your service is installed your socket - is installed too, hence add - Also=foo.socket in - your service file - foo.service, for - a hypothetical program - foo. - - - - - - Installing Systemd Service Files - - At the build installation time - (e.g. make install during - package build) packages are recommended to - install their systemd unit files in the - directory returned by pkg-config - systemd - --variable=systemdsystemunitdir (for - system services) or pkg-config - systemd - --variable=systemduserunitdir - (for user services). This will make the - services available in the system on explicit - request but not activate them automatically - during boot. Optionally, during package - installation (e.g. rpm -i - by the administrator) symlinks should be - created in the systemd configuration - directories via the enable - command of the - systemctl1 - tool, to activate them automatically on - boot. - - Packages using - autoconf1 - are recommended to use a configure script - excerpt like the following to determine the - unit installation path during source - configuration: - - PKG_PROG_PKG_CONFIG -AC_ARG_WITH([systemdsystemunitdir], - AS_HELP_STRING([--with-systemdsystemunitdir=DIR], [Directory for systemd service files]), - [], [with_systemdsystemunitdir=$($PKG_CONFIG --variable=systemdsystemunitdir systemd)]) -if test "x$with_systemdsystemunitdir" != xno; then - AC_SUBST([systemdsystemunitdir], [$with_systemdsystemunitdir]) -fi -AM_CONDITIONAL(HAVE_SYSTEMD, [test -n "$with_systemdsystemunitdir" -a "x$with_systemdsystemunitdir" != xno ]) - - This snippet allows automatic - installation of the unit files on systemd - machines, and optionally allows their - installation even on machines lacking - systemd. (Modification of this snippet for the - user unit directory is left as an exercise for the - reader.) - - Additionally, to ensure that - make distcheck continues to - work, it is recommended to add the following - to the top-level Makefile.am - file in - automake1-based - projects: - - DISTCHECK_CONFIGURE_FLAGS = \ - --with-systemdsystemunitdir=$$dc_install_base/$(systemdsystemunitdir) - - Finally, unit files should be installed in the system with an automake excerpt like the following: - - if HAVE_SYSTEMD -systemdsystemunit_DATA = \ - foobar.socket \ - foobar.service -endif - - In the - rpm8 - .spec file use snippets - like the following to enable/disable the - service during - installation/deinstallation. This makes use of - the RPM macros shipped along systemd. Consult - the packaging guidelines of your distribution - for details and the equivalent for other - package managers. - - At the top of the file: - - BuildRequires: systemd -%{?systemd_requires} - - And as scriptlets, further down: - - %post -%systemd_post foobar.service foobar.socket - -%preun -%systemd_preun foobar.service foobar.socket - -%postun -%systemd_postun - - If the service shall be restarted during - upgrades replace the - %postun scriptlet above - with the following: - - %postun -%systemd_postun_with_restart foobar.service - - Note that - %systemd_post and - %systemd_preun expect the - names of all units that are installed/removed - as arguments, separated by - spaces. %systemd_postun - expects no - arguments. %systemd_postun_with_restart - expects the units to restart as - arguments. - - To facilitate upgrades from a package - version that shipped only SysV init scripts to - a package version that ships both a SysV init - script and a native systemd service file, use - a fragment like the following: - - %triggerun -- foobar < 0.47.11-1 -if /sbin/chkconfig --level 5 foobar ; then - /bin/systemctl --no-reload enable foobar.service foobar.socket >/dev/null 2>&1 || : -fi - - Where 0.47.11-1 is the first package - version that includes the native unit - file. This fragment will ensure that the first - time the unit file is installed it will be - enabled if and only if the SysV init script is - enabled, thus making sure that the enable - status is not changed. Note that - chkconfig is a command - specific to Fedora which can be used to check - whether a SysV init script is enabled. Other - operating systems will have to use different - commands here. - - - - - Porting Existing Daemons - - Since new-style init systems such as systemd are - compatible with traditional SysV init systems it is - not strictly necessary to port existing daemons to the - new style. However doing so offers additional - functionality to the daemons as well as simplifying - integration into new-style init systems. - - To port an existing SysV compatible daemon the - following steps are recommended: - - - If not already implemented, - add an optional command line switch to the - daemon to disable daemonization. This is - useful not only for using the daemon in - new-style init systems, but also to ease - debugging. - - If the daemon offers - interfaces to other software running on the - local system via local AF_UNIX sockets, - consider implementing socket-based activation - (see above). Usually a minimal patch is - sufficient to implement this: Extend the - socket creation in the daemon code so that - sd_listen_fds3 - is checked for already passed sockets - first. If sockets are passed (i.e. when - sd_listen_fds() returns a - positive value), skip the socket creation step - and use the passed sockets. Secondly, ensure - that the file-system socket nodes for local - AF_UNIX sockets used in the socket-based - activation are not removed when the daemon - shuts down, if sockets have been - passed. Third, if the daemon normally closes - all remaining open file descriptors as part of - its initialization, the sockets passed from - the init system must be spared. Since - new-style init systems guarantee that no - left-over file descriptors are passed to - executed processes, it might be a good choice - to simply skip the closing of all remaining - open file descriptors if sockets are - passed. - - Write and install a systemd - unit file for the service (and the sockets if - socket-based activation is used, as well as a - path unit file, if the daemon processes a - spool directory), see above for - details. - - If the daemon exposes - interfaces via D-Bus, write and install a - D-Bus activation file for the service, see - above for details. - - - - - See Also - - systemd1, - sd-daemon3, - sd_listen_fds3, - sd_notify3, - daemon3, - systemd.service5 - - - - diff --git a/man/halt.xml b/man/halt.xml deleted file mode 100644 index 8473965194..0000000000 --- a/man/halt.xml +++ /dev/null @@ -1,172 +0,0 @@ - - - - - - - - - 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: - - - - - - Prints a short help - text and exits. - - - - - - 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. Don't contact the - init system. - - - - - - - Only write wtmp - shutdown entry, don't actually halt, - power-off, reboot. - - - - - - - Don't write wtmp - shutdown entry. - - - - - - Don't 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 deleted file mode 100644 index 84a2961664..0000000000 --- a/man/hostname.xml +++ /dev/null @@ -1,102 +0,0 @@ - - - - - - - - - /etc/hostname - systemd - - - - Developer - Lennart - Poettering - lennart@poettering.net - - - - - - hostname - 5 - - - - hostname - Local host name configuration file - - - - /etc/hostname - - - - Description - - The /etc/hostname file - configures the name of the local system that is set - during boot, with the - sethostname2 - system call. It should contain a single - newline-terminated host name string. The - host name may be a free-form string up to 64 characters - in length, however it is recommended that it consists - only of 7bit 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 host name as well, however only as fallback. - - You may use - hostnamectl1 - to change the value of this file from the command - line. - - - - 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 - - - - diff --git a/man/hostnamectl.xml b/man/hostnamectl.xml deleted file mode 100644 index c36f522c8e..0000000000 --- a/man/hostnamectl.xml +++ /dev/null @@ -1,228 +0,0 @@ - - - - - - - - - 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 host - names: 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 might be assigned temporarily due to network - configuration and might revert back to the static - hostname if network connectivity is lost and is only - temporarily written to the kernel hostname - (e.g. "dhcp-47-11"). - - 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 host name is stored in - /etc/hostname, see - hostname5 - for more information. The pretty host name and icon - name are stored in - /etc/machine-info, see - machine-id5. - - - - Options - - The following options are understood: - - - - - - - Prints a short help - text and exits. - - - - - - Prints a short version - string and exits. - - - - - - Don't query the user - for authentication for privileged - operations. - - - - - - - Execute the operation - remotely. Specify a hostname, or - username and hostname separated by @, - to connect to. This will use SSH to - talk to a remote - system. - - - - - - - - If - set-hostname is - invoked and one or more of these - options are passed only the selected - hostnames is - updated. - - - - The following commands are understood: - - - - status - - Show current system - hostname and related - information. - - - - set-hostname [NAME] - - Set the system - hostname. 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 host - name will be simplified in regards to - the character set used before the - latter are updated. This is done by - replacing spaces by "-" 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 hostname to reset the - selected hostnames to their default - (usually - "localhost"). - - - - set-icon-name [NAME] - - Set the system icon - 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 this operation to - reset the icon name to the default - value which is determined from the - system form factor and possibly other - parameters. - - - - - - - Exit status - - On success 0 is returned, a non-zero failure - code otherwise. - - - - See Also - - systemd1, - hostname1, - hostname5, - machine-info5, - systemctl1, - systemd-hostnamed.service8 - - - - diff --git a/man/journalctl.xml b/man/journalctl.xml deleted file mode 100644 index 026bb22940..0000000000 --- a/man/journalctl.xml +++ /dev/null @@ -1,533 +0,0 @@ - - - - - - - - - journalctl - systemd - - - - Developer - Lennart - Poettering - lennart@poettering.net - - - - - - journalctl - 1 - - - - journalctl - Query the systemd journal - - - - - journalctl OPTIONS MATCHES - - - - - Description - - journalctl may be used to - query the contents of the - systemd1 - journal as written by - systemd-journald.service8. - - If called without parameter it will show the full - contents of the journal, starting with the oldest - entry collected. - - If one or more match arguments are passed the - output is filtered accordingly. A match is in the - format FIELD=VALUE, - e.g. _SYSTEMD_UNIT=httpd.service, - referring to the components of a structured journal - entry. See - systemd.journal-fields7 - for a list of well-known fields. If multiple matches - are specified matching different fields the log - entries are filtered by both, i.e. the resulting output - will show only entries matching all the specified - matches of this kind. If two matches apply to the same - field, then they are automatically matched as - alternatives, i.e. the resulting output will show - entries matching any of the specified matches for the - same field. Finally, if the character - "+" appears as separate word on the - command line all matches before and after are combined - in a disjunction (i.e. logical OR). - - As shortcuts for a few types of field/value - matches file paths may be specified. If a file path - refers to an executable file, this is equivalent to an - _EXE= match for the canonicalized - binary path. Similar, if a path refers to a device - node, this is equivalent to a - _KERNEL_DEVICE= match for the - device. - - Output is interleaved from all accessible - journal files, whether they are rotated or currently - being written, and regardless whether they belong to the - system itself or are accessible user journals. - - All users are granted access to their private - per-user journals. However, by default only root and - users who are members of the adm - group get access to the system journal and the - journals of other users. - - - - Options - - The following options are understood: - - - - - - - Prints a short help - text and exits. - - - - - - Prints a short version - string and exits. - - - - - - Do not pipe output into a - pager. - - - - - - - Show all fields in - full, even if they include unprintable - characters or are very - long. - - - - - - - Show only the most recent - journal entries, and continuously print - new entries as they are appended to - the journal. - - - - - - - Show the most recent - journal events and limit the number of - events shown. If - is used, - this option is implied. The argument, - a positive integer, is optional, and - defaults to 10. - - - - - - Show all stored output - lines, even in follow mode. Undoes the - effect of - . - - - - - - - Controls the - formatting of the journal entries that - are shown. Takes one of - short, - short-monotonic, - verbose, - export, - json, - json-pretty, - json-sse, - cat. short - is the default and generates an output - that is mostly identical to the - formatting of classic syslog log - files, showing one line per journal - entry. short-monotonic - is very similar but shows monotonic - timestamps instead of wallclock - timestamps. verbose - shows the full structured entry items - with all - fields. export - serializes the journal into a binary - (but mostly text-based) stream - suitable for backups and network - transfer (see Journal - Export Format for more - information). json - formats entries as JSON data - structures, one per - line (see Journal - JSON Format for more - information). json-pretty - also formats entries as JSON data - structures, but formats them in - multiple lines in order to make them - more readable for - humans. json-sse - also formats entries as JSON data - structures, but wraps them in a format - suitable for Server-Sent - Events. cat - generates a very terse output only - showing the actual message of each - journal entry with no meta data, not - even a timestamp. - - - - - - - Suppresses any warning - message regarding inaccessible system - journals when run as normal - user. - - - - - - - Show entries - interleaved from all available - journals, including remote - ones. - - - - - - - Show data only from - current boot. This will add a match - for _BOOT_ID= for - the current boot ID of the - kernel. - - - - - - - Show data only of the - specified unit. This will add a match - for _SYSTEMD_UNIT= - for the specified - unit. - - - - - - - Filter output by - message priorities or priority - ranges. Takes either a single numeric - or textual log level (i.e. between - 0/emerg and - 7/debug), or a - range of numeric/text log levels in - the form FROM..TO. The log levels are - the usual syslog log levels as - documented in - syslog3, - i.e. emerg (0), - alert (1), - crit (2), - err (3), - warning (4), - notice (5), - info (6), - debug (7). If a - single log level is specified all - messages with this log level or a - lower (hence more important) log level - are shown. If a range is specified all - messages within the range are shown, - including both the start and the end - value of the range. This will add - PRIORITY= matches - for the specified - priorities. - - - - - - - Start showing entries - from the location in the journal - specified by the passed - cursor. - - - - - - - Start showing entries - on or newer than the specified date, - or on or older than the specified - date, respectively. Date specifications should be of - the format "2012-10-30 18:17:16". If - the time part is omitted, 00:00:00 is - assumed. If only the seconds component - is omitted, :00 is assumed. If the - date component is ommitted, the - current day is assumed. Alternatively - the strings - yesterday, - today, - tomorrow are - understood, which refer to 00:00:00 of - the day before the current day, the - current day, or the day after the - current day, respectively. now - refers to the current time. Finally, - relative times may be specified, - prefixed with - or - +, referring to - times before or after the current - time, respectively. - - - - - - - Print all possible - data values the specified field can - take in all entries of the - journal. - - - - - - - Takes an absolute - directory path as argument. If - specified journalctl will operate on the - specified journal directory instead of - the default runtime and system journal - paths. - - - - - - Instead of showing - journal contents generate a new 128 - bit ID suitable for identifying - messages. This is intended for usage - by developers who need a new - identifier for a new message they - introduce and want to make - recognizable. Will print the new ID in - three different formats which can be - copied into source code or - similar. - - - - - - Instead of showing - journal contents show internal header - information of the journal fields - accessed. - - - - - - Shows the current disk - usage of all - journal files. - - - - - - Instead of showing - journal contents generate a new key - pair for Forward Secure Sealing - (FSS). This will generate a sealing - key and a verification key. The - sealing key is stored in the journal - data directory and shall remain on the - host. The verification key should be - stored externally. - - - - - - Specifies the change - interval for the sealing key, when - generating an FSS key pair with - . Shorter - intervals increase CPU consumption but - shorten the time range of - undetectable journal - alterations. Defaults to - 15min. - - - - - - Check the journal file - for internal consistency. If the - file has been generated with FSS - enabled, and the FSS verification key - has been specified with - - authenticity of the journal file is - verified. - - - - - - Specifies the FSS - verification key to use for the - - operation. - - - - - - - Exit status - - On success 0 is returned, a non-zero failure - code otherwise. - - - - Environment - - - - $SYSTEMD_PAGER - Pager to use when - is not given; - overrides $PAGER. Setting - this to an empty string or the value - cat is equivalent to passing - . - - - - - - Examples - - Without arguments all collected logs are shown - unfiltered: - - journalctl - - With one match specified all entries with a field matching the expression are shown: - - journalctl _SYSTEMD_UNIT=avahi-daemon.service - - If two different fields are matched only entries matching both expressions at the same time are shown: - - journalctl _SYSTEMD_UNIT=avahi-daemon.service _PID=28097 - - If two matches refer to the same field all entries matching either expression are shown: - - journalctl _SYSTEMD_UNIT=avahi-daemon.service _SYSTEMD_UNIT=dbus.service - - If the separator "+" is used - two expressions may be combined in a logical OR. The - following will show all messages from the Avahi - service process with the PID 28097 plus all messages - from the D-Bus service (from any of its - processes): - - journalctl _SYSTEMD_UNIT=avahi-daemon.service _PID=28097 + _SYSTEMD_UNIT=dbus.service - - Show all logs generated by the D-Bus executable: - - journalctl /usr/bin/dbus-daemon - - Show all logs of the kernel device node /dev/sda: - - journalctl /dev/sda - - - - - See Also - - systemd1, - systemd-journald.service8, - systemctl1, - systemd.journal-fields7, - journald.conf5 - - - - diff --git a/man/journald.conf.xml b/man/journald.conf.xml deleted file mode 100644 index 86c9869e51..0000000000 --- a/man/journald.conf.xml +++ /dev/null @@ -1,411 +0,0 @@ - - - - - - - - - journald.conf - systemd - - - - Developer - Lennart - Poettering - lennart@poettering.net - - - - - - journald.conf - 5 - - - - journald.conf - Journal service configuration file - - - - /etc/systemd/journald.conf - - - - Description - - This files configures 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 with the XZ - compression algorithm 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. - - - - SplitMode= - - Controls whether to - split up journal files per user. One - of login, - uid and - none. If - login each logged - in user will get his own journal - files, but systemd user IDs will log - into the system journal. If - uid any user ID - will get his own journal files - regardless whether it belongs to a - system service or refers to a real - logged in user. If - none journal files - are not split up per-user and all - messages are stored in the single - system journal. Note that splitting - up journal files per-user is only - available of journals are stored - persistently. If journals are stored - on volatile storage (see above) only a - single journal file for all user IDs - is kept. Defaults to - login. - - - - 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 - limit. Defaults to 200 messages in - 10s. 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. SystemMaxUse= - and RuntimeMaxUse= - control how much disk space the - journal may use up at - maximum. Defaults to 10% of the size - of the respective file - system. SystemKeepFree= - and - RuntimeKeepFree= - control how much disk space the - journal shall always leave free for - other uses if less than the disk space - configured in - SystemMaxUse= and - RuntimeMaxUse= is - available. Defaults to 5% of the size - of the respective file - system. 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. Note that size limits are - enforced synchronously to journal - files as they are extended, and need - no explicit rotation step triggered by - time. - - - - 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 don't 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, 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 don't 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, m - to override the default time unit of - seconds. - - - - ForwardToSyslog= - ForwardToKMsg= - ForwardToConsole= - - Control whether log - messages received by the journal - daemon shall be forwarded to a - traditional syslog daemon, to the - kernel log buffer (kmsg), or to the - system console. 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 - to syslog 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= - and - systemd.journald.forward_to_console=. - - - - - MaxLevelStore= - MaxLevelSyslog= - MaxLevelKMsg= - MaxLevelConsole= - - Controls the maximum - log level of messages that are stored - on disk, forwarded to syslog, kmsg or - the console (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= and - info for - MaxLevelConsole=. - - - - 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.conf5 - - - - diff --git a/man/kernel-command-line.xml b/man/kernel-command-line.xml deleted file mode 100644 index 27f0d4036f..0000000000 --- a/man/kernel-command-line.xml +++ /dev/null @@ -1,295 +0,0 @@ - - - - - - - - - kernel-command-line - systemd - - - - Developer - Lennart - Poettering - lennart@poettering.net - - - - - - kernel-command-line - 7 - - - - kernel-command-line - Kernel command line parameters - - - - /proc/cmdline - - - - Description - - The kernel, the initial RAM disk (initrd) and - basic userspace functionality may be configured at boot via - kernel command line arguments. - - For command line parameters understood by the - kernel please see kernel-parameters.txt - and - bootparam7. - - For command line paramaters understood by the - initial RAM disk, please see - dracut.cmdline7, - or the documentation of the specific initrd - implementation of your installation. - - - - Core OS Command Line Arguments - - - - systemd.unit= - rd.systemd.unit= - systemd.dump_core= - systemd.crash_shell= - systemd.crash_chvt= - systemd.confirm_spawn= - systemd.show_status= - systemd.log_target= - systemd.log_level= - systemd.log_color= - systemd.log_location= - systemd.default_standard_output= - systemd.default_standard_error= - systemd.setenv= - - Parameters understood by - the system and service manager - to control system behavior. For details see - systemd1. - - - - - quiet - - Parameter understood by - both the kernel and the system - and service manager to control - console log verbosity. For - details see - systemd1. - - - - - emergency - single - s - S - 1 - 2 - 3 - 4 - 5 - - Parameters understood by - the system and service - manager, as compatibility - options. For details see - systemd1. - - - - - 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= - - Parameters understood by - the system and service manager - to control locale and language - settings. For details see - systemd1. - - - - - fsck.mode= - - - Parameter understood by - the file system checker - services. For details see - systemd-fsck@.service8. - - - - - quotacheck.mode= - - - Parameter understood by - the file quota checker - service. For details see - systemd-quotacheck.service8. - - - - - systemd.journald.forward_to_syslog= - systemd.journald.forward_to_kmsg= - systemd.journald.forward_to_console= - - - Parameters understood by - the journal service. For - details see - systemd-journald.service8. - - - - - vconsole.keymap= - vconsole.keymap.toggle= - vconsole.font= - vconsole.font.map= - vconsole.font.unimap= - - - Parameters understood by - the virtual console setup logic. For - details see - systemd-vconsole-setup.service8. - - - - - udev.log-priority= - rd.udev.log-priority= - udev.children-max= - rd.udev.children-max= - udev.exec-delay= - rd.udev.exec-delay= - - - Parameters understood by - the device event managing daemon. For - details see - systemd-udevd.service8. - - - - - plymouth.enable= - - - May be used to disable - the Plymouth boot splash. For - details see - plymouth8. - - - - - luks= - rd.luks= - luks.crypttab= - rd.luks.crypttab= - luks.uuid= - rd.luks.uuid= - - - Configures the LUKS - full-disk encryption logic at - boot. For details see - systemd-cryptsetup-generator8. - - - - - fstab= - rd.fstab= - - - Configures the - /etc/fstab - logic at boot. For details see - systemd-fstab-generator8. - - - - - modules-load= - rd.modules-load= - - - Load a specific kernel - module early at boot. For - details see - systemd-modules-load.service8. - - - - - - - - - See Also - - systemd1, - bootparam7, - dracut.cmdline7, - systemd-fsck@.service8, - systemd-quotacheck.service8, - systemd-journald.service8, - systemd-vconsole-setup.service8, - systemd-udevd.service8, - plymouth8, - systemd-cryptsetup-generator8, - systemd-fstab-generator8, - systemd-modules-load.service8 - - - - diff --git a/man/locale.conf.xml b/man/locale.conf.xml deleted file mode 100644 index 06c0af0bf7..0000000000 --- a/man/locale.conf.xml +++ /dev/null @@ -1,149 +0,0 @@ - - - - - - - - - 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. - - - - 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=C - - - - - - See Also - - systemd1, - locale7, - systemd-localed.service8 - - - - diff --git a/man/localectl.xml b/man/localectl.xml deleted file mode 100644 index 33508cffe5..0000000000 --- a/man/localectl.xml +++ /dev/null @@ -1,259 +0,0 @@ - - - - - - - - - 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. - - - - Options - - The following options are understood: - - - - - - - Prints a short help - text and exits. - - - - - - Prints a short version - string and exits. - - - - - - Do not pipe output into a - pager. - - - - - - Don't query the user - for authentication for privileged - operations. - - - - - - - Execute the operation - remotely. Specify a hostname, or - username and hostname separated by @, - to connect to. This will use SSH to - talk to a remote - system. - - - - - - 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. This - takes a keyboard 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 to the default keyboard - mapping of X11, after converting it to - the closest matching X11 keyboard - mapping. Use - list-locales for a - list of available keyboard mappings - (see below). - - - - list-keymaps - - List available - keyboard mappings for the console, - useful for configuration with - set-keyboard. - - - - set-x11-keymap LAYOUT [MODEL] [VARIANT] [OPTIONS] - - Set the system default - keyboard mapping for X11. 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 to the system console keyboard - mapping, after converting it to the - closest matching console keyboard - mapping. - - - - - - - - Exit status - - On success 0 is returned, a non-zero failure - code otherwise. - - - - Environment - - - - $SYSTEMD_PAGER - Pager to use when - is not given; - overrides $PAGER. Setting - this to an empty string or the value - cat is equivalent to passing - . - - - - - - See Also - - systemd1, - locale7, - locale.conf5, - vconsole.conf5, - loadkeys1, - kbd4, - systemctl1, - systemd-localed.service8 - - - - diff --git a/man/localtime.xml b/man/localtime.xml deleted file mode 100644 index 88c84a3682..0000000000 --- a/man/localtime.xml +++ /dev/null @@ -1,103 +0,0 @@ - - - - - - - - - /etc/localtime - systemd - - - - Developer - Lennart - Poettering - lennart@poettering.net - - - Developer - Shawn - Landden - shawnlandden@gmail.com - - - - - - localtime - 5 - - - - localtime - Local time zone configuration file - - - - /etc/localtime -> ../usr/share/zoneinfo/… - - - - Description - - The /etc/localtime file - configures the system-wide time zone 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 time zone identifier such as - Europe/Berlin or - Etc/UTC. The resulting link should - lead to the corresponding binary - tzfile5 - time zone data for the configured time zone. - - As the time zone identifier is extracted from - the symlink target name of - /etc/localtime this file may not - be a normal file or hardlink. - - The time zone 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. - - - - See Also - - systemd1, - tzset3, - localtime3, - timedatectl1, - systemd-timedated.service8 - - - - diff --git a/man/loginctl.xml b/man/loginctl.xml deleted file mode 100644 index 5dbc1f6967..0000000000 --- a/man/loginctl.xml +++ /dev/null @@ -1,474 +0,0 @@ - - - - - - - - - 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: - - - - - - - Prints a short help - text and exits. - - - - - - Prints a short version - string and exits. - - - - - - - When showing - session/user 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 - unit/job/manager properties, show all - properties regardless whether they are - set or not. - - - - - - - Do not pipe output into a - pager. - - - - - - Don't query the user - for authentication for privileged - operations. - - - - - - 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 - . - - - - - - - Execute operation - remotely. Specify a hostname, or - username and hostname separated by @, - to connect to. This will use SSH to - talk to the remote login manager - instance. - - - - - - - Acquire privileges via - PolicyKit before executing the - operation. - - - - The following commands are understood: - - - - list-sessions - - List current sessions. - - - - session-status [ID...] - - Show terse runtime - status information about one or more - sessions. 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 is 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 one or more - sessions. This brings one or more - sessions into the foreground, if - another session is currently in the - foreground on the respective - seat. - - - - lock-session [ID...] - unlock-session [ID...] - - Activates/deactivates - the screen lock on one or more - sessions, if the session supports it. - - - - lock-sessions - - Activate 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. - - - - list-users - - List currently logged - in users. - - - - user-status [USER...] - - Show terse runtime - status information about one or more - logged in users. 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 is 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 him/her at - boot, and kept around after - logouts. This allows users who aren't - logged in to run long-running - services. - - - - 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. - - - - list-seats - - List currently - available seats on the local - system. - - - - seat-status [NAME...] - - Show terse runtime - status information about one or more - seats. 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 a seat and - deallocates all runtime resources - attached to them. - - - - - - - Exit status - - On success 0 is returned, a non-zero failure - code otherwise. - - - - Environment - - - - $SYSTEMD_PAGER - Pager to use when - is not given; - overrides $PAGER. Setting - this to an empty string or the value - cat is equivalent to passing - . - - - - - - See Also - - systemd1, - systemctl1, - systemd-logind.service8, - logind.conf5 - - - - diff --git a/man/logind.conf.xml b/man/logind.conf.xml deleted file mode 100644 index df15d51b5f..0000000000 --- a/man/logind.conf.xml +++ /dev/null @@ -1,298 +0,0 @@ - - - - - - - - - logind.conf - systemd - - - - Developer - Lennart - Poettering - lennart@poettering.net - - - - - - logind.conf - 5 - - - - logind.conf - Login manager configuration file - - - - /etc/systemd/logind.conf - - - - Description - - This file configures 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 - previously unused -- - autovt services are - automatically spawned on. These - services are instantiated from the - template unit - autovt@.service - for the respective VT TTY name, - e.g. autovt@tty4.service. By - default - autovt@.service - is linked to - getty@.service, - i.e. 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 - 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. Configures the number of 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 how many VTs are allocated - by other subsystems one login - getty is always - available. Defaults to 6 (with other - words: there'll 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 she or he completely logs out (i.e. after - her/his last session ended). Defaults to - no. - - - - KillOnlyUsers= - KillExcludeUsers= - - These settings take - space separated lists of user names - 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. - - - - Controllers= - ResetControllers= - - These settings control - the default control group hierarchies - users logging in are added to. When - logging in users will get private - control groups in all hierarchies - listed in - Controllers= and be - reset to the root control group in all - hierarchies listed in - ResetControllers=. Controllers= - defaults to the empty list, - ResetControllers= - defaults to - cpu. - - - - InhibitDelayMaxSec= - - Specifies the maximum - time a system shutdown or sleep - request is delayed due to an inhibitor - lock of type delay - being active -- before it is ignored - and the operation executed - anyway. Defaults to - 5s. - - - - HandlePowerKey= - HandleSuspendKey= - HandleHibernateKey= - HandleLidSwitch= - - 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. - HandleHibernateKey= - defaults to - hibernate. - - - - 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 - off the inhibitor - locks taken by applications in order - to block the requested operation are - respected, if on - the requested operation is executed in - any - case. PowerKeyIgnoreInhibited=, - SuspendKeyIgnoreInhibited= - and - HibernateKeyIgnoreInhibited= - defaults to off, - LidSwitchIgnoreInhibited= - defaults to - yes. This means - that the lid switch does not respect - suspend blockers by default, but the - power and sleep keys do. - - - - - - Note that setting - KillUserProcesses=1 will break tools - like - screen1. - - Note that KillUserProcesses=1 - is a weaker version of - kill-session-processes=1 which may - be configured per-service for - pam_systemd8. The - latter kills processes of a session as soon as it - ends, the former kills processes as soon as the last - session of the user ends. - - - - See Also - - systemd1, - systemd-logind.service8, - loginctl1, - systemd.conf5 - - - - diff --git a/man/machine-id.xml b/man/machine-id.xml deleted file mode 100644 index 7d424b705b..0000000000 --- a/man/machine-id.xml +++ /dev/null @@ -1,145 +0,0 @@ - - - - - - - - - /etc/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, lowercase 32 - character 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, that 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 POSIX specifies. - - The - systemd-machine-id-setup1 - tool may be used by installer tools to initialize the - machine ID at install time. - - - - Relation to OSF UUIDs - - Note that the machine ID historically is not an - OSF UUID as defined by RFC - 4122, nor a Microsoft GUID. Starting with - systemd v30 newly generated machine IDs however 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 - 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 - - - - diff --git a/man/machine-info.xml b/man/machine-info.xml deleted file mode 100644 index b310d71334..0000000000 --- a/man/machine-info.xml +++ /dev/null @@ -1,154 +0,0 @@ - - - - - - - - - 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 meta data. - - 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 - meta data 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 meta data parameters may - be set using - /etc/machine-info: - - - - - PRETTY_HOSTNAME= - - A pretty - human-readable UTF8 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 host name as configured in - /etc/hostname - should be kept similar to this - one. Example: if this value is - Lennart's Computer - an Internet host name 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. - - - - - - - - Example - - PRETTY_HOSTNAME="Lennart's Computer" -ICON_NAME=computer-laptop - - - - See Also - - systemd1, - os-release5, - hostname5, - machine-id5, - hostnamectl1, - systemd-hostnamed.service8 - - - - diff --git a/man/modules-load.d.xml b/man/modules-load.d.xml deleted file mode 100644 index bcc4d12561..0000000000 --- a/man/modules-load.d.xml +++ /dev/null @@ -1,120 +0,0 @@ - - - - - - - - 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. - - Each configuration file shall be named in the - style of <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 configuration files in - /usr/lib/, files in - /etc/ are reserved for the local - administrator, who may use this logic to override the - configuration files installed from vendor - packages. - - If the administrator wants to disable a - configuration file supplied by the vendor the - recommended way is to place a symlink to - /dev/null in - /etc/modules-load.d/ bearing the - same file name. - - - - 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 - - - - diff --git a/man/os-release.xml b/man/os-release.xml deleted file mode 100644 index 98320efe31..0000000000 --- a/man/os-release.xml +++ /dev/null @@ -1,350 +0,0 @@ - - - - - - - - - os-release - systemd - - - - Developer - Lennart - Poettering - lennart@poettering.net - - - - - - os-release - 5 - - - - os-release - Operating system identification - - - - /etc/os-release - - - - Description - - The /etc/os-release file - contains 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 should be enclosed - in double or single quotes if they include spaces, - semicolons or other special characters outside of A-Z, - a-z, 0-9. All strings should be in UTF-8 format, and - non-printable characters should not be used. If double - or single quotes or backslashes are to be used within - variable assignments they should be escaped with - backslashes, following shell style. It is not - supported to concatenate multiple individually quoted - strings. Lines beginning with "#" shall be ignored as - comments. - - /etc/os-release contains - data that is defined by the operating system vendor - and should not be changed by the administrator. - - As this file only encodes names and identifiers - it should not be localized. - - The file /etc/os-release might - be a symlink to another file, 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 - /etc/os-release please refer to - the Announcement of /etc/os-release. - - - - Options - - The following OS identifications parameters may be set using - /etc/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 file names. 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. 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 - from, and not any OSes that - are derived from it, but 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 file names. 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= - - 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. 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", - and "Report a Bug". 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/" - - - - - - 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 -PRETTY_NAME="Fedora 17 (Beefy Miracle)" -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 - - - - diff --git a/man/pam_systemd.xml b/man/pam_systemd.xml deleted file mode 100644 index 2d2f191487..0000000000 --- a/man/pam_systemd.xml +++ /dev/null @@ -1,319 +0,0 @@ - - - - - - - - - pam_systemd - systemd - - - - Developer - Lennart - Poettering - lennart@poettering.net - - - - - - pam_systemd - 8 - - - - pam_systemd - Register user sessions in the systemd login manager - - - - - pam_systemd.so - - - - - Description - - pam_systemd registers user - sessions in the systemd login manager - systemd-logind.service8, - and hence the systemd control group hierarchy. - - On login, this module ensures the following: - - - If it does not exist yet, the - user runtime directory - /run/user/$USER is - created and its ownership changed to the user - that is logging in. - - The - $XDG_SESSION_ID environment - variable is initialized. If auditing is - available and - pam_loginuid.so run before - this module (which is highly recommended), the - variable is initialized from the auditing - session id - (/proc/self/sessionid). Otherwise - an independent session counter is - used. - - A new control group - /user/$USER/$XDG_SESSION_ID - is created and the login process moved into - it. - - - On logout, this module ensures the following: - - - If - $XDG_SESSION_ID is set and - specified, all - remaining processes in the - /user/$USER/$XDG_SESSION_ID - control group are killed and the control group - is removed. - - If the last subgroup of the - /user/$USER control group - was removed the - $XDG_RUNTIME_DIR directory - and all its contents are - removed, too. - - - If the system was not booted up with systemd as - init system, this module does nothing and immediately - returns PAM_SUCCESS. - - - - - Options - - The following options are understood: - - - - - - Takes a boolean - argument. If true, all processes - created by the user during his session - and from his session will be - terminated when he logs out from his - session. - - - - - - Takes a comma - separated list of user names or - numeric user ids as argument. If this - option is used the effect of the - options - will apply only to the listed - users. If this option is not used the - option applies to all local - users. Note that - - takes precedence over this list and is - hence subtracted from the list - specified here. - - - - - - Takes a comma - separated list of user names or - numeric user ids as argument. Users - listed in this argument will not be - subject to the effect of - . Note - that this option takes precedence - over - , and - hence whatever is listed for - - is guaranteed to never be killed by - this PAM module, independent of any - other configuration - setting. - - - - - - Takes a comma - separated list of control group - controllers in which hierarchies a - user/session control group will be - created by default for each user - logging in, in addition to the control - group in the named 'name=systemd' - hierarchy. If omitted, defaults to an - empty list. - - - - - - Takes a comma - separated list of control group - controllers in which hierarchies the - logged in processes will be reset to - the root control - group. - - - - - - Takes a boolean - argument. If yes, the module will log - debugging information as it - operates. - - - - Note that setting - kill-session-processes=1 will break tools - like - screen1. - - Note that - kill-session-processes=1 is a - stricter version of - KillUserProcesses=1 which may be - configured system-wide in - logind.conf5. The - former kills processes of a session as soon as it - ends, the latter kills processes as soon as the last - session of the user ends. - - If the options are omitted they default to - , - , - , - , - , - . - - - - Module Types Provided - - Only is provided. - - - - Environment - - The following environment variables are set for the processes of the user's session: - - - - $XDG_SESSION_ID - - A session identifier, - suitable to be used in file names. The - string itself should be considered - opaque, although often it is just the - audit session ID as reported by - /proc/self/sessionid. Each - ID will be assigned only once during - machine uptime. It may hence be used - to uniquely label files or other - resources of this - session. - - - - $XDG_RUNTIME_DIR - - Path to a user-private - user-writable directory that is bound - to the user login time on the - machine. It is automatically created - the first time a user logs in and - removed on his final logout. If a user - logs in twice at the same time, both - sessions will see the same - $XDG_RUNTIME_DIR - and the same contents. If a user logs - in once, then logs out again, and logs - in again, the directory contents will - have been lost in between, but - applications should not rely on this - behavior and must be able to deal with - stale files. To store session-private - data in this directory the user should - include the value of $XDG_SESSION_ID - in the filename. This directory shall - be used for runtime file system - objects such as AF_UNIX sockets, - FIFOs, PID files and similar. It is - guaranteed that this directory is - local and offers the greatest possible - file system feature set the - operating system - provides. - - - - - - Example - - #%PAM-1.0 -auth required pam_unix.so -auth required pam_nologin.so -account required pam_unix.so -password required pam_unix.so -session required pam_unix.so -session required pam_loginuid.so -session required pam_systemd.so kill-session-processes=1 - - - - See Also - - systemd1, - systemd-logind.service8, - logind.conf5, - loginctl1, - pam.conf5, - pam.d5, - pam8, - pam_loginuid8 - - - - diff --git a/man/runlevel.xml b/man/runlevel.xml deleted file mode 100644 index 02d5371c5d..0000000000 --- a/man/runlevel.xml +++ /dev/null @@ -1,154 +0,0 @@ - - - - - - - - - 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: - - - - - - Prints a short help - text and exits. - - - - - - - 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 deleted file mode 100644 index a3bf662fe9..0000000000 --- a/man/sd-daemon.xml +++ /dev/null @@ -1,180 +0,0 @@ - - - - - - - - - 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 - Reference implementation of APIs for - new-style daemons - - - - - #include <systemd/sd-daemon.h> - - - - pkg-config --cflags --libs libsystemd-daemon - - - - - - Description - - sd-daemon.c and - sd-daemon.h provide a reference - implementation of various APIs for new-style daemons, - as implemented by the - systemd1 - init system. - - See - sd_listen_fds3, - sd_notify3, - sd_booted3, - sd_is_fifo3 - 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 */ -#define SD_WARNING "<4>" /* warning conditions */ -#define SD_NOTICE "<5>" /* normal but significant condition */ -#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=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"); - - - - - Notes - - These interfaces are provided by the reference - implementation of APIs for new-style daemons and - distributed with the systemd package. The algorithms - they implement are simple, and can easily be - reimplemented in daemons if it is important to support - this interface without using the reference - implementation. See the respective function man pages - for details. - - In addition, for details about the algorithms - check the liberally licensed reference implementation - sources: - - and - - These APIs are implemented in the reference - implementation's sd-daemon.c and - sd-daemon.h files. These - interfaces are available as shared library, which can - be compiled and linked to with the - libsystemd-daemon - pkg-config1 - file. Alternatively, applications consuming these APIs - may copy the implementation into their source tree, - either verbatim or in excerpts. - - The functions directly related to new-style - daemons become NOPs when -DDISABLE_SYSTEMD is set - during compilation and the reference implementation is - used as drop-in files. In addition, if - sd-daemon.c is compiled on - non-Linux systems they become NOPs. - - - - See Also - - systemd1, - sd_listen_fds3, - sd_notify3, - sd_booted3, - sd_is_fifo3, - daemon7, - systemd.service5, - systemd.socket5, - fprintf3, - sd-readahead3, - pkg-config1 - - - - diff --git a/man/sd-id128.xml b/man/sd-id128.xml deleted file mode 100644 index ac2000e275..0000000000 --- a/man/sd-id128.xml +++ /dev/null @@ -1,181 +0,0 @@ - - - - - - - - - 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-id128 - - - - - - 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, though use a simpler string - formatting. 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 128bit 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; -} - - 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; -} - - Note that new, randomized IDs may be generated - with - journalctl1's - --new-id option. - - - - Notes - - These APIs are implemented as a shared library, - which can be compiled and linked to with the - libsystemd-id128 - pkg-config1 - file. - - - - - 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 deleted file mode 100644 index 1beb9a5c7d..0000000000 --- a/man/sd-journal.xml +++ /dev/null @@ -1,130 +0,0 @@ - - - - - - - - - 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-journal - - - - - - 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_cutoff_realtime_usec3, - sd_journal_get_usage3 - 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. - - - - Notes - - These APIs are implemented as shared library, - which can be compiled and linked to with the - libsystemd-journal - pkg-config1 - file. - - - - 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_cutoff_realtime_usec3, - sd_journal_get_usage3, - sd_journal_get_fd3, - sd_journal_query_unique3, - journalctl1, - sd-id1283, - pkg-config1 - - - - diff --git a/man/sd-login.xml b/man/sd-login.xml deleted file mode 100644 index c02ad0c146..0000000000 --- a/man/sd-login.xml +++ /dev/null @@ -1,146 +0,0 @@ - - - - - - - - - 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-login - - - - - 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. Similar, 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. - - - - Notes - - These APIs are implemented as shared library, - which can be compiled and linked to with the - libsystemd-login - pkg-config1 - file. - - - - 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, - sd-readahead3, - pkg-config1 - - - - diff --git a/man/sd-readahead.xml b/man/sd-readahead.xml deleted file mode 100644 index cebaa5da2b..0000000000 --- a/man/sd-readahead.xml +++ /dev/null @@ -1,117 +0,0 @@ - - - - - - - - - sd-readahead - systemd - - - - Developer - Lennart - Poettering - lennart@poettering.net - - - - - - sd-readahead - 3 - - - - sd-readahead - Reference implementation of APIs for - controlling boot-time read-ahead - - - - - #include "sd-readahead.h" - - - - - Description - - sd-readahead.c and - sd-readahead.h provide a - reference implementation for APIs for controlling boot-time - read-ahead, as implemented by the read-ahead subsystem - of the - systemd1 - init system. - - See - sd_readahead3 - for more information about the function - implemented. - - - - Notes - - This interface is provided by the reference - implementation of APIs for controlling boot-time - read-ahead and distributed with the systemd - package. The algorithms it implements are simple, and - can easily be reimplemented in daemons if it is - important to support this interface without using the - reference implementation. See the respective function - man pages for details. - - In addition, for details about the algorithms - check the liberally licensed reference implementation - sources: - - and - - These APIs are implemented in the reference - implementation's drop-in - sd-readahead.c and - sd-readahead.h files. It is - recommended that applications consuming these APIs copy - the implementation into their source tree, either - verbatim or in excerpts. These interfaces are - currently not available in a dynamic library. - - The functions provided by this interface become - NOPs when -DDISABLE_SYSTEMD is set during - compilation. In addition, if - sd-readhead.c is compiled on - non-Linux systems it becomes NOPs. - - - - See Also - - systemd1, - sd_readahead3, - sd-daemon3 - - - - diff --git a/man/sd_booted.xml b/man/sd_booted.xml deleted file mode 100644 index 34f2cbfbc8..0000000000 --- a/man/sd_booted.xml +++ /dev/null @@ -1,128 +0,0 @@ - - - - - - - - - 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 - - This function is provided by the reference - implementation of APIs for new-style daemons and - distributed with the systemd package. The algorithm it - implements is simple, and can easily be reimplemented - in daemons if it is important to support this - interface without using the reference - implementation. - - Internally, this function checks whether the - /sys/fs/cgroup/systemd virtual file - system is mounted, by comparing the st_dev value of - the stat() data of - /sys/fs/cgroup and - /sys/fs/cgroup/systemd. - - For details about the algorithm check the - liberally licensed reference implementation sources: - - and - - sd_booted() is implemented - in the reference implementation's - sd-daemon.c and - sd-daemon.h files. These - interfaces are available as shared library, which can - be compiled and linked to with the - libsystemd-daemon - pkg-config1 - file. Alternatively, applications consuming these APIs - may copy the implementation into their source - tree. For more details about the reference - implementation see - sd-daemon3. - - If the reference implementation is used as - drop-in files and -DDISABLE_SYSTEMD is set during - compilation this function will always return 0 and - otherwise become a NOP. - - - - See Also - - systemd1, - sd-daemon3 - - - - diff --git a/man/sd_get_seats.xml b/man/sd_get_seats.xml deleted file mode 100644 index 17adcef745..0000000000 --- a/man/sd_get_seats.xml +++ /dev/null @@ -1,129 +0,0 @@ - - - - - - - - - sd_get_seats - systemd - - - - Developer - Lennart - Poettering - lennart@poettering.net - - - - - - sd_get_seats - 3 - - - - sd_get_seats - sd_get_sessions - sd_get_uids - Determine available seats, sessions and logged in users - - - - - #include <systemd/sd-login.h> - - - int sd_get_seats - char*** seats - - - - int sd_get_sessions - char*** sessions - - - - int sd_get_uids - char*** sessions - - - - - - - Description - - sd_get_seats() may be used - to determine all currently available local - seats. Returns a NULL terminated array of seat - identifiers. The returned array and all strings it - references need to be freed with the libc - free3 - call after use. Note that instead of an empty array - NULL may be returned and should be considered - equivalent to an empty array. - - Similar, sd_get_sessions() may - be used to determine all current login sessions. - - Similar, sd_get_uids() may - be used to determine all Unix users who currently have login sessions. - - Note that the returned lists are not sorted and in an undefined order. - - - - Return Value - - On success sd_get_seats(), - sd_get_sessions() and - sd_get_uids() return the number - of entries in the arrays. On failure, these calls - return a negative errno-style error code. - - - - Notes - - The sd_get_seats(), - sd_get_sessions() and - sd_get_uids() interfaces - are available as shared library, which can be compiled - and linked to with the - libsystemd-login - pkg-config1 - file. - - - - See Also - - - systemd1, - sd-login3, - sd_session_get_seat3 - - - - diff --git a/man/sd_id128_get_machine.xml b/man/sd_id128_get_machine.xml deleted file mode 100644 index 039c1dd64c..0000000000 --- a/man/sd_id128_get_machine.xml +++ /dev/null @@ -1,138 +0,0 @@ - - - - - - - - - sd_id128_get_machine - systemd - - - - Developer - Lennart - Poettering - lennart@poettering.net - - - - - - sd_id128_get_machine - 3 - - - - sd_id128_get_machine - sd_id128_get_boot - Retrieve 128 bit IDs - - - - - #include <systemd/sd-id128.h> - - - int sd_id128_get_machine - sd_id128_t* ret - - - - int sd_id128_get_boot - sd_id128_t* ret - - - - - - - Description - - sd_id128_get_machine() - returns the machine ID of the executing host. This - reads and parses the - machine-id5 - file. This function caches the machine ID internally - to make retrieving the machine ID a cheap - operation. - - sd_id128_get_boot() returns - the boot ID of the executing kernel. This reads and - parses the - /proc/sys/kernel/random/boot_id - file exposed by the kernel. It is randomly generated - early at boot and is unique for every running kernel - instance. See - random4 - for more information. This function also internally - caches the returned ID to make this call a cheap - operation. - - Note that - sd_id128_get_boot() always returns - a UUID v4 compatible - ID. sd_id128_get_machine() will - also return a UUID v4 compatible ID on new - installations, but might not on older. It is possible - to convert the machine ID into an UUID v4 compatible - one. For more information see - machine-id5. - - For more information about the - sd_id128_t type see - sd-id1283. - - - - Return Value - - The two calls return 0 on success (in which - case ret is filled in), or a - negative errno-style error code. - - - - Notes - - The sd_id128_get_machine() - and sd_id128_get_boot() - interfaces are available as shared library, which can - be compiled and linked to with the - libsystemd-id128 - pkg-config1 - file. - - - - See Also - - - systemd1, - sd-id1283, - machine-id5, - random4, - sd_id128_randomize3 - - - - diff --git a/man/sd_id128_randomize.xml b/man/sd_id128_randomize.xml deleted file mode 100644 index be74937dd0..0000000000 --- a/man/sd_id128_randomize.xml +++ /dev/null @@ -1,118 +0,0 @@ - - - - - - - - - sd_id128_randomize - systemd - - - - Developer - Lennart - Poettering - lennart@poettering.net - - - - - - sd_id128_randomize - 3 - - - - sd_id128_randomize - Generate 128 bit IDs - - - - - #include <systemd/sd-id128.h> - - - int sd_id128_randomize - sd_id128_t* ret - - - - - - - Description - - sd_id128_randomize() - generates a new randomized 128 bit ID and returns it - in ret. Every invocation - returns a new randomly generated ID. This uses the - /dev/urandom kernel random number - generator. - - Note that - sd_id128_randomize() always returns - a UUID v4 compatible - ID. - - For more information about the - sd_id128_t type see - sd-id1283. - - journalctl1's - --new-id command may be used as - command line front-end for - sd_id128_randomize(). - - - - Return Value - - The call returns 0 on success (in which - case ret is filled in), or a - negative errno-style error code. - - - - Notes - - The sd_id128_randomize() interface - is available as shared library, which can be compiled - and linked to with the - libsystemd-id128 - pkg-config1 - file. - - - - See Also - - - systemd1, - sd-id1283, - machine-id5, - random4, - sd_id128_get_machine3 - - - - diff --git a/man/sd_id128_to_string.xml b/man/sd_id128_to_string.xml deleted file mode 100644 index ec8b263e0d..0000000000 --- a/man/sd_id128_to_string.xml +++ /dev/null @@ -1,131 +0,0 @@ - - - - - - - - - sd_id128_to_string - systemd - - - - Developer - Lennart - Poettering - lennart@poettering.net - - - - - - sd_id128_to_string - 3 - - - - sd_id128_to_string - sd_id128_from_string - Format or parse 128 bit IDs as strings - - - - - #include <systemd/sd-id128.h> - - - char* sd_id128_to_string - sd_id128_t id, char s[33] - - - - int sd_id128_from_string - const char s[33], sd_id128_t* ret - - - - - - - Description - - sd_id128_to_string() - formats a 128 bit ID as character string. It expects - the ID and a string array capable of storing 33 - characters. The ID will be formatted as 32 lowercase - hexadecimal digits and be terminated by a NUL - byte. - - sd_id128_from_string() - implements the reverse operation: it takes a 33 - character array with 32 hexadecimal digits - (terminated by NUL) and parses them back into an - 128 bit ID returned in - ret. - - For more information about the - sd_id128_t type see - sd-id1283. - - When formatting a 128 bit ID into a string it is - often easier to use a format string for - printf3. This - is easily done using the - SD_ID128_FORMAT_STR and - SD_ID128_FORMAT_VAL() macros. For - more information see - sd-id1283. - - - - Return Value - - sd_id128_to_string() always - succeeds and returns a pointer to the string array - passed in. sd_id128_from_string - returns 0 on success (in which case - ret is filled in), or a negative - errno-style error code. - - - - Notes - - The sd_id128_to_string() - and sd_id128_from_string() interfaces are - available as shared library, which can be compiled and - linked to with the libsystemd-id128 - pkg-config1 - file. - - - - See Also - - - systemd1, - sd-id1283, - printf3 - - - - diff --git a/man/sd_is_fifo.xml b/man/sd_is_fifo.xml deleted file mode 100644 index 595c8f112d..0000000000 --- a/man/sd_is_fifo.xml +++ /dev/null @@ -1,217 +0,0 @@ - - - - - - - - - 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 - 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 - - - - - - - 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 - 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. - - - - 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 - - These functions are provided by the reference - implementation of APIs for new-style daemons and - distributed with the systemd package. The algorithms - they implement are simple, and can easily be - reimplemented in daemons if it is important to support - this interface without using the reference - implementation. - - Internally, these function use a combination of - fstat() and - getsockname() to check the file - descriptor type and where it is bound to. - - For details about the algorithms check the - liberally licensed reference implementation sources: - - and - - sd_is_fifo() and the - related functions are implemented in the reference - implementation's sd-daemon.c and - sd-daemon.h files. These - interfaces are available as shared library, which can - be compiled and linked to with the - libsystemd-daemon - pkg-config1 - file. Alternatively, applications consuming these APIs - may copy the implementation into their source - tree. For more details about the reference - implementation see - sd-daemon3. - - These functions continue to work as described, - even if -DDISABLE_SYSTEMD is set during - compilation. - - - - 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 deleted file mode 100644 index ad2486d749..0000000000 --- a/man/sd_journal_add_match.xml +++ /dev/null @@ -1,189 +0,0 @@ - - - - - - - - - sd_journal_add_match - systemd - - - - Developer - Lennart - Poettering - lennart@poettering.net - - - - - - sd_journal_add_match - 3 - - - - sd_journal_add_match - sd_journal_add_disjunction - sd_journal_flush_matches - Add or remove entry matches - - - - - #include <systemd/sd-journal.h> - - - int sd_journal_add_match - sd_journal* j - const void* data - size_t size - - - - int sd_journal_add_disjunction - sd_journal* j - - - - int sd_journal_flush_matches - sd_journal* j - - - - - - Description - - sd_journal_add_match() adds - a match by which to filter the entries of the journal - file. Matches applied with this call will filter what - can be iterated through and read from the journal file - via calls like - sd_journal_next3 - and - sd_journal_get_data3. Matches - are of the form FIELD=value, where - the field part is a short uppercase string consisting - only of 0-9, A-Z and the underscore. It may not begin - with two underscores or be the empty string. The value - part may be any value, including binary. If a match is - applied only entries with this field set will be - iterated. Multiple matches may be active at the same - time: if they apply to different fields only entries - with both fields set like this will be iterated, if - they apply to the same fields only entries where the - field takes one of the specified values will be - iterated. Well known fields are documented in - systemd.journal-fields7. Whenever - a new match is added the current entry position is - reset, and - sd_journal_next3 (or a similar call) - needs to be called before entries can be read - again. - - sd_journal_add_disjunction() - may be used to insert a disjunction (i.e. logical OR) - in the match list. If this call is invoked all - previously added matches are combined in an OR with - all matches added afterwards, until - sd_journal_add_disjunction() is - invoked again to begin the next OR term. The - combination of - sd_journal_add_match() and - sd_journal_add_disjunction() may - be used to build complex search terms, even though - full logical expressions are not available. - - sd_journal_flush_matches() - may be used to flush all matches and disjunction terms - again. After this call all filtering is removed and - all entries in the journal will be iterated - again. - - Note that filtering via matches only applies to - the way the journal is read, it has no effect on storage - on disk. - - - - Return Value - - sd_journal_add_match() and - sd_journal_add_disjunction() - return 0 on success or a negative errno-style error - code. sd_journal_flush_matches() - returns nothing. - - - - Notes - - The sd_journal_add_match(), - sd_journal_add_disjunction() and - sd_journal_flush_matches() interfaces are - available as shared library, which can be compiled and - linked to with the - libsystemd-journal - pkg-config1 - file. - - - - Examples - - The following example adds matches to a journal - context object to iterate only through messages - generated by the Avahi service at the four error log - levels, plus all messages of the message ID - 03bb1dab98ab4ecfbf6fff2738bdd964 coming from any - service (this example lacks the necessary error - checking): - - ... -int add_matches(sd_journal *j) { - sd_journal_add_match(j, "_SYSTEMD_UNIT=avahi-daemon.service", 0); - sd_journal_add_match(j, "PRIORITY=0", 0); - sd_journal_add_match(j, "PRIORITY=1", 0); - sd_journal_add_match(j, "PRIORITY=2", 0); - sd_journal_add_match(j, "PRIORITY=3", 0); - sd_journal_add_disjunction(j); - sd_journal_add_match(j, "MESSAGE_ID=03bb1dab98ab4ecfbf6fff2738bdd964", 0); -} - - - - - See Also - - - systemd1, - sd-journal3, - sd_journal_open3, - sd_journal_next3, - sd_journal_get_data3, - systemd.journal-fields7 - - - - diff --git a/man/sd_journal_get_cursor.xml b/man/sd_journal_get_cursor.xml deleted file mode 100644 index 354168bee2..0000000000 --- a/man/sd_journal_get_cursor.xml +++ /dev/null @@ -1,151 +0,0 @@ - - - - - - - - - sd_journal_get_cursor - systemd - - - - Developer - Lennart - Poettering - lennart@poettering.net - - - - - - sd_journal_get_cursor - 3 - - - - sd_journal_get_cursor - sd_journal_test_cursor - Get cursor string for or test cursor string against the current journal entry - - - - - #include <systemd/sd-journal.h> - - - int sd_journal_get_cursor - sd_journal* j - char ** cursor - - - - int sd_journal_test_cursor - sd_journal* j - const char * cursor - - - - - - - Description - - sd_journal_get_cursor() - returns a cursor string for the current journal - entry. A cursor is a serialization of the current - journal position formatted as text. The string only - contains printable characters and can be passed around - in text form. The cursor identifies a journal entry - globally and in a stable way and may be used to later - seek to it via - sd_journal_seek_cursor3. The - cursor string should be considered opaque and not be - parsed by clients. Seeking to a cursor position - without the specific entry being available locally - will seek to the next closest (in terms of time) - available entry. The call takes two arguments: a - journal context object and a pointer to a string - pointer where the cursor string will be placed. The - string is allocated via libc - malloc3 - and should be freed after use with - free3. - - Note that - sd_journal_get_cursor() will not - work before - sd_journal_next3 - (or related call) has been called at least once, in - order to position the read pointer at a valid - entry. - - sd_journal_test_cursor() - may be used to check whether the current position in - the journal matches the specified cursor. This is - useful since cursor strings do not uniquely identify - an entry: the same entry might be referred to by - multiple different cursor strings, and hence string - comparing cursors is not possible. Use this call to - verify after an invocation of - sd_journal_seek_cursor3 - whether the entry being seeked to was actually found - in the journal or the next closest entry was used - instead. - - - - Return Value - - sd_journal_get_cursor() - returns 0 on success or a negative errno-style error - code. sd_journal_test_cursor() - returns positive if the current entry matches the - specified cursor, 0 if it doesn't match the specified - cursor or a negative errno-style error code on - failure. - - - - Notes - - The sd_journal_get_cursor() - and sd_journal_test_cursor() - interfaces are available as shared library, which can - be compiled and linked to with the - libsystemd-journal - pkg-config1 - file. - - - - See Also - - - systemd1, - sd-journal3, - sd_journal_open3, - sd_journal_seek_cursor3 - - - - diff --git a/man/sd_journal_get_cutoff_realtime_usec.xml b/man/sd_journal_get_cutoff_realtime_usec.xml deleted file mode 100644 index ed014cb509..0000000000 --- a/man/sd_journal_get_cutoff_realtime_usec.xml +++ /dev/null @@ -1,142 +0,0 @@ - - - - - - - - - sd_journal_get_cutoff_realtime_usec - systemd - - - - Developer - Lennart - Poettering - lennart@poettering.net - - - - - - sd_journal_get_cutoff_realtime_usec - 3 - - - - sd_journal_get_cutoff_realtime_usec - sd_journal_get_cutoff_monotonic_usec - Read cut-off timestamps from the current journal entry - - - - - #include <systemd/sd-journal.h> - - - int sd_journal_get_cutoff_realtime_usec - sd_journal* j - uint64_t* from - uint64_t* to - - - - int sd_journal_get_cutoff_monotonic_usec - sd_journal* j - sd_id128_t boot_id - uint64_t* from - uint64_t* to - - - - - - - Description - - sd_journal_get_cutoff_realtime_usec() - gets the realtime (wallclock) timestamps of the first - and last entries accessible in the journal. It takes - three arguments: the journal context object and two - pointers to 64 Bit unsigned integers to store the - timestamps in. The timestamps are in microseconds - since the epoch, i.e. CLOCK_REALTIME. Either one of - the two timestamp arguments may be passed as NULL in - case the timestamp is not needed, but not both. - - sd_journal_get_cutoff_monotonic_usec() - gets the monotonic timestamps of the first and last - entries accessible in the journal. It takes three - arguments: the journal context object, a 128 Bit - identifier for the boot, and two pointers to 64 Bit - unsigned integers to store the timestamps. The - timestamps are in microseconds since boot-up of the - specific boot, i.e. CLOCK_MONOTONIC. Since the - monotonic clock begins new with every reboot it only - defines a well-defined point in time when used - together with an identifier identifying the boot, see - sd_id128_get_boot3 - for more information. The function will return the - timestamps for the boot identified by the passed boot - ID. Either one of the two timestamp arguments may be - passed as NULL in case the timestamp is not needed, - but not both. - - - - Return Value - - sd_journal_get_cutoff_realtime_usec() - and - sd_journal_get_cutoff_monotonic_usec() - return 1 on success, 0 if not suitable entries are in - the journal or a negative errno-style error code. - - - - Notes - - The - sd_journal_get_cutoff_realtime_usec() - and - sd_journal_get_cutoff_monotonic_usec() - interfaces are available as shared library, which can - be compiled and linked to with the - libsystemd-journal - pkg-config1 - file. - - - - See Also - - - systemd1, - sd-journal3, - sd_journal_open3, - sd_journal_get_realtime_usec3, - sd_id128_get_boot3, - clock_gettime2 - - - - diff --git a/man/sd_journal_get_data.xml b/man/sd_journal_get_data.xml deleted file mode 100644 index 6470f19cc6..0000000000 --- a/man/sd_journal_get_data.xml +++ /dev/null @@ -1,201 +0,0 @@ - - - - - - - - - sd_journal_get_data - systemd - - - - Developer - Lennart - Poettering - lennart@poettering.net - - - - - - sd_journal_get_data - 3 - - - - sd_journal_get_data - sd_journal_enumerate_data - sd_journal_restart_data - SD_JOURNAL_FOREACH_DATA - Read data fields from the current journal entry - - - - - #include <systemd/sd-journal.h> - - - int sd_journal_get_data - sd_journal* j - const char* field - const void** data - size_t* length - - - - int sd_journal_enumerate_data - sd_journal* j - const void** data - size_t* length - - - - void sd_journal_restart_data - sd_journal* j - - - - SD_JOURNAL_FOREACH_DATA - sd_journal* j - const void* data - size_t length - - - - - - - Description - - sd_journal_get_data() gets - the data object associated with a specific field from - the current journal entry. It takes four arguments: - the journal context object, a string with the field - name to request, plus a pair of pointers to - pointer/size variables where the data object and its - size shall be stored in. The field name should be an - entry field name. Well-known field names are listed in - systemd.journal-fields7. The - returned data is in a read-only memory map and is only - valid until the next invocation of - sd_journal_get_data() or - sd_journal_enumerate_data(), or - the read pointer is altered. Note that the data - returned will be prefixed with the field name and - '='. - - sd_journal_enumerate_data() - may be used to iterate through all fields of the - current entry. On each invocation the data for the - next field is returned. The order of these fields is - not defined. The data returned is in the same format - as with sd_journal_get_data() and - also follows the same life-time semantics. - - sd_journal_restart_data() - resets the data enumeration index to the beginning of - the entry. The next invocation of - sd_journal_enumerate_data() will return the first - field of the entry again. - - Note that the - SD_JOURNAL_FOREACH_DATA() macro - may be used as a handy wrapper around - sd_journal_restart_data() and - sd_journal_enumerate_data(). - - Note that these functions will not work before - sd_journal_next3 - (or related call) has been called at least - once, in order to position the read pointer at a valid entry. - - - - Return Value - - sd_journal_get_data() - returns 0 on success or a negative errno-style error - code. If the current entry does not include the - specified field -ENOENT is returned. If - sd_journal_next3 - has not been called at least once -EADDRNOTAVAIL is - returned. sd_journal_enumerate_data() - returns a positive integer if the next field has been - read, 0 when no more fields are known, or a negative - errno-style error - code. sd_journal_restart_data() - returns nothing. - - - - Notes - - The sd_journal_get_data(), - sd_journal_enumerate_data() and - sd_journal_restart_data() - interfaces are available as shared library, which can - be compiled and linked to with the - libsystemd-journal - pkg-config1 - file. - - - - Examples - - See - sd_journal_next3 - for a complete example how to use - sd_journal_get_data(). - - Use the - SD_JOURNAL_FOREACH_DATA macro to - iterate through all fields of the current journal - entry: - - ... -int print_fields(sd_journal *j) { - const void *data; - size_t l; - SD_JOURNAL_FOREACH_DATA(j, data, length) - printf("%.*s\n", (int) length, data); -} -... - - - - - See Also - - - systemd1, - systemd.journal-fields7, - sd-journal3, - sd_journal_open3, - sd_journal_next3, - sd_journal_get_realtime_usec3, - sd_journal_query_unique3 - - - - diff --git a/man/sd_journal_get_fd.xml b/man/sd_journal_get_fd.xml deleted file mode 100644 index 189d21352b..0000000000 --- a/man/sd_journal_get_fd.xml +++ /dev/null @@ -1,272 +0,0 @@ - - - - - - - - - sd_journal_get_fd - systemd - - - - Developer - Lennart - Poettering - lennart@poettering.net - - - - - - sd_journal_get_fd - 3 - - - - sd_journal_get_fd - sd_journal_reliable_fd - sd_journal_process - sd_journal_wait - SD_JOURNAL_NOP - SD_JOURNAL_APPEND - SD_JOURNAL_INVALIDATE - Journal change notification - interface - - - - - #include <systemd/sd-journal.h> - - - int sd_journal_get_fd - sd_journal* j - - - - int sd_journal_reliable_fd - sd_journal* j - - - - int sd_journal_process - sd_journal* j - - - - int sd_journal_wait - sd_journal* j - uint64_t timeout_usec - - - - - - - Description - - sd_journal_get_fd() returns - a file descriptor that may be asynchronously polled in - an external event loop and is signaled readable as - soon as the journal changes, because new entries or - files were added, rotation took place, or files have - been deleted, and similar. The file descriptor is - suitable for usage in - poll2 - where it will yield POLLIN on changes. The call takes - one argument: the journal context object. Note that - not all file systems are capable of generating the - necessary events for wakeups from this file descriptor - to be enirely reliable. In particular network files - systems do not generate suitable file change events in - all cases. In such a case an application should not - rely alone on wake-ups from this file descriptor but - wake up and recheck the journal in regular time - intervals, for example every 2s. To detect - cases where this is necessary, use - sd_journal_reliable_fd(), - below. - - sd_journal_reliable_fd() - may be used to check whether the wakeup events from - the file descriptor returned by - sd_journal_get_fd are sufficient - to track changes to the journal. If this call returns - 0, it is necessary to regularly recheck for journal - changes (suggestion: every 2s). If this call returns a - positive integer this is not necessary, and wakeups - from the file descriptor returned by - sd_journal_get_fd() are - sufficient as only source for wake-ups. - - After each POLLIN wake-up - sd_journal_process() needs to be - called to process events and reset the readable state - of the file descriptor. This call will also indicate - what kind of change has been detected (see below; note - that spurious wake-ups are possible). - - A synchronous alternative for using - sd_journal_get_fd(), - sd_journal_reliable_fd() and - sd_journal_process() is - sd_journal_wait(). It will - synchronously wait until the journal gets changed, - possibly using a 2s time-out if this is necessary (see - above). In either way the maximum time this call - sleeps may be controlled with the - timeout_usec parameter. Pass - (uint64_t) -1 to wait - indefinitely. Internally this call simply combines - sd_journal_get_fd(), - sd_journal_reliable_fd(), - poll() and - sd_journal_process() into - one. - - - - - Return Value - - sd_journal_get_fd() returns a valid file descriptor on success or a negative errno-style error - code. - - sd_journal_reliable_fd() - returns a positive integer if the file descriptor - returned by sd_journal_get_fd() - is sufficient as sole wake-up source for journal - change events. Returns 0 if it is not sufficient and - the journal needs to be checked manually in regular - time intervals for changes. Returns a negative - errno-style error code on failure. - - sd_journal_process() and - sd_journal_wait() return one of - SD_JOURNAL_NOP, - SD_JOURNAL_APPEND or - SD_JOURNAL_INVALIDATE on success or - a negative errno-style error code. If - SD_JOURNAL_NOP is returned the - journal didn't change since the last invocation. If - SD_JOURNAL_APPEND is returned new - entries have been appended to the end of the - journal. If SD_JOURNAL_INVALIDATE - journal files were added or removed (possibly due to - rotation). In the latter event live-view UIs should - probably refresh their entire display while in the - case of SD_JOURNAL_APPEND it is - sufficient to simply continue reading at the previous - end of the journal. - - - - Notes - - The sd_journal_get_fd(), - sd_journal_reliable_fd(), - sd_journal_process() and - sd_journal_wait() interfaces are - available as shared library, which can be compiled and - linked to with the - libsystemd-journal - pkg-config1 - file. - - - - Examples - - Iterating through the journal, in a live view tracking all changes: - - #include <stdio.h> -#include <string.h> -#include <systemd/sd-journal.h> - -int main(int argc, char *argv[]) { - int r; - sd_journal *j; - r = sd_journal_open(&j, SD_JOURNAL_LOCAL_ONLY); - if (r < 0) { - fprintf(stderr, "Failed to open journal: %s\n", strerror(-r)); - return 1; - } - for (;;) { - const char *d; - size_t l; - r = sd_journal_next(j); - if (r < 0) { - fprintf(stderr, "Failed to iterate to next entry: %s\n", strerror(-r)); - break; - } - if (r == 0) { - /* Reached the end, let's wait for changes, and try again */ - r = sd_journal_wait(j, (uint64_t) -1); - if (r < 0) { - fprintf(stderr, "Failed to wait for changes: %s\n", strerror(-r)); - break; - } - continue; - } - r = sd_journal_get_data(j, "MESSAGE", &d, &l); - if (r < 0) { - fprintf(stderr, "Failed to read message field: %s\n", strerror(-r)); - continue; - } - printf("%.*s\n", (int) l, d); - } - sd_journal_close(j); - return 0; -} - - Waiting with poll() (this - example lacks all error checking for the sake of - simplicity): - - #include <sys/poll.h> -#include <systemd/sd-journal.h> - -int wait_for_changes(sd_journal *j) { - struct pollfd pollfd; - pollfd.fd = sd_journal_get_fd(); - pollfd.events = POLLIN; - poll(&pollfd, 1, sd_journal_reliable_fd() > 0 ? -1 : 2000); - return sd_journal_process(j); -} - - - - - - See Also - - - systemd1, - sd-journal3, - sd_journal_open3, - sd_journal_next3, - poll2 - - - - diff --git a/man/sd_journal_get_realtime_usec.xml b/man/sd_journal_get_realtime_usec.xml deleted file mode 100644 index 515932c6d8..0000000000 --- a/man/sd_journal_get_realtime_usec.xml +++ /dev/null @@ -1,146 +0,0 @@ - - - - - - - - - sd_journal_get_realtime_usec - systemd - - - - Developer - Lennart - Poettering - lennart@poettering.net - - - - - - sd_journal_get_realtime_usec - 3 - - - - sd_journal_get_realtime_usec - sd_journal_get_monotonic_usec - Read timestamps from the current journal entry - - - - - #include <systemd/sd-journal.h> - - - int sd_journal_get_realtime_usec - sd_journal* j - uint64_t* usec - - - - int sd_journal_get_monotonic_usec - sd_journal* j - uint64_t* usec - sd_id128_t* boot_id - - - - - - - Description - - sd_journal_get_realtime_usec() - gets the realtime (wallclock) timestamp of the - current journal entry. It takes two arguments: the - journal context object and a pointer to a 64 Bit - unsigned integer to store the timestamp in. The - timestamp is in microseconds since the epoch, - i.e. CLOCK_REALTIME. - - sd_journal_get_monotonic_usec() - gets the monotonic timestamp of the current - journal entry. It takes three arguments: the journal - context object, a pointer to a 64 Bit unsigned integer - to store the timestamp in as well as a 128 Bit ID - buffer to store the boot ID of the monotonic timestamp - in. The timestamp is in microseconds since boot-up of - the specific boot, i.e. CLOCK_MONOTONIC. Since the - monotonic clock begins new with every reboot it only - defines a well-defined point in time when used - together with an identifier identifying the boot, see - sd_id128_get_boot3 - for more information. If the boot ID parameter is - passed NULL the function will fail if the monotonic - timestamp of the current entry is not of the current - system boot. - - Note that these functions will not work before - sd_journal_next3 - (or related call) has been called at least - once, in order to position the read pointer at a valid entry. - - - - Return Value - - sd_journal_get_realtime_usec() - and - sd_journal_get_monotonic_usec() - returns 0 on success or a negative errno-style error - code. If the boot ID parameter was passed NULL and the - monotonic timestamp of the current journal entry is - not of the current system boot, -ESTALE is returned by sd_journal_get_monotonic_usec(). - - - - Notes - - The - sd_journal_get_realtime_usec() - and - sd_journal_get_monotonic_usec() - interfaces are available as shared library, which can - be compiled and linked to with the - libsystemd-journal - pkg-config1 - file. - - - - See Also - - - systemd1, - sd-journal3, - sd_journal_open3, - sd_journal_next3, - sd_journal_get_data3, - sd_id128_get_boot3, - clock_gettime2, - sd_journal_get_cutoff_realtime_usec3 - - - - diff --git a/man/sd_journal_get_usage.xml b/man/sd_journal_get_usage.xml deleted file mode 100644 index 14eb1e2b79..0000000000 --- a/man/sd_journal_get_usage.xml +++ /dev/null @@ -1,104 +0,0 @@ - - - - - - - - - sd_journal_get_usage - systemd - - - - Developer - Lennart - Poettering - lennart@poettering.net - - - - - - sd_journal_get_usage - 3 - - - - sd_journal_get_usage - Journal disk usage - - - - - #include <systemd/sd-journal.h> - - - int sd_journal_get_usage - sd_journal* j - uint64_t* bytes - - - - - - - Description - - sd_journal_get_usage() - determines the total disk space currently used up by - journal files. If - SD_JOURNAL_LOCAL_ONLY has been - passed when opening the journal files this value will - only reflect the size of journal files of the local - host, otherwise of all hosts. - - - - Return Value - - sd_journal_get_usage() - returns 0 on success or a negative errno-style error - code. - - - - Notes - - The sd_journal_get_usage() - interface is available as shared library, which can be - compiled and linked to with the - libsystemd-journal - pkg-config1 - file. - - - - See Also - - - systemd1, - sd-journal3, - sd_journal_open3, - - - - diff --git a/man/sd_journal_next.xml b/man/sd_journal_next.xml deleted file mode 100644 index 9b1cb1fc46..0000000000 --- a/man/sd_journal_next.xml +++ /dev/null @@ -1,214 +0,0 @@ - - - - - - - - - sd_journal_next - systemd - - - - Developer - Lennart - Poettering - lennart@poettering.net - - - - - - sd_journal_next - 3 - - - - sd_journal_next - sd_journal_previous - sd_journal_next_skip - sd_journal_previous_skip - SD_JOURNAL_FOREACH - SD_JOURNAL_FOREACH_BACKWARDS - Advance or set back the read pointer in the journal - - - - - #include <systemd/sd-journal.h> - - - int sd_journal_next - sd_journal* j - - - - int sd_journal_previous - sd_journal* j - - - - int sd_journal_next_skip - sd_journal* j - uint64_t skip - - - - int sd_journal_previous_skip - sd_journal* j - uint64_t skip - - - - SD_JOURNAL_FOREACH - sd_journal* j - - - - SD_JOURNAL_FOREACH_BACKWARDS - sd_journal* j - - - - - - Description - - sd_journal_next() advances - the read pointer into the journal by one entry. The - only argument taken is a journal context object as - allocated via - sd_journal_open3. After - successful invocation the entry may be read with - functions such as - sd_journal_get_data3. - - Similar, sd_journal_previous() sets - the read pointer back one entry. - - sd_journal_next_skip() and - sd_journal_previous_skip() - advance/set back the read pointer by multiple entries - at once, as specified in the skip - parameter. - - The journal is strictly ordered by reception - time, and hence advancing to the next entry guarantees - that the entry then pointing to is later in time than - then previous one, or has the same timestamp. - - Note that - sd_journal_get_data3 - and related calls will fail unless - sd_journal_next() has been - invoked at least once in order to position the read - pointer on a journal entry. - - Note that the - SD_JOURNAL_FOREACH() macro may be used - as a wrapper around - sd_journal_seek_head3 - and sd_journal_next() in order to - make iterating through the journal easier. See below - for an example. Similar, - SD_JOURNAL_FOREACH_BACKWARDS() - may be used for iterating the journal in reverse - order. - - - - Return Value - - The four calls return the number of entries - advanced/set back on success or a negative errno-style - error code. When the end or beginning of the journal - is reached, a number smaller than requested is - returned. More specifically, if - sd_journal_next() or - sd_journal_previous() reach the - end/beginning of the journal they will return 0, - instead of 1 when they are successful. This should be - considered an EOF marker. - - - - Notes - - The sd_journal_next(), sd_journal_previous(), - sd_journal_next_skip() and - sd_journal_previous_skip() interfaces are - available as shared library, which can be compiled and - linked to with the - libsystemd-journal - pkg-config1 - file. - - - - Examples - - Iterating through the journal: - - #include <stdio.h> -#include <string.h> -#include <systemd/sd-journal.h> - -int main(int argc, char *argv[]) { - int r; - sd_journal *j; - r = sd_journal_open(&j, SD_JOURNAL_LOCAL_ONLY); - if (r < 0) { - fprintf(stderr, "Failed to open journal: %s\n", strerror(-r)); - return 1; - } - SD_JOURNAL_FOREACH(j) { - const char *d; - size_t l; - - r = sd_journal_get_data(j, "MESSAGE", &d, &l); - if (r < 0) { - fprintf(stderr, "Failed to read message field: %s\n", strerror(-r)); - continue; - } - - printf("%.*s\n", (int) l, d); - } - sd_journal_close(j); - return 0; -} - - - - - See Also - - - systemd1, - sd-journal3, - sd_journal_open3, - sd_journal_get_data3, - sd_journal_get_realtime_usec3, - sd_journal_get_cursor3 - - - - diff --git a/man/sd_journal_open.xml b/man/sd_journal_open.xml deleted file mode 100644 index 06d0ccfd12..0000000000 --- a/man/sd_journal_open.xml +++ /dev/null @@ -1,184 +0,0 @@ - - - - - - - - - sd_journal_open - systemd - - - - Developer - Lennart - Poettering - lennart@poettering.net - - - - - - sd_journal_open - 3 - - - - sd_journal_open - sd_journal_open_directory - sd_journal_close - sd_journal - SD_JOURNAL_LOCAL_ONLY - SD_JOURNAL_RUNTIME_ONLY - SD_JOURNAL_SYSTEM_ONLY - Open the system journal for reading - - - - - #include <systemd/sd-journal.h> - - - int sd_journal_open - sd_journal** ret - int flags - - - - int sd_journal_open_directory - sd_journal** ret - const char* path - int flags - - - - int sd_journal_close - sd_journal* j - - - - - - Description - - sd_journal_open() opens - the log journal for reading. It will find all journal - files automatically and interleave them automatically - when reading. As first argument it takes a pointer to - a sd_journal pointer, which on - success will contain journal context object afterwards. The - second argument is a flags field, which may consist of - the following flags ORed together: - SD_JOURNAL_LOCAL_ONLY makes sure - only journal files generated on the local machine will - be opened. SD_JOURNAL_RUNTIME_ONLY - makes sure only volatile journal files will be opened, - excluding those which are stored on persistent - storage. SD_JOURNAL_SYSTEM_ONLY - will ensure that only journal files of system services - and the kernel (in opposition to user session processes) will - be opened. - - sd_journal_open_directory() - is similar to sd_journal_open() - but takes an absolute directory path as argument. All - journal files in this directory will be opened and - interleaved automatically. This call also takes a - flags argument, but it must be passed as 0 as no flags - are currently understood for this call. - - sd_journal_close() will - close the journal context allocated with - sd_journal_open() or - sd_journal_open_directory() and - free its resources. - - When opening the journal only journal files - accessible to the calling user will be opened. If - journal files are not accessible to the caller this - will be silently ignored. - - See - sd_journal_next3 - for an example how to iterate through the journal - after opening it with - sd_journal_open(). - - A journal context object returned by - sd_journal_open() references a - specific journal entry as current entry, - similar to a file seek index in a classic file system - file, but without absolute positions. It may be - altered with - sd_journal_next3 - and - sd_journal_seek_head3 - and related calls. The current entry position may be - exported in cursor strings, as accessible - via - sd_journal_get_cursor3. Cursor - strings may be used to globally identify a specific - journal entry in a stable way and then later to seek - to it (or if the specific entry is not available - locally, to its closest entry in time) - sd_journal_seek_cursor3. - - Notification of journal changes is available via - sd_journal_get_fd() and related - calls. - - - - Return Value - - The sd_journal_open() and - sd_journal_open_directory() calls - return 0 on success or a negative errno-style error - code. sd_journal_close() returns - nothing. - - - - Notes - - The sd_journal_open(), - sd_journal_open_directory() and - sd_journal_close() interfaces are - available as shared library, which can be compiled and - linked to with the - libsystemd-journal - pkg-config1 - file. - - - - See Also - - - systemd1, - sd-journal3, - sd_journal_next3, - sd_journal_get_data3 - - - - diff --git a/man/sd_journal_print.xml b/man/sd_journal_print.xml deleted file mode 100644 index 7742268f5d..0000000000 --- a/man/sd_journal_print.xml +++ /dev/null @@ -1,251 +0,0 @@ - - - - - - - - - sd_journal_print - systemd - - - - Developer - Lennart - Poettering - lennart@poettering.net - - - - - - sd_journal_print - 3 - - - - sd_journal_print - sd_journal_printv - sd_journal_send - sd_journal_sendv - sd_journal_perror - SD_JOURNAL_SUPPRESS_LOCATION - Submit log entries to the journal - - - - - #include <systemd/sd-journal.h> - - - int sd_journal_print - int priority - const char* format - ... - - - - int sd_journal_printv - int priority - const char* format - va_list ap - - - - int sd_journal_send - const char* format - ... - - - - int sd_journal_sendv - const struct iovec *iov - int n - - - - int sd_journal_perror - const char* message - - - - - - - Description - - sd_journal_print() may be - used to submit simple, plain text log entries to the - system journal. The first argument is a priority - value. This is followed by a format string and its - parameters, similar to - printf3 - or - syslog3. The - priority value is one of - LOG_EMERG, - LOG_ALERT, - LOG_CRIT, - LOG_ERR, - LOG_WARNING, - LOG_NOTICE, - LOG_INFO, - LOG_DEBUG, as defined in - syslog.h, see - syslog3 - for details. It is recommended to use this call to - submit log messages in the application locale or system - locale and in UTF-8 format, but no such restrictions - are enforced. - - sd_journal_printv() is - similar to sd_journal_print() but - takes a variable argument list encapsulated in an - object of type va_list (see - stdarg3 - for more information) instead of the format string. It - is otherwise equivalent in behavior. - - sd_journal_send() may be - used to submit structured log entries to the system - journal. It takes a series of format strings, each - immediately followed by their associated parameters, - terminated by NULL. The strings passed should be of - the format VARIABLE=value. The - variable name must be in uppercase and consist only of - characters, numbers and underscores, and may not begin - with an underscore. (All assignments that do not - follow this syntax will be ignored.) The value can be - of any size and format. It is highly recommended to - submit text strings formatted in the UTF-8 character - encoding only, and submit binary fields only when - formatting in UTf-8 strings is not sensible. A number - of well known fields are defined, see - systemd.journal-fields7 - for details, but additional application defined fields - may be used. A variable may be assigned more than one - value per entry. - - sd_journal_sendv() is - similar to sd_journal_send() but - takes an array of struct iovec (as - defined in uio.h, see - readv3 - for details) instead of the format string. Each - structure should reference one field of the entry to - submit. The second argument specifies the number of - structures in the - array. sd_journal_sendv() is - particularly useful to submit binary objects to the - journal where that is necessary. - - sd_journal_perror() is a - similar to - perror3 - and writes a message to the journal that consists of - the passed string, suffixed with ": " and a human - readable representation of the current error code - stored in - errno3. If - the message string is passed as NULL or empty string - only the error string representation will be written, - prefixed with nothing. An additional journal field - ERRNO= is included in the entry containing the numeric - error code formatted as decimal string. The log - priority used is LOG_ERR (3). - - Note that sd_journal_send() - is a wrapper around - sd_journal_sendv() to make it - easier to use when only text strings shall be - submitted. Also, the following two calls are - mostly equivalent: - - sd_journal_print(LOG_INFO, "Hello World, this is PID %lu!", (unsigned long) getpid()); - -sd_journal_send("MESSAGE=Hello World, this is PID %lu!", (unsigned long) getpid(), - "PRIORITY=%i", LOG_INFO, - NULL); - - Note that these calls implicitly add fields for - the source file, function name and code line where - invoked. This is implemented with macros. If this is - not desired it can be turned off by defining - SD_JOURNAL_SUPPRESS_LOCATION before including - sd-journal.h. - - syslog3 - and sd_journal_print() may - largely be used interchangeably - functionality-wise. However, note that log messages - logged via the former take a different path to the - journal server than the later, and hence global - chronological ordering between the two streams cannot - be guaranteed. Using - sd_journal_print() has the - benefit of logging source code line, file names, and - functions as meta data along all entries, and - guaranteeing chronological ordering with structured - log entries that are generated via - sd_journal_send(). Using - syslog() has the benefit of being - more portable. - - - - Return Value - - The four calls return 0 on success or a negative - errno-style error code. The - errno3 - variable itself is not altered. - - - - Notes - - The sd_journal_print(), - sd_journal_printv(), - sd_journal_send() and - sd_journal_sendv() interfaces - are available as shared library, which can be compiled - and linked to with the - libsystemd-journal - pkg-config1 - file. - - - - See Also - - - systemd1, - sd-journal3, - sd_journal_stream_fd3, - syslog3, - perror3, - errno3, - systemd.journal-fields7 - - - - diff --git a/man/sd_journal_query_unique.xml b/man/sd_journal_query_unique.xml deleted file mode 100644 index f2f8af0eb5..0000000000 --- a/man/sd_journal_query_unique.xml +++ /dev/null @@ -1,214 +0,0 @@ - - - - - - - - - sd_journal_query_unique - systemd - - - - Developer - Lennart - Poettering - lennart@poettering.net - - - - - - sd_journal_query_unique - 3 - - - - sd_journal_query_unique - sd_journal_enumerate_unique - sd_journal_restart_unique - SD_JOURNAL_FOREACH_UNIQUE - Read unique data fields from the journal - - - - - #include <systemd/sd-journal.h> - - - int sd_journal_query_unique - sd_journal* j - const char* field - - - - int sd_journal_enumerate_unique - sd_journal* j - const void** data - size_t* length - - - - void sd_journal_restart_unique - sd_journal* j - - - - SD_JOURNAL_FOREACH_UNIQUE - sd_journal* j - const void* data - size_t length - - - - - - - Description - - sd_journal_query_unique() - queries the journal for all unique values the - specified field can take. It takes two arguments: the - journal to query and the field name to look - for. Well-known field names are listed on - systemd.journal-fields7. Field - names must be specified without a trailing '='. After - this function has been executed successfully the field - values may be queried using - sd_journal_enumerate_unique(). Invoking - this call a second time will change the field name - being queried and reset the enumeration index to the - first field value that matches. - - sd_journal_enumerate_unique() - may be used to iterate through all data fields which - match the previously selected field name as set with - sd_journal_query_unique(). On - each invocation the next field data matching the field - name is returned. The order of the returned data - fields is not defined. It takes three arguments: the - journal context object, plus a pair of pointers to - pointer/size variables where the data object and its - size shall be stored in. The returned data is in a - read-only memory map and is only valid until the next - invocation of - sd_journal_enumerate_unique(). Note - that the data returned will be prefixed with the field - name and '='. - - sd_journal_restart_unique() - resets the data enumeration index to the beginning of - the list. The next invocation of - sd_journal_enumerate_unique() - will return the first field data matching the field - name again. - - Note that the - SD_JOURNAL_FOREACH_UNIQUE() macro - may be used as a handy wrapper around - sd_journal_restart_unique() and - sd_journal_enumerate_unique(). - - Note that these functions currently are not - influenced by matches set with - sd_journal_add_match() but this - might change in a later version of this - software. - - - - Return Value - - sd_journal_query_unique() - returns 0 on success or a negative errno-style error - code. sd_journal_enumerate_unique() - returns a positive integer if the next field data has - been read, 0 when no more fields are known, or a - negative errno-style error - code. sd_journal_restart_unique() - returns nothing. - - - - Notes - - The sd_journal_query_unique(), - sd_journal_enumerate_unique() and - sd_journal_restart_unique() - interfaces are available as shared library, which can - be compiled and linked to with the - libsystemd-journal - pkg-config1 - file. - - - - Examples - - Use the - SD_JOURNAL_FOREACH_UNIQUE macro - to iterate through all values a field of the journal - can take. The following example lists all unit names - referenced in the journal: - - #include <stdio.h> -#include <string.h> -#include <systemd/sd-journal.h> - -int main(int argc, char *argv[]) { - sd_journal *j; - const void *d; - size_t l; - int r; - - r = sd_journal_open(&j, SD_JOURNAL_LOCAL_ONLY); - if (r < 0) { - fprintf(stderr, "Failed to open journal: %s\n", strerror(-r)); - return 1; - } - r = sd_journal_query_unique(j, "_SYSTEMD_UNIT"); - if (r < 0) { - fprintf(stderr, "Failed to query journal: %s\n", strerror(-r)); - return 1; - } - SD_JOURNAL_FOREACH_UNIQUE(j, d, l) - printf("%.*s\n", (int) l, (const char*) d); - sd_journal_close(j); - return 0; -} - - - - - See Also - - - systemd1, - systemd.journal-fields7, - sd-journal3, - sd_journal_open3, - sd_journal_get_data3, - sd_journal_add_match3 - - - - diff --git a/man/sd_journal_seek_head.xml b/man/sd_journal_seek_head.xml deleted file mode 100644 index 3716c5d367..0000000000 --- a/man/sd_journal_seek_head.xml +++ /dev/null @@ -1,178 +0,0 @@ - - - - - - - - - sd_journal_seek_head - systemd - - - - Developer - Lennart - Poettering - lennart@poettering.net - - - - - - sd_journal_seek_head - 3 - - - - sd_journal_seek_head - sd_journal_seek_tail - sd_journal_seek_monotonic_usec - sd_journal_seek_realtime_usec - sd_journal_seek_cursor - Seek to a position in the - journal - - - - - #include <systemd/sd-journal.h> - - - int sd_journal_seek_head - sd_journal* j - - - - int sd_journal_seek_tail - sd_journal* j - - - - int sd_journal_seek_monotonic_usec - sd_journal* j - sd_id128_t boot_id - uint64_t usec - - - - int sd_journal_seek_realtime_usec - sd_journal* j - uint64_t usec - - - - int sd_journal_seek_cursor - sd_journal* j - const char * cursor - - - - - - Description - - sd_journal_seek_head() - seeks to the beginning of the journal, i.e. the oldest - available entry. - - Similar, - sd_journal_seek_tail() may be - used to seek to the end of the journal, i.e. the most - recent available entry. - - sd_journal_seek_monotonic_usec() - seeks to the entry with the specified monotonic - timestamp, i.e. CLOCK_MONOOTONIC. Since monotonic time - restarts on every reboot a boot ID needs to be - specified as well. - - sd_journal_seek_realtime_usec() - seeks to the entry with the specified realtime - (wallclock) timestamp, i.e. CLOCK_REALTIME. Note that - the realtime clock is not necessarily monotonic. If a - realtime timestamp is ambiguous it is not defined - which position is sought to. - - sd_journal_seek_cursor() - seeks to the entry located at the specified cursor - string. For details on cursors see - sd_journal_get_cursor3. If - no entry matching the specified cursor is found the - call will seek to the next closest entry (in terms of - time) instead. To verify whether the newly selected - entry actually matches the cursor use - sd_journal_test_cursor3. - - Note that these calls do not actually make any - entry the new current entry, this needs to be done in - a separate step with a subsequent - sd_journal_next3 - invocation (or a similar call). Only then entry data - may be retrieved via - sd_journal_get_data3. If - no entry exists that matches exactly the specified - seek address the next closest is sought to. If - sd_journal_next3 - is used the closest following entry will be sought to, - if - sd_journal_previous3 - is used the closest preceding entry is sought - to. - - - - Return Value - - The functions return 0 on success or a negative - errno-style error code. - - - - Notes - - The sd_journal_seek_head(), - sd_journal_seek_tail(), - sd_journal_seek_monotonic_usec(), - sd_journal_seek_realtime_usec(), - and sd_journal_seek_cursor() - interfaces are available as shared library, which can - be compiled and linked to with the - libsystemd-journal - pkg-config1 - file. - - - - See Also - - - systemd1, - sd-journal3, - sd_journal_open3, - sd_journal_next3, - sd_journal_get_data3, - sd_journal_get_cursor3, - sd_journal_get_realtime_usec3 - - - - diff --git a/man/sd_journal_stream_fd.xml b/man/sd_journal_stream_fd.xml deleted file mode 100644 index 4407296b40..0000000000 --- a/man/sd_journal_stream_fd.xml +++ /dev/null @@ -1,171 +0,0 @@ - - - - - - - - - sd_journal_stream_fd - systemd - - - - Developer - Lennart - Poettering - lennart@poettering.net - - - - - - sd_journal_stream_fd - 3 - - - - sd_journal_stream_fd - Create log stream file descriptor to the journal - - - - - #include <systemd/sd-journal.h> - - - int sd_journal_stream_fd - const char* identifier - int priority - int level_prefix - - - - - - - Description - - sd_journal_stream_fd() may - be used to create a log stream file descriptor. Log - messages written to this file descriptor as simple - newline separated text strings are written to the - journal. This file descriptor can be used internally - by applications or be made STDOUT/STDERR of other - processes executed. - - sd_journal_stream_fd() - takes a short program identifier string as first - argument, which will be written to the journal as - _SYSLOG_IDENTIFIER= field for each log entry (see - systemd.journal-fields7 - for more information). The second argument shall be - the default priority level for all messages. The - priority level is one of LOG_EMERG, - LOG_ALERT, - LOG_CRIT, - LOG_ERR, - LOG_WARNING, - LOG_NOTICE, - LOG_INFO, - LOG_DEBUG, as defined in - syslog.h, see - syslog3 - for details. The third argument is a boolean: if true - kernel-style log priority level prefixes (such as - SD_WARNING) are interpreted, see - sd-daemon3 - for more information. - - It is recommended that applications log UTF-8 - messages only with this API, but this is not - enforced. - - - - - Return Value - - The call returns a valid write-only file descriptor on success or a - negative errno-style error code. - - - - Notes - - The sd_journal_stream_fd() - interface is available as shared library, which can - be compiled and linked to with the - libsystemd-journal - pkg-config1 - file. - - - - Examples - - Creating a log stream suitable for - fprintf3: - - #include <syslog.h> -#include <stdio.h> -#include <string.h> -#include <unistd.h> -#include <systemd/sd-journal.h> -#include <systemd/sd-daemon.h> - -int main(int argc, char *argv[]) { - int fd; - FILE *log; - fd = sd_journal_stream_fd("test", LOG_INFO, 1); - if (fd < 0) { - fprintf(stderr, "Failed to create stream fd: %s\n", strerror(-fd)); - return 1; - } - log = fdopen(fd, "w"); - if (!log) { - fprintf(stderr, "Failed to create file object: %m\n"); - close(fd); - return 1; - } - fprintf(log, "Hello World!\n"); - fprintf(log, SD_WARNING "This is a warning!\n"); - fclose(log); - return 0; -} - - - - - See Also - - - systemd1, - sd-journal3, - sd-daemon3, - sd_journal_print3, - syslog3, - fprintf3, - systemd.journal-fields7 - - - - diff --git a/man/sd_listen_fds.xml b/man/sd_listen_fds.xml deleted file mode 100644 index b891b6b039..0000000000 --- a/man/sd_listen_fds.xml +++ /dev/null @@ -1,204 +0,0 @@ - - - - - - - - - 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/$LISTEN_PID - environment variables before returning (regardless - 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 definition - file. 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. - - - - 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 - - This function is provided by the reference - implementation of APIs for new-style daemons and - distributed with the systemd package. The algorithm it - implements is simple, and can easily be reimplemented - in daemons if it is important to support this - interface without using the reference - implementation. - - 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. - - For details about the algorithm check the - liberally licensed reference implementation sources: - - and - - sd_listen_fds() is - implemented in the reference implementation's - sd-daemon.c and - sd-daemon.h files. These - interfaces are available as shared library, which can - be compiled and linked to with the - libsystemd-daemon - pkg-config1 - file. Alternatively, applications consuming these APIs - may copy the implementation into their source - tree. For more details about the reference - implementation see - sd-daemon3. - - If the reference implementation is used as - drop-in files and -DDISABLE_SYSTEMD is set during - compilation this function will always return 0 and - otherwise become a NOP. - - - - 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 deleted file mode 100644 index 35cb6b368b..0000000000 --- a/man/sd_login_monitor_new.xml +++ /dev/null @@ -1,173 +0,0 @@ - - - - - - - - - sd_login_monitor_new - systemd - - - - Developer - Lennart - Poettering - lennart@poettering.net - - - - - - sd_login_monitor_new - 3 - - - - sd_login_monitor_new - sd_login_monitor_unref - sd_login_monitor_flush - sd_login_monitor_get_fd - sd_login_monitor - Monitor login sessions, seats and users - - - - - #include <systemd/sd-login.h> - - - int sd_login_monitor_new - const char* category - sd_login_monitor** ret - - - - sd_login_monitor* sd_login_monitor_unref - sd_login_monitor* m - - - - int sd_login_monitor_flush - sd_login_monitor* m - - - - int sd_login_monitor_get_fd - sd_login_monitor* m - - - - - - - Description - - sd_login_monitor_new() may - be used to monitor login sessions, users and seats. Via - a monitor object a file descriptor can be integrated - into an application defined event loop which is woken - up each time a user logs in, logs out or a seat is - added or removed, or a session, user, or seat changes - state otherwise. The first parameter takes a string - which can be seat (to get - only notifications about seats being added, removed or - changed), session (to get only - notifications about sessions being created or removed - or changed) or uid (to get only - notifications when a user changes state in respect to - logins). If notifications shall be generated in all - these conditions, NULL may be passed. Note that in the - future additional categories may be defined. The - second parameter returns a monitor object and needs to - be freed with the - sd_login_monitor_unref() call - after use. - - sd_login_monitor_unref() - may be used to destroy a monitor object. Note that - this will invalidate any file descriptor returned by - sd_login_monitor_get_fd(). - - sd_login_monitor_flush() - may be used to reset the wakeup state of the monitor - object. Whenever an event causes the monitor to wake - up the event loop via the file descriptor this - function needs to be called to reset the wake-up - state. If this call is not invoked the file descriptor - will immediately wake up the event loop again. - - sd_login_monitor_get_fd() - may be used to retrieve the file descriptor of the - monitor object that may be integrated in an - application defined event loop, based around - poll2 - or a similar interface. The application should include - the returned file descriptor as wake up source for - POLLIN events. Whenever a wake-up is triggered the - file descriptor needs to be reset via - sd_login_monitor_flush(). An - application needs to reread the login state with a - function like - sd_get_seats3 - or similar to determine what changed. - - - - Return Value - - On success - sd_login_monitor_new() and - sd_login_monitor_flush() return 0 - or a positive integer. On success - sd_login_monitor_get_fd() returns - a Unix file descriptor. On failure, these calls return - a negative errno-style error code. - - sd_login_monitor_unref() - always returns NULL. - - - - Notes - - The sd_login_monitor_new(), - sd_login_monitor_unref(), sd_login_monitor_flush() and - sd_login_monitor_get_fd() interfaces - are available as shared library, which can be compiled - and linked to with the - libsystemd-login - pkg-config1 - file. - - - - See Also - - - systemd1, - sd-login3, - sd_get_seats3 - - - - diff --git a/man/sd_notify.xml b/man/sd_notify.xml deleted file mode 100644 index 75edeeadf3..0000000000 --- a/man/sd_notify.xml +++ /dev/null @@ -1,319 +0,0 @@ - - - - - - - - - sd_notify - systemd - - - - Developer - Lennart - Poettering - lennart@poettering.net - - - - - - sd_notify - 3 - - - - sd_notify - sd_notifyf - Notify service manager about start-up completion and other daemon 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 - ... - - - - - - Description - sd_notify() shall be called - by a daemon to notify the init system about status - 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 - 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 init system - that daemon startup is finished. This - is only used by systemd if the service - definition file has Type=notify - set. The passed argument is a boolean - "1" or "0". Since there is little - value in signaling non-readiness, the - only value daemons should send is - "READY=1". - - - - STATUS=... - - Passes a single-line - status string back to the init system - that describes the daemon 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 daemon fails, the - errno-style error code, formatted as - string. Example: "ERRNO=2" for - ENOENT. - - - - BUSERROR=... - - If a daemon fails, the - D-Bus error-style error code. Example: - "BUSERROR=org.freedesktop.DBus.Error.TimedOut" - - - - MAINPID=... - - The main pid of the - daemon, in case the init system did - not fork off the process - itself. Example: - "MAINPID=4711" - - - - WATCHDOG=1 - - Tells systemd 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 details. It is recommended to send - this message if the - WATCHDOG_USEC= - environment variable has been set for - the service process, in every half the - time interval that is specified in the - variable. - - - - It is recommended to prefix variable names that - are not shown in the list above with - X_ to avoid namespace - clashes. - - Note that systemd will accept status data sent - from a daemon 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. - - - - 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 - don't, it is generally recommended to ignore the return - value of this call. - - - - Notes - - These functions are provided by the reference - implementation of APIs for new-style daemons and - distributed with the systemd package. The algorithms - they implement are simple, and can easily be - reimplemented in daemons if it is important to support - this interface without using the reference - implementation. - - 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 daemon, using SCM_CREDENTIALS. - - For details about the algorithms check the - liberally licensed reference implementation sources: - - and - - sd_notify() and - sd_notifyf() are implemented in - the reference implementation's - sd-daemon.c and - sd-daemon.h files. These - interfaces are available as shared library, which can - be compiled and linked to with the - libsystemd-daemon - pkg-config1 - file. Alternatively, applications consuming these APIs - may copy the implementation into their source tree. For - more details about the reference implementation see - sd-daemon3. - - If the reference implementation is used as - drop-in files and -DDISABLE_SYSTEMD is set during - compilation these functions will always return 0 and - otherwise become a NOP. - - - - Environment - - - - $NOTIFY_SOCKET - - Set by the init system - 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 daemon finished starting up, it - might issue the following call to notify - the init system: - - sd_notify(0, "READY=1"); - - - - Extended Start-up Notification - - A daemon 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 daemon could send the following shortly before exiting, on failure - - sd_notifyf(0, "STATUS=Failed to start up: %s\n" - "ERRNO=%i", - strerror(errno), - errno); - - - - - See Also - - systemd1, - sd-daemon3, - daemon7, - systemd.service5 - - - - diff --git a/man/sd_pid_get_session.xml b/man/sd_pid_get_session.xml deleted file mode 100644 index 9517795f78..0000000000 --- a/man/sd_pid_get_session.xml +++ /dev/null @@ -1,160 +0,0 @@ - - - - - - - - - sd_pid_get_session - systemd - - - - Developer - Lennart - Poettering - lennart@poettering.net - - - - - - sd_pid_get_session - 3 - - - - sd_pid_get_session - sd_pid_get_unit - sd_pid_get_owner_uid - Determine session, service or owner of a session of a specific PID - - - - - #include <systemd/sd-login.h> - - - int sd_pid_get_session - pid_t pid - char** session - - - - int sd_pid_get_unit - pid_t pid - char** unit - - - - int sd_pid_get_owner_uid - pid_t pid - uid_t* uid - - - - - - Description - - sd_pid_get_session() may be - used to determine the login session identifier of a - process identified by the specified process - identifier. The session identifier is a short string, - suitable for usage in file system paths. Note that not - all processes are part of a login session (e.g. system - service processes, user processes that are shared - between multiple sessions of the same user, or kernel - threads). For processes not being part of a login - session this function will fail. The returned string - needs to be freed with the libc - free3 - call after use. - - sd_pid_get_unit() may be - used to determine the systemd unit (i.e. system - service) identifier of a process identified by the - specified process identifier. The unit name is a short - string, suitable for usage in file system paths. Note - that not all processes are part of a unit/service - (e.g. user processes, or kernel threads). For - processes not being part of a systemd unit/system - service this function will fail. The returned string - needs to be freed with the libc - free3 - call after use. - - sd_pid_get_owner_uid() may - be used to determine the Unix user identifier of the - owner of the session of a process identified the - specified PID. Note that this function will succeed - for user processes which are shared between multiple - login sessions of the same user, where - sd_pid_get_session() will - fail. For processes not being part of a login session - and not being a shared process of a user this function - will fail. - - If the pid parameter of any - of these functions is passed as 0 the operation is - executed for the calling process. - - - - Return Value - - On success these calls return 0 or a positive - integer. On failure, these calls return a negative - errno-style error code. - - - - Notes - - The sd_pid_get_session(), - sd_pid_get_pid(), and - sd_pid_get_owner_uid() interfaces - are available as shared library, which can be compiled - and linked to with the - libsystemd-login - pkg-config1 - file. - - Note that the login session identifier as - returned by sd_pid_get_session() - is completely unrelated to the process session - identifier as returned by - getsid2. - - - - See Also - - - systemd1, - sd-login3, - sd_session_is_active3, - getsid2 - - - - diff --git a/man/sd_readahead.xml b/man/sd_readahead.xml deleted file mode 100644 index a1fc6f178f..0000000000 --- a/man/sd_readahead.xml +++ /dev/null @@ -1,178 +0,0 @@ - - - - - - - - - sd_readahead - systemd - - - - Developer - Lennart - Poettering - lennart@poettering.net - - - - - - sd_readahead - 3 - - - - sd_readahead - Control ongoing disk boot-time read-ahead operations - - - - - #include "sd-readahead.h" - - - int sd_readahead - const char *action - - - - - - Description - sd_readahead() may be - called by programs involved with early boot-up to - control ongoing boot-time disk read-ahead operations. It may be - used to terminate read-ahead operations in case an - uncommon disk access pattern is to be expected and - hence read-ahead replay or collection is unlikely to - have the desired speed-up effect on the current or - future boot-ups. - - The action should be one - of the following strings: - - - - cancel - - Terminates read-ahead - data collection, and drops all - read-ahead data collected during this - boot-up. - - - - done - - Terminates read-ahead - data collection, but keeps all - read-ahead data collected during this - boot-up around for use during - subsequent boot-ups. - - - - noreplay - - Terminates read-ahead - replay. - - - - - - - - Return Value - - On failure, these calls return a negative - errno-style error code. It is generally recommended to - ignore the return value of this call. - - - - Notes - - This function is provided by the reference - implementation of APIs for controlling boot-time - read-ahead and distributed with the systemd - package. The algorithm it implements is simple, and - can easily be reimplemented in daemons if it is - important to support this interface without using the - reference implementation. - - Internally, this function creates a file in - /run/systemd/readahead/ which is - then used as flag file to notify the read-ahead - subsystem. - - For details about the algorithm check the - liberally licensed reference implementation sources: - - and - - sd_readahead() is - implemented in the reference implementation's drop-in - sd-readahead.c and - sd-readahead.h files. It is - recommended that applications consuming this API copy - the implementation into their source tree. For more - details about the reference implementation see - sd-readahead3 - - If -DDISABLE_SYSTEMD is set during compilation - this function will always return 0 and otherwise - become a NOP. - - - - Examples - - - Cancelling all read-ahead operations - - During boots where SELinux has to - relabel the file system hierarchy, it will - create a large amount of disk accesses that - are not necessary during normal boots. Hence - it is a good idea to disable both read-ahead replay and read-ahead collection. - - - sd_readahead("cancel"); -sd_readahead("noreplay"); - - - - - - See Also - - systemd1, - sd-readahead3, - daemon7 - - - - diff --git a/man/sd_seat_get_active.xml b/man/sd_seat_get_active.xml deleted file mode 100644 index b1d6d20edf..0000000000 --- a/man/sd_seat_get_active.xml +++ /dev/null @@ -1,180 +0,0 @@ - - - - - - - - - sd_seat_get_active - systemd - - - - Developer - Lennart - Poettering - lennart@poettering.net - - - - - - sd_seat_get_active - 3 - - - - sd_seat_get_active - sd_seat_get_sessions - sd_seat_can_multi_session - Determine state of a specific seat - - - - - #include <systemd/sd-login.h> - - - int sd_seat_get_active - const char* seat - char** session - uid_t* uid - - - - int sd_seat_get_sessions - const char* seat - char*** sessions - uid_t** uid - unsigned* n_uids - - - - int sd_seat_can_multi_session - const char* seat - - - - int sd_seat_can_tty - const char* seat - - - - int sd_seat_can_graphical - const char* seat - - - - - - Description - - sd_seat_get_active() may be - used to determine which session is currently active on - a seat, if there is any. Returns the session - identifier and the user identifier of the Unix user - the session is belonging to. Either the session or the - user identifier parameter can be passed NULL, in - case only one of the parameters shall be queried. The - returned string needs to be freed with the libc - free3 - call after use. - - sd_seat_get_sessions() may - be used to determine all sessions on the specified - seat. Returns two arrays, one (NULL terminated) with - the session identifiers of the sessions and one with - the user identifiers of the Unix users the sessions - belong to. An additional parameter may be used to - return the number of entries in the latter array. The - two arrays and the latter parameter may be passed as - NULL in case these values need not to be - determined. The arrays and the strings referenced by - them need to be freed with the libc - free3 - call after use. Note that instead of an empty array - NULL may be returned and should be considered - equivalent to an empty array. - - sd_seat_can_multi_session() - may be used to determine whether a specific seat is - capable of multi-session, i.e. allows multiple login - sessions in parallel (with only one being active at a - time). - - sd_seat_can_tty() may be - used to determine whether a specific seat provides TTY - functionality, i.e. is useful as a text console. - - sd_seat_can_graphical() may - be used to determine whether a specific seat provides - graphics functionality, i.e. is useful as a graphics - display. - - If the seat parameter of any - of these functions is passed as NULL the operation is - executed for the seat of the session of the calling - process, if there is any. - - - - Return Value - - On success - sd_seat_get_active() - returns 0 or a positive integer. On success - sd_seat_get_sessions() returns - the number of entries in the session identifier - array. If the test succeeds - sd_seat_can_multi_session, - sd_seat_can_tty and - sd_seat_can_graphical return a - positive integer, if it fails 0. On failure, these - calls return a negative errno-style error code. - - - - Notes - - The sd_seat_get_active(), - sd_seat_get_sessions(), - sd_seat_can_multi_session(), - sd_seat_can_tty() and - sd_seat_can_grapical() interfaces - are available as shared library, which can be compiled - and linked to with the - libsystemd-login - pkg-config1 - file. - - - - See Also - - - systemd1, - sd-login3, - sd_session_get_seat3 - - - - diff --git a/man/sd_session_is_active.xml b/man/sd_session_is_active.xml deleted file mode 100644 index a9107cb95f..0000000000 --- a/man/sd_session_is_active.xml +++ /dev/null @@ -1,240 +0,0 @@ - - - - - - - - - sd_session_is_active - systemd - - - - Developer - Lennart - Poettering - lennart@poettering.net - - - - - - sd_session_is_active - 3 - - - - sd_session_is_active - sd_session_get_state - sd_session_get_uid - sd_session_get_seat - sd_session_get_service - sd_session_get_type - sd_session_get_class - sd_session_get_display - Determine state of a specific session - - - - - #include <systemd/sd-login.h> - - - int sd_session_is_active - const char* session - - - - int sd_session_get_state - const char* session - char** state - - - - int sd_session_get_uid - const char* session - uid_t* uid - - - - int sd_session_get_seat - const char* session - char** seat - - - - int sd_session_get_service - const char* session - char** service - - - - int sd_session_get_type - const char* session - char** type - - - - int sd_session_get_class - const char* session - char** class - - - - int sd_session_get_display - const char* session - char** display - - - - - - Description - - sd_session_is_active() may - be used to determine whether the session identified by - the specified session identifier is currently active - (i.e. currently in the foreground and available for - user input) or not. - - sd_session_get_state() may - be used to determine the state of the session - identified by the specified session identifier. The - following states are currently known: - online (session logged in, but - session not active, i.e. not in the foreground), - active (session logged in and - active, i.e. in the foreground), - closing (session nominally logged - out, but some processes belonging to it are still - around). In the future additional states might be - defined, client code should be written to be robust in - regards to additional state strings being - returned. This function is a more generic version of - sd_session_is_active(). The returned - string needs to be freed with the libc - free3 - call after use. - - sd_session_get_uid() may be - used to determine the user identifier of the Unix user the session - identified by the specified session identifier belongs - to. - - sd_session_get_seat() may - be used to determine the seat identifier of the seat - the session identified by the specified session - identifier belongs to. Note that not all sessions are - attached to a seat, this call will fail for them. The - returned string needs to be freed with the libc - free3 - call after use. - - sd_session_get_service() - may be used to determine the name of the service (as - passed during PAM session setup) that registered the - session identified by the specified session - identifier. The returned string needs to be freed with - the libc - free3 - call after use. - - sd_session_get_type() may - be used to determine the type of the session - identified by the specified session identifier. The - returned string is one of x11, - tty or - unspecified and needs to be freed - with the libc - free3 - call after use. - - sd_session_get_class() may - be used to determine the class of the session - identified by the specified session identifier. The - returned string is one of user, - greeter or - lock-screen and needs to be freed - with the libc - free3 - call after use. - - sd_session_get_display() - may be used to determine the X11 display of the - session identified by the specified session - identifier. The returned string is one of needs to be - freed with the libc - free3 - call after use. - - If the session parameter of - any of these functions is passed as NULL the operation - is executed for the session the calling process is a - member of, if there is any. - - - - Return Value - - If the test succeeds - sd_session_is_active() returns a - positive integer, if it fails 0. On success - sd_session_get_state(), - sd_session_get_uid(), - sd_session_get_seat(), - sd_session_get_service(), - sd_session_get_type(), - sd_session_get_class() and - sd_session_get_display() return 0 or - a positive integer. On failure, these calls return a - negative errno-style error code. - - - - Notes - - The sd_session_is_active(), - sd_session_get_state(), - sd_session_get_uid(), - sd_session_get_seat(), - sd_session_get_service(), - sd_session_get_type(), - sd_session_get_class() and - sd_session_get_display() interfaces - are available as shared library, which can be compiled - and linked to with the - libsystemd-login - pkg-config1 - file. - - - - See Also - - - systemd1, - sd-login3, - sd_pid_get_session3 - - - - diff --git a/man/sd_uid_get_state.xml b/man/sd_uid_get_state.xml deleted file mode 100644 index b7bc944b14..0000000000 --- a/man/sd_uid_get_state.xml +++ /dev/null @@ -1,190 +0,0 @@ - - - - - - - - - sd_uid_get_state - systemd - - - - Developer - Lennart - Poettering - lennart@poettering.net - - - - - - sd_uid_get_state - 3 - - - - sd_uid_get_state - sd_uid_is_on_seat - sd_uid_get_sessions - sd_uid_get_seats - Determine login state of a specific Unix user ID - - - - - #include <systemd/sd-login.h> - - - int sd_uid_get_state - uid_t uid - char** state - - - - int sd_uid_is_on_seat - uid_t uid - int require_active - const char* seat - - - - int sd_uid_get_sessions - uid_t uid - int require_active - char*** sessions - - - - int sd_uid_get_seats - uid_t uid - int require_active - char*** seats - - - - - - Description - - sd_uid_get_state() may be - used to determine the login state of a specific Unix - user identifier. The following states are currently - known: offline (user not logged in - at all), lingering (user not logged - in, but some user services running), - online (user logged in, but not - active, i.e. has no session in the foreground), - active (user logged in, and has at - least one active session, i.e. one session in the - foreground), closing (user not - logged in, and not lingering, but some processes are - still around). In the future additional states might - be defined, client code should be written to be robust - in regards to additional state strings being - returned. The returned string needs to be freed with - the libc - free3 - call after use. - - sd_uid_is_on_seat() may be - used to determine whether a specific user is logged in - or active on a specific seat. Accepts a Unix user - identifier and a seat identifier string as - parameters. The require_active - parameter is a boolean value. If non-zero (true) this - function will test if the user is active (i.e. has a - session that is in the foreground and accepting user - input) on the specified seat, otherwise (false) only - if the user is logged in (and possibly inactive) on - the specified seat. - - sd_uid_get_sessions() may - be used to determine the current sessions of the - specified user. Accepts a Unix user identifier as - parameter. The require_active - parameter controls whether the returned list shall - consist of only those sessions where the user is - currently active (> 0), where the user is currently - online but possibly inactive (= 0), or - logged in at all but possibly closing the session (< 0). The call returns a - NULL terminated string array of session identifiers in - sessions which needs to be - freed by the caller with the libc - free3 - call after use, including all the strings - referenced. If the string array parameter is passed as - NULL the array will not be filled in, but the return - code still indicates the number of current - sessions. Note that instead of an empty array NULL may - be returned and should be considered equivalent to an - empty array. - - Similar, sd_uid_get_seats() - may be used to determine the list of seats on which - the user currently has sessions. Similar semantics - apply, however note that the user may have - multiple sessions on the same seat as well as sessions - with no attached seat and hence the number of entries - in the returned array may differ from the one returned - by sd_uid_get_sessions(). - - - - Return Value - - On success - sd_uid_get_state() returns 0 or a - positive integer. If the test succeeds - sd_uid_is_on_seat() returns a - positive integer, if it fails - 0. sd_uid_get_sessions() and - sd_uid_get_seats() return the - number of entries in the returned arrays. On failure, - these calls return a negative errno-style error - code. - - - - Notes - - The sd_uid_get_state(), - sd_uid_is_on_seat(), - sd_uid_get_sessions(), and - sd_uid_get_seats() interfaces are - available as shared library, which can be compiled and - linked to with the libsystemd-login - pkg-config1 - file. - - - - See Also - - - systemd1, - sd-login3, - sd_pid_get_owner_uid3 - - - - diff --git a/man/shutdown.xml b/man/shutdown.xml deleted file mode 100644 index d54fcb25ab..0000000000 --- a/man/shutdown.xml +++ /dev/null @@ -1,188 +0,0 @@ - - - - - - - - - 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 - /etc/nologin file is created to - ensure that further logins shall not be - allowed. - - - - Options - - The following options are understood: - - - - - - Prints a short help - text and exits. - - - - - - - Halt the machine. - - - - - - - Power-off the - machine (the default). - - - - - - - Reboot the - machine. - - - - - - Equivalent to - , unless - is - specified. - - - - - - Don't halt, power-off, - reboot, just write wall - message. - - - - - - Don't 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. - - - - Notes - - This is a legacy command available for - compatibility only. - - - - See Also - - systemd1, - systemctl1, - halt8, - wall1 - - - - diff --git a/man/sysctl.d.xml b/man/sysctl.d.xml deleted file mode 100644 index 69aac8cab7..0000000000 --- a/man/sysctl.d.xml +++ /dev/null @@ -1,127 +0,0 @@ - - - - - - - - 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 both / and . are accepted as label - separators within sysctl variable - names. kernel.domainname=foo and - kernel/domainname=foo hence are - entirely equivalent. - - Each configuration file shall be named in the - style of <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 configuration files in - /usr/lib/. Files in - /etc/ are reserved for the local - administrator, who may use this logic to override the - configuration files installed by vendor packages. All - configuration files are sorted by their filename in - alphabetical order, regardless in which of the - directories they reside, to guarantee that a specific - configuration file takes precedence over another file - with an alphabetically earlier name, if both files - contain the same variable setting. - - If the administrator wants to disable a - configuration file supplied by the vendor the - recommended way is to place a symlink to - /dev/null in - /etc/sysctl.d/ bearing the - same file name. - - - - Example - - /etc/sysctl.d/domain-name.conf example: - - # Set kernel YP domain name -kernel.domainname=example.com - - - - - See Also - - systemd1, - systemd-sysctl.service8, - systemd-delta1, - sysctl8, - sysctl.conf5 - - - - diff --git a/man/systemctl.xml b/man/systemctl.xml deleted file mode 100644 index 31f3b1a909..0000000000 --- a/man/systemctl.xml +++ /dev/null @@ -1,1268 +0,0 @@ - - - - - - - - - systemctl - systemd - - - - Developer - Lennart - Poettering - lennart@poettering.net - - - - - - systemctl - 1 - - - - systemctl - Control the systemd system and service manager - - - - - systemctl OPTIONS COMMAND NAME - - - - - Description - - systemctl may be used to - introspect and control the state of the - systemd1 - system and service manager. - - - - Options - - The following options are understood: - - - - - - - Prints a short help - text and exits. - - - - - - Prints a short version - string and exits. - - - - - - - The argument should - be a unit type name such as - and - , - or a unit load state such as - and - . - - - If the argument is a unit type, - when listing units, limit display to - certain unit types. If not specified - units of all types will be shown. - - If the argument is a unit load state, - when listing units, limit display to - certain unit types. If not specified - units of in all load states will be - shown. - - - - - - - - When showing - unit/job/manager 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 - MainPID. If - specified more than once all - properties with the specified names - are shown. - - - - - - - When listing units, - show all units, regardless of their - state, including inactive units. When - showing unit/job/manager properties, - show all properties regardless whether - they are set or not. - - - - - - When listing units, - show only failed units. Do not confuse - with - . - - - - - - Do not ellipsize unit - names and truncate unit descriptions - in the output of - list-units and - list-jobs. - - - - - - If the requested - operation conflicts with a pending - unfinished job, fail the command. If - this is not specified the requested - operation will replace the pending job, - if necessary. Do not confuse - with - . - - - - - - When enqueuing a new - job ignore all its dependencies and - execute it immediately. If passed no - required units of the unit passed will - be pulled in, and no ordering - dependencies will be honored. This is - mostly a debugging and rescue tool for - the administrator and should not be - used by - applications. - - - - - - - Suppress output to - STDOUT in - snapshot, - is-active, - enable and - disable. - - - - - - Do not synchronously wait for - the requested operation to finish. If this is - not specified the job will be verified, - enqueued and systemctl will - wait until it is completed. By passing this - argument it is only verified and - enqueued. - - - - - - Do not print a legend, i.e. - the column headers and the footer with hints. - - - - - - - Do not pipe output into a - pager. - - - - - - Talk to the systemd - system manager. (Default) - - - - - - Talk to the systemd - manager of the calling user. - - - - - - - When used in - conjunction with the - dot command (see - below), 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, shows - dependencies of all these - types. - - - - - - Don't send wall - message before - halt, power-off, reboot. - - - - - - When used with - enable and - disable, operate on the - global user configuration - directory, thus enabling or disabling - a unit file globally for all future - logins of all users. - - - - - - When used with - enable and - disable, do not - implicitly reload daemon configuration - after executing the - changes. - - - - - - When used with - start and related - commands, disables asking for - passwords. Background services may - require input of a password or - passphrase string, for example to - unlock system hard disks or - cryptographic certificates. Unless - this option is specified and the - command is invoked from a terminal - systemctl will - query the user on the terminal for the - necessary secrets. Use this option to - switch this behavior off. In this case - the password must be supplied by some - other means (for example graphical - password agents) or the service might - fail. This also disables querying 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 main process of the - unit, the control process or all - processes of the unit. 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 - . - - - - - - - When used with - enable, overwrite any - existing conflicting - symlinks. - - When used with - halt, - poweroff, - reboot or - kexec execute the - selected operation without shutting - down all units. However, all processes - will be killed forcibly and all file - systems are unmounted or remounted - read-only. This is hence a drastic but - relatively safe option to request an - immediate reboot. If - is specified - twice for these operations, they will - be executed immediately without - terminating any processes or umounting - any file systems. Warning: specifying - twice with - any of these operations might result - in data loss. - - - - - - When used with - enable/disable/is-enabled (and - related commands), use alternative - root path when looking for unit - files. - - - - - - When used with - enable/disable/is-enabled (and related commands), make - changes only temporarily, so that they - are dropped on the next reboot. This - will have the effect that changes are - not made in subdirectories of - /etc but in - /run, with - identical immediate effects, however, - since the latter is lost on reboot, - the changes are lost - too. - - - - - - - Execute operation - remotely. Specify a hostname, or - username and hostname separated by @, - to connect to. This will use SSH to - talk to the remote systemd - instance. - - - - - - - Acquire privileges via - PolicyKit before executing the - operation. - - - - - - - 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. - - - - - The following commands are understood: - - - - list-units - - List known units. - - - start [NAME...] - - Start (activate) one - or more units specified on the command - line. - - - stop [NAME...] - - Stop (deactivate) one - or more units specified on the command - line. - - - reload [NAME...] - - Asks all units listed - on the command line to reload their - configuration. Note that this will - reload the service-specific - configuration, not the unit - configuration file of systemd. If you - want systemd to reload the - configuration file of a unit use the - daemon-reload - command. In other words: for the - example case of Apache, this will - reload Apache's - httpd.conf in the - web server, not the - apache.service - systemd unit file. - - This command should not be - confused with the - daemon-reload or - load - commands. - - - - restart [NAME...] - - Restart one or more - units specified on the command - line. If the units are not running yet - they will be - started. - - - try-restart [NAME...] - - Restart one or more - units specified on the command - line if the units are running. Do - nothing if units are not running. - Note that for compatibility - with Red Hat init scripts - condrestart is - equivalent to this command. - - - reload-or-restart [NAME...] - - Reload one or more - units if they support it. If not, - restart them instead. If the units - are not running yet they will be - started. - - - reload-or-try-restart [NAME...] - - Reload one or more - units if they support it. If not, - restart them instead. Do nothing if - the units are not running. Note that - for compatibility with SysV init - scripts - force-reload is - equivalent to this - command. - - - isolate [NAME] - - Start the unit - specified on the command line and its - dependencies and stop all others. - - This is similar to changing the - runlevel in a traditional init system. The - isolate command will - immediately stop processes that are not - enabled in the new unit, possibly including - the graphical environment or terminal you - are currently using. - - Note that this works only on units - where is - enabled. See - systemd.unit5 - for details. - - - kill [NAME...] - - Send a signal to one - or more processes of the unit. Use - to select - which process to kill. Use - to - select the kill mode and - to select - the signal to send. - - - is-active [NAME...] - - Check whether any of - the specified units are active - (i.e. running). Returns an exit code - 0 if at least one is active, non-zero - otherwise. Unless - is specified - this will also print the current unit - state to STDOUT. - - - status [NAME...|PID...] - - Show terse runtime - status information about one or more - units, followed by its 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. If a - PID is passed information about the - unit the process of the PID belongs to - is shown. - - - show [NAME...|JOB...] - - Show properties of one - or more units, jobs or the manager - itself. If no argument is specified - properties of the manager will be - shown. If a unit name is specified - properties of the unit is shown, and - if a job id is specified properties of - the job is 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. - - - help [NAME...|PID...] - - Show manual pages for - one or more units, if available. If a - PID is passed the manual pages for the - unit the process of the PID belongs to - is shown. - - - reset-failed [NAME...] - - Reset the - 'failed' state of the - specified units, or if no unit name is - passed of all units. When a unit fails - in some way (i.e. process exiting with - non-zero error code, terminating - abnormally or timing out) it will - automatically enter the - 'failed' state and - its exit code and status is recorded - for introspection by the administrator - until the service is restarted or - reset with this - command. - - - - list-unit-files - - List installed unit files. - - - - - enable [NAME...] - - Enable one or - more unit files or unit file - instances, as specified on the - command line. This will create a - number of symlinks as encoded in - the [Install] - sections of the unit files. After - the symlinks have been created the - systemd configuration is reloaded - (in a way that is equivalent to - daemon-reload) - to ensure the changes are taken into - account immediately. Note that this - does not have the effect that any of - the units enabled are also started at - the same time. If this is desired - a separate start - command must be invoked for the unit. - Also note that in case of instance - enablement, symlinks named same as - instances are created in install - location, however they all point to - the same template unit file. - - This command will - print the actions executed. This - output may be suppressed by passing - . - - Note that this operation creates - only the suggested symlinks for the - units. While this command is the - recommended way to manipulate the unit - configuration directory, the - administrator is free to make - additional changes manually, by - placing or removing symlinks in the - directory. This is particularly useful - to create configurations that deviate - from the suggested default - installation. In this case the - administrator must make sure to invoke - daemon-reload - manually as necessary, to ensure his - changes are taken into account. - - Enabling units should not be - confused with starting (activating) - units, as done by the - start - command. Enabling and starting units - is orthogonal: units may be enabled - without being started and started - without being enabled. Enabling simply - hooks the unit into various suggested - places (for example, so that the unit - is automatically started on boot or - when a particular kind of hardware is - plugged in). Starting actually spawns - the daemon process (in case of service - units), or binds the socket (in case - of socket units), and so - on. - - Depending on whether - , - or - is specified - this enables the unit for the system, - for the calling user only - or for all future logins of all - users. Note that in the latter case no - systemd daemon configuration is - reloaded. - - - - - disable [NAME...] - - Disables one or more - units. This removes all symlinks to - the specified unit files from the unit - configuration directory, and hence - undoes the changes made by - enable. Note - however that this removes - all symlinks to the unit files - (i.e. including manual additions), not - just those actually created by - enable. This call - implicitly reloads the systemd daemon - configuration after completing the - disabling of the units. Note that this - command does not implicitly stop the - units that are being disabled. If this - is desired an additional - stop command should - be executed afterwards. - - This command will print the - actions executed. This output may be - suppressed by passing - . - - - This command honors - , - , - in a similar - way as - enable. - - - - is-enabled [NAME...] - - Checks whether any of - the specified unit files are enabled - (as with - enable). Returns an - exit code of 0 if at least one is - enabled, non-zero otherwise. Prints - the current enable status. To suppress - this output use - . - - - - reenable [NAME...] - - Reenable one or more - unit files, as specified on the - command line. This is a combination of - disable and - enable and is - useful to reset the symlinks a unit is - enabled with to the defaults - configured in the - [Install] section - of the unit file. - - - - - preset [NAME...] - - Reset one or more unit - files, as specified on the command - line, to the defaults configured in - the preset policy files. This has the - same effect as - disable or - enable, depending - how the unit is listed in the preset - files. For more information on preset - policy format see - systemd.preset5. For - more information on the concept of - presets please consult the Preset - document. - - - - - mask [NAME...] - - Mask one or more unit - files, as specified on the command - line. This will link these units to - /dev/null, making - it impossible to start them. This is a stronger version - of disable, since - it prohibits all kinds of activation - of the unit, including manual - activation. Use this option with - care. - - - - - unmask [NAME...] - - Unmask one or more - unit files, as specified on the - command line. This will undo the - effect of - mask. - - - - - link [NAME...] - - Link a unit file that - is not in the unit file search paths - into the unit file search path. This - requires an absolute path to a unit - file. The effect of this can be undone - with disable. The - effect of this command is that a unit - file is available for - start and other - commands although it isn't installed - directly in the unit search - path. - - - - - load [NAME...] - - Load one or more units - specified on the command line. This - will simply load their configuration - from disk, but not start them. To - start them you need to use the - start command which - will implicitly load a unit that has - not been loaded yet. Note that systemd - garbage collects loaded units that are - not active or referenced by an active - unit. This means that units loaded - this way will usually not stay loaded - for long. Also note that this command - cannot be used to reload unit - configuration. Use the - daemon-reload - command for that. All in all, this - command is of little use except for - debugging. - This command should not be - confused with the - daemon-reload or - reload - commands. - - - list-jobs - - List jobs that are in progress. - - - cancel [JOB...] - - Cancel one or more - jobs specified on the command line by - their numeric job - IDs. If no job id is specified, cancel all pending jobs. - - - dump - - Dump server - status. This will output a (usually - very long) human readable manager - status dump. Its format is subject to - change without notice and should not - be parsed by - applications. - - - dot - - Generate textual - dependency graph description in dot - format for further processing with the - GraphViz - dot1 - tool. Use a command line like - systemctl 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. - - - snapshot [NAME] - - Create a snapshot. If - a snapshot name is specified, the new - snapshot will be named after it. If - none is specified an automatic - snapshot name is generated. In either - case, the snapshot name used is - printed to STDOUT, unless - is - specified. - - A snapshot refers to a saved - state of the systemd manager. It is - implemented itself as a unit that is - generated dynamically with this - command and has dependencies on all - units active at the time. At a later - time the user may return to this state - by using the - isolate command on - the snapshot unit. - - Snapshots are only useful for - saving and restoring which units are - running or are stopped, they do not - save/restore any other - state. Snapshots are dynamic and lost - on reboot. - - - delete [NAME...] - - Remove a snapshot - previously created with - snapshot. - - - daemon-reload - - Reload systemd manager - configuration. This will reload all - unit files and recreate the entire - dependency tree. While the daemon is - reloaded, all sockets systemd listens - on on behalf of user configuration will - stay accessible. This - command should not be confused with - the load or - reload - commands. - - - daemon-reexec - - Reexecute the systemd - manager. This will serialize the - manager state, reexecute the process - and deserialize the state again. This - command is of little use except for - debugging and package - upgrades. Sometimes it might be - helpful as a heavy-weight - daemon-reload. While - the daemon is reexecuted all sockets - systemd listens on on behalf of user - configuration will stay - accessible. - - - show-environment - - Dump the systemd - manager environment block. The - environment block will be dumped in - straight-forward form suitable for - sourcing into a shell script. This - environment block will be passed to - all processes the manager - spawns. - - - set-environment [NAME=VALUE...] - - Set one or more - systemd manager environment variables, - as specified on the command - line. - - - unset-environment [NAME...] - - Unset one or more - systemd manager environment - variables. If only a variable name is - specified it will be removed - regardless of its value. If a variable - and a value are specified the variable - is only removed if it has the - specified value. - - - default - - Enter default - mode. This is mostly equivalent to - start - default.target. - - - rescue - - Enter rescue - mode. This is mostly equivalent to - isolate - rescue.target but also - prints a wall message to all - users. - - - emergency - - Enter emergency - mode. This is mostly equivalent to - isolate - emergency.target but also - prints a wall message to all - users. - - - halt - - Shut down and halt the - system. This is mostly equivalent to - start halt.target - but also prints a wall message to all - users. If combined with - shutdown of - all running services is skipped, - however all processes are killed and - all file systems are unmounted or - mounted read-only, immediately - followed by the system halt. If - is specified - twice the operation is immediately - executed without terminating any - processes or unmounting any file - systems. This may result in data - loss. - - - poweroff - - Shut down and - power-off the system. This is mostly - equivalent to start - poweroff.target but also - prints a wall message to all users. If - combined with - shutdown of all running services is - skipped, however all processes are - killed and all file systems are - unmounted or mounted read-only, - immediately followed by the powering - off. If is - specified twice the operation is - immediately executed without - terminating any processes or - unmounting any file systems. This may - result in data loss. - - - reboot - - Shut down and reboot - the system. This is mostly equivalent - to start - reboot.target but also - prints a wall message to all users. If - combined with - shutdown of all running services is - skipped, however all processes are - killed and all file systems are - unmounted or mounted read-only, - immediately followed by the reboot. If - is specified - twice the operation is immediately - executed without terminating any - processes or unmounting any file - systems. This may result in data - loss. - - - kexec - - Shut down and reboot - the system via kexec. This is mostly - equivalent to start - kexec.target but also prints - a wall message to all users. If - combined with - shutdown of all running services is - skipped, however all processes are killed - and all file systems are unmounted or - mounted read-only, immediately - followed by the - reboot. - - - exit - - Ask the systemd - manager to quit. This is only - supported for user service managers - (i.e. in conjunction with the - option) and - will fail otherwise. - - - suspend - - Suspend the - system. This will trigger activation - of the special - suspend.target - target. - - - hibernate - - Hibernate the - system. This will trigger activation - of the special - hibernate.target - target. - - - hybrid-sleep - - Hibernate and suspend - the system. This will trigger - activation of the special - hybrid-sleep.target - target. - - - switch-root [ROOT] [INIT] - - Switches to a - different root directory and executes - a new system manager process below - it. This is intended for usage in - initial RAM disks ("initrd"), and will - transition from the initrd's system - manager process (a.k.a "init" process) - to the main system manager - process. Takes two arguments: the - directory to make the new root - directory, and the path to the new - system manager binary below it to - execute as PID 1. If the latter is - omitted or the empty string, a - systemd binary will automatically be - searched for and used as init. If the - system manager path is omitted or - equal the empty string the state of - the initrd's system manager process is - passed to the main system manager, - which allows later introspection of the - state of the services involved in the - initrd boot. - - - - - - - Exit status - - On success 0 is returned, a non-zero failure - code otherwise. - - - - Environment - - - - $SYSTEMD_PAGER - Pager to use when - is not given; - overrides $PAGER. Setting - this to an empty string or the value - cat is equivalent to passing - . - - - - - - See Also - - systemd1, - systemadm1, - journalctl1, - loginctl1, - systemd.unit5, - systemd.special7, - wall1, - systemd.preset5 - - - - diff --git a/man/systemd-analyze.xml b/man/systemd-analyze.xml deleted file mode 100644 index c2ff9cc5bd..0000000000 --- a/man/systemd-analyze.xml +++ /dev/null @@ -1,138 +0,0 @@ - - - - - - - - - systemd-analyze - systemd - - - - Developer - Lennart - Poettering - lennart@poettering.net - - - - - - systemd-analyze - 1 - - - - systemd-analyze - Analyze system boot-up performance - - - - - systemd-analyze OPTIONS time - - - systemd-analyze OPTIONS blame - - - systemd-analyze OPTIONS plot > file.svg - - - - - Description - - systemd-analyze may be used - to determine system boot-up performance of the current - boot. - - 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 plot prints - an SVG graphic detailing which system services have - been started at what time, highlighting the time they - spent on initialization. - - If no command is passed systemd-analyze - time is implied. - - - - - Options - - The following options are understood: - - - - - - - Prints a short help - text and exits. - - - - - - Shows performance data - of user sessions instead of the system - manager. - - - - - - - Exit status - - On success 0 is returned, a non-zero failure - code otherwise. - - - - See Also - - systemd1, - systemctl1 - - - - diff --git a/man/systemd-ask-password-console.service.xml b/man/systemd-ask-password-console.service.xml deleted file mode 100644 index 6c87feb179..0000000000 --- a/man/systemd-ask-password-console.service.xml +++ /dev/null @@ -1,96 +0,0 @@ - - - - - - - - systemd-ask-password-console.service - systemd - - - - Developer - Lennart - Poettering - lennart@poettering.net - - - - - - 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 - - - - 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. - - 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. - - - - See Also - - systemd1, - systemd-tty-ask-password-agent1, - wall1 - - - - diff --git a/man/systemd-ask-password.xml b/man/systemd-ask-password.xml deleted file mode 100644 index 7b0b9ab809..0000000000 --- a/man/systemd-ask-password.xml +++ /dev/null @@ -1,183 +0,0 @@ - - - - - - - - - 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 STDOUT. 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: - - - - - - - Prints a short help - text and exits. - - - - - - 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. - - - - - - 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-binfmt.service.xml b/man/systemd-binfmt.service.xml deleted file mode 100644 index 1db735a826..0000000000 --- a/man/systemd-binfmt.service.xml +++ /dev/null @@ -1,76 +0,0 @@ - - - - - - - - systemd-binfmt.service - systemd - - - - Developer - Lennart - Poettering - lennart@poettering.net - - - - - - systemd-binfmt.service - 8 - - - - systemd-binfmt.service - systemd-binfmt - Configure additional binary formats for executables at boot - - - - systemd-binfmt.service - /usr/lib/systemd/systemd-binfmt - - - - Description - - 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 Also - - systemd1, - binfmt.d5, - wine8 - - - - diff --git a/man/systemd-cat.xml b/man/systemd-cat.xml deleted file mode 100644 index cac275b453..0000000000 --- a/man/systemd-cat.xml +++ /dev/null @@ -1,205 +0,0 @@ - - - - - - - - - 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 STDOUT and STDERR of a process with 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: - - - - - - - Prints a short help - text and exits. - - - - - - Prints a short version - string and exits. - - - - - - - Specify a short string - that is used to identify the logging - tool. If not specified no identifying - 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 STDOUT/STDERR 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 deleted file mode 100644 index 4b6ee93b4e..0000000000 --- a/man/systemd-cgls.xml +++ /dev/null @@ -1,141 +0,0 @@ - - - - - - - - - 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: - - - - - - - Prints a short help - text and exits. - - - - - - Prints a short version - string and exits. - - - - - - Do not pipe output into a - pager. - - - - - - Don't hide empty - control groups in the - output. - - - - - - Include kernel - threads in output. - - - - - - - - Exit status - - On success 0 is returned, a non-zero failure - code otherwise. - - - - See Also - - systemd1, - systemctl1, - systemd-cgtop1, - ps1 - - - - diff --git a/man/systemd-cgtop.xml b/man/systemd-cgtop.xml deleted file mode 100644 index 7a34512b21..0000000000 --- a/man/systemd-cgtop.xml +++ /dev/null @@ -1,276 +0,0 @@ - - - - - - - - - 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 and disk I/O load. The - display is refreshed in regular intervals (by default - every 1s), similar in style to - top1. - - 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. systemd1 - by default places all services in their own control - group in the cpuacct hierarchy, but - not in memory nor - blkio. If resource monitoring for - these resources is required it is recommended to add - blkio and memory - to the DefaultControllers= setting - in /etc/systemd/system.conf (see - systemd.conf5 - for details). Alternatively, it is possible to enable - resource accounting individually for services, by - making use of the ControlGroup= - option in the unit files (See - systemd.exec5 - for details). - - To emphasize this: unless - blkio and memory - are enabled for the services in question with either - of the options suggested above 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: - - - - - - - Prints a short help - text and exits. - - - - - - Prints a version string and - exits. - - - - - - 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. - - - - + - - - - 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, - top1 - - - - diff --git a/man/systemd-coredumpctl.xml b/man/systemd-coredumpctl.xml deleted file mode 100644 index 8b54b90999..0000000000 --- a/man/systemd-coredumpctl.xml +++ /dev/null @@ -1,214 +0,0 @@ - - - - - - - - - systemd-coredumpctl - systemd - - - - Developer - Zbigniew - Jędrzejewski-Szmek - zbyszek@in.waw.pl - - - - - - systemd-coredumpctl - 1 - - - - systemd-coredumpctl - Retrieve coredumps from the journal - - - - - systemd-coredumpctl OPTIONS COMMAND PID|COMM|EXE|MATCH - - - - - Description - - systemd-coredumpctl may be used to - retrieve coredumps from - systemd-journald8. - - - - Options - - The following options are understood: - - - - - - - Print a short help - text and exit. - - - - - - Print a short version - string and exit. - - - - - - - Print all possible - data values the specified field - takes in matching coredump entries of the - journal. - - - - - - - Write the core to - . - - - - - - Do not pipe output of - list into a - pager. - - - - - - Do not print the column headers. - - - - - - The following commands are understood: - - - - list - - List coredumps captured in the journal - matching specified characteristics. - - - - dump - - Extract the last coredump - matching specified characteristics. - Coredump will be written on stdout, unless - an output file is specified with - . - - - - - - gdb - - Invoke the GNU - debugger on the last coredump matching - specified characteristics. - - - - - - - - - Matching - - Match can be: - - - - - - Process ID of the - process that dumped - core. An integer. - - - - - - Name of the executable - (matches ). - Must not contain slashes. - - - - - - - Path to the executable - (matches ). - Must contain at least one slash. - - - - - - - General journalctl predicates - (see journalctl1). - Must contain an equals sign. - - - - - - - Exit status - On success 0 is returned, a non-zero failure - code otherwise. Not finding any matching coredumps is treated - as failure. - - - - - See Also - - systemd-journald.service8, - gdb1 - - - - diff --git a/man/systemd-cryptsetup-generator.xml b/man/systemd-cryptsetup-generator.xml deleted file mode 100644 index 49d4d5545b..0000000000 --- a/man/systemd-cryptsetup-generator.xml +++ /dev/null @@ -1,147 +0,0 @@ - - - - - - - - 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 super - block UUID as argument. This will - activate the specified device as part - of the boot process as if it was - listed in - /etc/fstab. 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. - - - - - - 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 deleted file mode 100644 index abbb9d78f2..0000000000 --- a/man/systemd-cryptsetup@.service.xml +++ /dev/null @@ -1,87 +0,0 @@ - - - - - - - - systemd-cryptsetup@.service - systemd - - - - Developer - Lennart - Poettering - lennart@poettering.net - - - - - - systemd-cryptsetup@.service - 8 - - - - systemd-cryptsetup@.service - systemd-cryptsetup - Full disk decryption logic - - - - systemd-cryptsetup@.service - /usr/lib/systemd/systemd-cryptsetup - - - - 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 - 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. - - - - See Also - - systemd1, - systemd-cryptsetup-generator8, - crypttab5, - cryptsetup8 - - - - diff --git a/man/systemd-delta.xml b/man/systemd-delta.xml deleted file mode 100644 index 072f55f1a1..0000000000 --- a/man/systemd-delta.xml +++ /dev/null @@ -1,181 +0,0 @@ - - - - - - - - - systemd-delta - systemd - - - - Developer - Lennart - Poettering - lennart@poettering.net - - - - - - systemd-delta - 1 - - - - systemd-delta - Find overridden configuration files - - - - - systemd-delta OPTIONS SUFFIX - - - - - Description - - systemd-delta may be used to - identify and compare configuration files in - /etc that override default - counterparts in /usr. The command - line argument can be one or more name of a subdirectories of - /etc or - /usr/lib to compare, such as - tmpfiles.d, sysctl.d or - systemd/system. - - When no argument is specified a number of - well-known subdirectories are searched for overridden - files. - - - - Options - - The following options are understood: - - - - - - - Prints a short help - text and exits. - - - - - - Prints a short version - string and exits. - - - - - - Do not pipe output into a - pager. - - - - - - - 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. - - - - 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 . - - - - - - - - Exit status - - On success 0 is returned, a non-zero failure - code otherwise. - - - - See Also - - systemd1 - - - - diff --git a/man/systemd-detect-virt.xml b/man/systemd-detect-virt.xml deleted file mode 100644 index 762b6ab992..0000000000 --- a/man/systemd-detect-virt.xml +++ /dev/null @@ -1,151 +0,0 @@ - - - - - - - - - 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. - - When executed without - will print a short identifier for the detected - virtualization technology. The following technologies - are currently identified: qemu, - kvm, vmware, - microsoft, - oracle, xen, - bochs, chroot, - openvz, lxc, - lxc-libvirt, - systemd-nspawn. - - 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: - - - - - - - Prints a short help - text and exits. - - - - - - Prints a short version - string and exits. - - - - - - - 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 - - - - diff --git a/man/systemd-fsck@.service.xml b/man/systemd-fsck@.service.xml deleted file mode 100644 index 62f63110e1..0000000000 --- a/man/systemd-fsck@.service.xml +++ /dev/null @@ -1,110 +0,0 @@ - - - - - - - - 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 is a - service responsible for file system checks. It is - instantiated for each device that requires a file - system - check. systemd-fsck-root.service is - responsible for file system checks on the root - file system. - - systemd-fsck will - forward file system checking progress to the - console. If a file system check fails 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. - - - - - - See Also - - systemd1, - fsck8, - systemd-quotacheck.service8 - - - - diff --git a/man/systemd-fstab-generator.xml b/man/systemd-fstab-generator.xml deleted file mode 100644 index 2decec6c40..0000000000 --- a/man/systemd-fstab-generator.xml +++ /dev/null @@ -1,118 +0,0 @@ - - - - - - - - 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. - - 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 - luks.fstab= is - honored by both the main system and - 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 deleted file mode 100644 index 1c9c9345f9..0000000000 --- a/man/systemd-getty-generator.xml +++ /dev/null @@ -1,90 +0,0 @@ - - - - - - - - systemd-getty-generator - systemd - - - - Developer - Lennart - Poettering - lennart@poettering.net - - - - - - systemd-getty-generator - 8 - - - - systemd-getty-generator - Generator for enabling getty instances on - the console - - - - /usr/lib/systemd/system-generators/systemd-getty-generator - - - - 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. This should - ensure that the user is shown a login prompt at the - right place, regardless in which environment the - system is started. 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. - - - - See Also - - systemd1, - agetty8 - - - - diff --git a/man/systemd-halt.service.xml b/man/systemd-halt.service.xml deleted file mode 100644 index 6a6bfdc7d7..0000000000 --- a/man/systemd-halt.service.xml +++ /dev/null @@ -1,119 +0,0 @@ - - - - - - - - - systemd-halt.service - systemd - - - - Developer - Lennart - Poettering - lennart@poettering.net - - - - - - systemd-halt.service - 8 - - - - systemd-halt.service - systemd-poweroff.service - systemd-reboot.service - systemd-kexec.service - systemd-shutdown - System shutdown logic - - - - systemd-halt.service - systemd-poweroff.service - systemd-reboot.service - systemd-kexec.service - /usr/lib/systemd/systemd-shutdown - - - - Description - - systemd-halt.service is a - system service that is pulled in by - halt.target and is responsible - for the actual system halt. Similar, - systemd-poweroff.service is - pulled in by poweroff.target, - systemd-reboot.service by - reboot.target and - systemd-kexec.service by - kexec.target to execute the - respective actions. - - When these services are run they ensure that PID - 1 is replaced by the - /usr/lib/systemd/systemd-shutdown - tool which is then responsible for the actual - shutdown. Before shutting down this binary will try to - unmount all remaining file systems, disable all - remaining swap devices, detach all remaining storage - devices and kill all remaining processes. - - Immediately before executing the actual system - halt/poweroff/reboot/kexec - systemd-shutdown will run all - executables in - /usr/lib/systemd/system-shutdown/ - and pass one arguments to them: either - "halt", - "poweroff", - "reboot" or - "kexec", depending on the chosen - action. All executables in this directory are executed - in parallel, and execution of the action is not - continued before all executables finished. - - Note that - systemd-halt.service (and the - related units) should never be executed - directly. Instead, trigger system shutdown with a - command such as "systemctl halt" or - suchlike. - - - - See Also - - systemd1, - systemctl1, - systemd.special7, - reboot2, - systemd-suspend.service8 - - - - diff --git a/man/systemd-hostnamed.service.xml b/man/systemd-hostnamed.service.xml deleted file mode 100644 index d9c1911018..0000000000 --- a/man/systemd-hostnamed.service.xml +++ /dev/null @@ -1,87 +0,0 @@ - - - - - - - - - systemd-hostnamed.service - systemd - - - - Developer - Lennart - Poettering - lennart@poettering.net - - - - - - systemd-hostnamed.service - 8 - - - - systemd-hostnamed.service - systemd-hostnamed - Hostname bus mechanism - - - - systemd-hostnamed.service - /usr/lib/systemd/systemd-hostnamed - - - - Description - - systemd-hostnamed is a system - service that may be used as mechanism to change the - system hostname. systemd-hostnamed is - automatically activated on request and terminates - itself when it is unused. - - The tool - hostnamectl1 - is a command line client to this service. - - See the - developer documentation for information about - the APIs systemd-hostnamed - provides. - - - - See Also - - systemd1, - hostname5, - machine-info5, - hostnamectl1, - sethostname2 - - - - diff --git a/man/systemd-inhibit.xml b/man/systemd-inhibit.xml deleted file mode 100644 index 6f63c8c73e..0000000000 --- a/man/systemd-inhibit.xml +++ /dev/null @@ -1,205 +0,0 @@ - - - - - - - - - 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: - - - - - - - Prints a short help - text and exits. - - - - - - Prints a short version - string and exits. - - - - - - 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 - systemd-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, - systemd-logind.conf5 - - - - diff --git a/man/systemd-initctl.service.xml b/man/systemd-initctl.service.xml deleted file mode 100644 index eda6459b50..0000000000 --- a/man/systemd-initctl.service.xml +++ /dev/null @@ -1,76 +0,0 @@ - - - - - - - - - systemd-initctl.service - systemd - - - - Developer - Lennart - Poettering - lennart@poettering.net - - - - - - systemd-initctl.service - 8 - - - - systemd-initctl.service - systemd-initctl.socket - systemd-initctl - /dev/initctl compatibility - - - - systemd-initctl.service - systemd-initctl.socket - /usr/lib/systemd/systemd-initctl - - - - Description - - systemd-initctl is a system - service that implements compatibility with the - /dev/initctl FIFO file system - object, as implemented by the SysV init system. systemd-initctl is - automatically activated on request and terminates - itself when it is unused. - - - - See Also - - systemd1 - - - - diff --git a/man/systemd-journald.service.xml b/man/systemd-journald.service.xml deleted file mode 100644 index abc03df5db..0000000000 --- a/man/systemd-journald.service.xml +++ /dev/null @@ -1,173 +0,0 @@ - - - - - - - - - systemd-journald.service - systemd - - - - Developer - Lennart - Poettering - lennart@poettering.net - - - - - - systemd-journald.service - 8 - - - - systemd-journald.service - systemd-journald.socket - systemd-journald - Journal service - - - - systemd-journald.service - systemd-journald.socket - /usr/lib/systemd/systemd-journald - - - - Description - - systemd-journald is a - system service that collects and stores logging - data. It creates and maintains structured, indexed - journals based on logging information that is received - from the kernel, from user processes via the libc - syslog3 - call, from STDOUT/STDERR of system services or via its - native API. It will implicitly collect numerous meta - data fields for each log messages in a secure and - unfakeable way. See - systemd.journal-fields7 - for more information about the collected meta data. - - - Log data collected by the journal is primarily - text based but can also include binary data where - necessary. All objects stored in the journal can be up - to 2^64-1 bytes in size. - - By default the journal stores log data in - /run/log/journal/. Since - /run/ is volatile log data is - lost at reboot. To make the data persistent it - is sufficient to create - /var/log/journal/ where - systemd-journald will then store - the data. - - systemd-journald will - forward all received log messages to the AF_UNIX - SOCK_DGRAM socket - /run/systemd/journal/syslog (if it exists) which - may be used by UNIX syslog daemons to process the data - further. - - See - journald.conf5 - for information about the configuration of this - service. - - - - Signals - - - - SIGUSR1 - - Request that journal - data from /run/ - is flushed to - /var/ in order to - make it persistent (if this is - enabled). This may be used after - /var/ is mounted, - but is generally not required since - the first journal write when - /var/ becomes - writable triggers the flushing - anyway. - - - - SIGUSR2 - - Request immediate - rotation of the journal - files. - - - - - - Kernel Command Line - - A few configuration parameters from - journald.conf may be overridden on - the kernel command line: - - - - systemd.journald.forward_to_syslog= - systemd.journald.forward_to_kmsg= - systemd.journald.forward_to_console= - - Enables/disables - forwarding of collected log messages - to syslog, the kernel log buffer or - the system console. - - - See - journald.conf5 - for information about these settings. - - - - - - - - - See Also - - systemd1, - journalctl1, - journald.conf5, - systemd.journal-fields7, - sd-journal3 - - - - diff --git a/man/systemd-localed.service.xml b/man/systemd-localed.service.xml deleted file mode 100644 index 6cefc4265f..0000000000 --- a/man/systemd-localed.service.xml +++ /dev/null @@ -1,89 +0,0 @@ - - - - - - - - - systemd-localed.service - systemd - - - - Developer - Lennart - Poettering - lennart@poettering.net - - - - - - systemd-localed.service - 8 - - - - systemd-localed.service - systemd-localed - Locale bus mechanism - - - - systemd-localed.service - /usr/lib/systemd/systemd-localed - - - - Description - - systemd-localed is a system - service that may be used as mechanism to change the - system locale settings, as well as the console key - mapping and default X11 key - mapping. systemd-localed is - automatically activated on request and terminates - itself when it is unused. - - The tool - localectl1 - is a command line client to this service. - - See the - developer documentation for information about - the APIs systemd-localed - provides. - - - - See Also - - systemd1, - locale.conf5, - vconsole.conf5, - localectl1, - loadkeys1 - - - - diff --git a/man/systemd-logind.service.xml b/man/systemd-logind.service.xml deleted file mode 100644 index 00f34051a3..0000000000 --- a/man/systemd-logind.service.xml +++ /dev/null @@ -1,133 +0,0 @@ - - - - - - - - - systemd-logind.service - systemd - - - - Developer - Lennart - Poettering - lennart@poettering.net - - - - - - systemd-logind.service - 8 - - - - systemd-logind.service - systemd-logind - Login manager - - - - systemd-logind.service - /usr/lib/systemd/systemd-logind - - - - Description - - systemd-logind is a system - service that manages user logins. It is responsible - for: - - - Keeping track of users and sessions, their - processes and their idle state - - Creating control groups for - user processes - - Providing PolicyKit-based access - for users to operations such as system - shutdown or sleep - - Implementing a shutdown/sleep - inhibition logic for - applications - - Handling of power/sleep - hardware keys - - Multi-seat - management - - Session - switch management - - Device access management for - users - - Automatic spawning of text - logins (gettys) on virtual console activation - and user runtime directory - management - - - User sessions are registered in logind via the - pam_systemd8 - PAM module. - - See - logind.conf5 - for information about the configuration of this - service. - - See Multi-Seat - on Linux for an introduction into basic - concepts of logind such as users, sessions and seats. - - See the - logind D-Bus API Documentation for information about - the APIs systemd-logind - provides. - - For more information on the inhibition logic see - the Inhibitor - Lock Developer Documentation. - - - - See Also - - systemd1, - systemd-user-sessions.service8, - loginctl1, - logind.conf5, - pam_systemd8 - - - - diff --git a/man/systemd-machine-id-setup.xml b/man/systemd-machine-id-setup.xml deleted file mode 100644 index 25fb63af2d..0000000000 --- a/man/systemd-machine-id-setup.xml +++ /dev/null @@ -1,132 +0,0 @@ - - - - - - - - - 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. - - - - - Options - - The following options are understood: - - - - - - - Prints a short help - text and exits. - - - - - - Prints a short version - string and exits. - - - - - - - Exit status - - On success 0 is returned, a non-zero failure - code otherwise. - - - - See Also - - systemd1, - machine-id5, - dbus-uuidgen1 - - - - diff --git a/man/systemd-modules-load.service.xml b/man/systemd-modules-load.service.xml deleted file mode 100644 index e5f10a7beb..0000000000 --- a/man/systemd-modules-load.service.xml +++ /dev/null @@ -1,101 +0,0 @@ - - - - - - - - systemd-modules-load.service - systemd - - - - Developer - Lennart - Poettering - lennart@poettering.net - - - - - - systemd-modules-load.service - 8 - - - - systemd-modules-load.service - systemd-modules-load - Configure kernel modules to load 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 - from 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, - wine8 - - - - diff --git a/man/systemd-notify.xml b/man/systemd-notify.xml deleted file mode 100644 index b03492c5c1..0000000000 --- a/man/systemd-notify.xml +++ /dev/null @@ -1,218 +0,0 @@ - - - - - - - - - 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: - - - - - - - Prints a short help - text and exits. - - - - - - Prints a short version - string and exits. - - - - - - 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. - - - - - - Controls disk - read-ahead operations. The argument - must be a string, and either "cancel", - "done" or "noreplay". For details - about the semantics of this option see - sd_readahead3. - - - - - - - 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" - - # Do something with $a ... - - systemd-notify --status="Waiting for data..." -done - - - - - See Also - - systemd1, - systemctl1, - systemd.unit5, - sd_notify3, - sd_booted3 - - - - diff --git a/man/systemd-nspawn.xml b/man/systemd-nspawn.xml deleted file mode 100644 index fef5c2c83a..0000000000 --- a/man/systemd-nspawn.xml +++ /dev/null @@ -1,331 +0,0 @@ - - - - - - - - - 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 - - - - - 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 - yum8 - or - debootstrap8 - 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. - - systemd-nspawn implements the - Container - Interface specification. - - - - Options - - If no arguments are passed the container is set - up and a shell started in it, otherwise the passed - command and arguments are executed in it. The - following options are understood: - - - - - - - Prints a short help - text and exits. - - - - - - - Directory to use as - file system root for the namespace - container. If omitted the current - directory will be - used. - - - - - - - Automatically search - for an init binary and invoke it - instead of a shell or a user supplied - program. - - - - - - - Run the command - under specified user, create home - directory and cd into it. As rest - of systemd-nspawn, this is not - the security feature and limits - against accidental changes only. - - - - - - - Set the specified uuid - for the container. The init system - will initialize - /etc/machine-id - from this if this file is not set yet. - - - - - - - - Makes the container appear in - other hierarchies than the name=systemd:/ one. - Takes a comma-separated list of controllers. - - - - - - - Turn off networking in - the container. This makes all network - interfaces unavailable in the - container, with the exception of the - loopback device. - - - - - - Mount the root file - system read only for 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. - - - - - - 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, - 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. If - auto (the default), - and the right subdirectory of - /var/log/journal - exists, it will be bind mounted - into the container. If the - subdirectory doesn't 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 - . - - - - - - - Example 1 - - # yum --releasever=17 --nogpgcheck --installroot ~/fedora-tree/ install yum passwd vim-minimal rootfiles systemd -# systemd-nspawn -D ~/fedora-tree /usr/lib/systemd/systemd - - This installs a minimal Fedora distribution into - the directory ~/fedora-tree/ - and then boots an OS in a namespace container in it, - with systemd as init system. - - - - Example 2 - - # 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. - - - - - Exit status - - The exit code of the program executed in the - container is returned. - - - - See Also - - systemd1, - chroot1, - yum8, - debootstrap8 - - - - diff --git a/man/systemd-quotacheck.service.xml b/man/systemd-quotacheck.service.xml deleted file mode 100644 index 4d0218b659..0000000000 --- a/man/systemd-quotacheck.service.xml +++ /dev/null @@ -1,102 +0,0 @@ - - - - - - - - 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-load.service.xml b/man/systemd-random-seed-load.service.xml deleted file mode 100644 index 87f563e293..0000000000 --- a/man/systemd-random-seed-load.service.xml +++ /dev/null @@ -1,80 +0,0 @@ - - - - - - - - systemd-random-seed-load.service - systemd - - - - Developer - Lennart - Poettering - lennart@poettering.net - - - - - - systemd-random-seed-load.service - 8 - - - - systemd-random-seed-load.service - systemd-random-seed-save.service - systemd-random-seed - Load and save the system random seed at boot and shutdown - - - - systemd-random-seed-load.service - systemd-random-seed-save.service - /usr/lib/systemd/systemd-random-seed - - - - Description - - systemd-random-seed-load.service - is an early-boot service that restores the random seed - of the - system. systemd-random-seed-save.service - is a late-shutdown service that saves the random seed - of the system. 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/random-seed. - - - - See Also - - systemd1, - random4 - - - - diff --git a/man/systemd-readahead-replay.service.xml b/man/systemd-readahead-replay.service.xml deleted file mode 100644 index 66d253454b..0000000000 --- a/man/systemd-readahead-replay.service.xml +++ /dev/null @@ -1,113 +0,0 @@ - - - - - - - - - systemd-readahead-replay.service - systemd - - - - Developer - Lennart - Poettering - lennart@poettering.net - - - - - - systemd-readahead-replay.service - 8 - - - - systemd-readahead-replay.service - systemd-readahead-collect.service - systemd-readahead-done.service - systemd-readahead-done.timer - systemd-readahead - Disk read ahead logic - - - - systemd-readahead-replay.service - systemd-readahead-collect.service - systemd-readahead-done.service - systemd-readahead-done.timer - /usr/lib/systemd/systemd-readahead - - - - Description - - systemd-readahead-collect.service - is a service that collects disk usage patterns at boot - time. systemd-readahead-replay.service - is a service that replays this access data collected - at the subsequent boot. Since disks tend to be - magnitudes slower than RAM this is intended to improve - boot speeds by pre-loading early at boot all data on - disk that is known to be read for the complete boot - process. - - systemd-readahead-done.service - is executed a short while after boot completed and signals - systemd-readahead-collect.service - to end data collection. On this signal this service - will then sort the collected disk accesses and store - information about them disk in - /.readahead. - - Normally, both - systemd-readahead-collect.service - and - systemd-readahead-replay.service - are activated at boot so that access patterns from the - preceding boot are replayed and new data collected - for the subsequent boot. However, on read-only media - where the collected data cannot be stored it might - be a good idea to disable - systemd-readahead-collect.service. - - On rotating media, when replaying disk accesses - at early boot - systemd-readahead-replay.service - will order read requests by their location on disk. On - non-rotating media, they will be ordered by their - original access timestamp. If the file system supports - it - systemd-readahead-collect.service - will also defragment and rearrange files on disk to - optimize subsequent boot times. - - - - See Also - - systemd1 - - - - diff --git a/man/systemd-remount-fs.service.xml b/man/systemd-remount-fs.service.xml deleted file mode 100644 index d920c0c400..0000000000 --- a/man/systemd-remount-fs.service.xml +++ /dev/null @@ -1,87 +0,0 @@ - - - - - - - - systemd-remount-fs.service - systemd - - - - Developer - Lennart - Poettering - lennart@poettering.net - - - - - - systemd-remount-fs.service - 8 - - - - systemd-remount-fs.service - systemd-remount-fs - Remount root and kernel file systems - - - - systemd-remount-fs.service - /usr/lib/systemd/systemd-remount-fs - - - - 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 virtual 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. - - - - See Also - - systemd1, - fstab5, - mount8 - - - - diff --git a/man/systemd-shutdownd.service.xml b/man/systemd-shutdownd.service.xml deleted file mode 100644 index c1b8ef7a49..0000000000 --- a/man/systemd-shutdownd.service.xml +++ /dev/null @@ -1,77 +0,0 @@ - - - - - - - - - systemd-shutdownd.service - systemd - - - - Developer - Lennart - Poettering - lennart@poettering.net - - - - - - systemd-shutdownd.service - 8 - - - - systemd-shutdownd.service - systemd-shutdownd.socket - systemd-shutdownd - Scheduled shutdown service - - - - systemd-shutdownd.service - systemd-shutdownd.socket - /usr/lib/systemd/systemd-shutdownd - - - - Description - - systemd-shutdownd.service is a - system service that implements scheduled shutdowns, as - exposed by - shutdown8. - systemd-shutdownd.service is automatically activated on request and terminates - itself when it is unused. - - - - See Also - - systemd1, - shutdown8 - - - - diff --git a/man/systemd-suspend.service.xml b/man/systemd-suspend.service.xml deleted file mode 100644 index 9b8bad4791..0000000000 --- a/man/systemd-suspend.service.xml +++ /dev/null @@ -1,126 +0,0 @@ - - - - - - - - - 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/systemd-sleep - - - - Description - - systemd-suspend.service is - a system service that is pulled in by - suspend.target and is responsible - for the actual system suspend. Similar, - 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 before all executables - 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. - - - - See Also - - systemd1, - systemctl1, - systemd.special7, - systemd-halt.service8 - - - - diff --git a/man/systemd-sysctl.service.xml b/man/systemd-sysctl.service.xml deleted file mode 100644 index 72a102c128..0000000000 --- a/man/systemd-sysctl.service.xml +++ /dev/null @@ -1,78 +0,0 @@ - - - - - - - - systemd-sysctl.service - systemd - - - - Developer - Lennart - Poettering - lennart@poettering.net - - - - - - systemd-sysctl.service - 8 - - - - systemd-sysctl.service - systemd-sysctl - Configure kernel parameters at boot - - - - systemd-sysctl.service - /usr/lib/systemd/systemd-sysctl - - - - Description - - 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 Also - - systemd1, - sysctl.d5, - sysctl8, - wine8 - - - - diff --git a/man/systemd-system-update-generator.xml b/man/systemd-system-update-generator.xml deleted file mode 100644 index 18a23ed7fc..0000000000 --- a/man/systemd-system-update-generator.xml +++ /dev/null @@ -1,79 +0,0 @@ - - - - - - - - systemd-system-update-generator - systemd - - - - Developer - Lennart - Poettering - lennart@poettering.net - - - - - - systemd-system-update-generator - 8 - - - - systemd-system-update-generator - Generator for redirecting boot to offline update mode - - - - /usr/lib/systemd/system-generators/systemd-system-update-generator - - - - 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 - implements the generator - specification. - - - - See Also - - systemd1, - systemd.special7 - - - - diff --git a/man/systemd-timedated.service.xml b/man/systemd-timedated.service.xml deleted file mode 100644 index ea2abc5765..0000000000 --- a/man/systemd-timedated.service.xml +++ /dev/null @@ -1,88 +0,0 @@ - - - - - - - - - systemd-timedated.service - systemd - - - - Developer - Lennart - Poettering - lennart@poettering.net - - - - - - systemd-timedated.service - 8 - - - - systemd-timedated.service - systemd-timedated - Time and date bus mechanism - - - - systemd-timedated.service - /usr/lib/systemd/systemd-timedated - - - - Description - - systemd-timedated is a - system service that may be used as mechanism to change - the system clock and timezone, as well as to - enable/disable NTP time - synchronization. systemd-timedated - is automatically activated on request and terminates - itself when it is unused. - - The tool - timedatectl1 - is a command line client to this service. - - See the - developer documentation for information about - the APIs systemd-timedated - provides. - - - - See Also - - systemd1, - timedatectl1, - localtime5, - hwclock8 - - - - diff --git a/man/systemd-tmpfiles.xml b/man/systemd-tmpfiles.xml deleted file mode 100644 index 22744c7c41..0000000000 --- a/man/systemd-tmpfiles.xml +++ /dev/null @@ -1,162 +0,0 @@ - - - - - - - - - systemd-tmpfiles - systemd - - - - Developer - Lennart - Poettering - lennart@poettering.net - - - - - - systemd-tmpfiles - 8 - - - - systemd-tmpfiles - systemd-tmpfiles-setup.service - systemd-tmpfiles-clean.service - systemd-tmpfiles-clean.timer - Creates, deletes and cleans up volatile - and temporary files and directories - - - - - systemd-tmpfiles OPTIONS CONFIGURATION FILE - - - systemd-tmpfiles-setup.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.d - 5 - . - - If invoked with no arguments, it applies all - directives from all configuration files. If one or - more file names 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.d - 5 - 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, d, D in the configuration files are - created. Files and directories marked with z, - Z 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 all files and directories marked - with r, R in the configuration files - are removed. - - - - Only apply rules that - apply to paths with the specified - prefix. - - - - - - - Prints a short help - text and exits. - - - - - 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 - - - - - 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 deleted file mode 100644 index 31a18ba4b0..0000000000 --- a/man/systemd-tty-ask-password-agent.xml +++ /dev/null @@ -1,166 +0,0 @@ - - - - - - - - - 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: - - - - - - - Prints a short help - text and exits. - - - - - - Prints a short version - string and exits. - - - - - - 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-udevd.service.xml b/man/systemd-udevd.service.xml deleted file mode 100644 index 92fb38f067..0000000000 --- a/man/systemd-udevd.service.xml +++ /dev/null @@ -1,168 +0,0 @@ - - - - - - - systemd-udevd.service - systemd - - - Developer - Kay - Sievers - kay@vrfy.org - - - - - - systemd-udevd.service - 8 - - - - - systemd-udevd.service - systemd-udevd-control.socket - systemd-udevd-kernel.socket - systemd-udevd - Device event managing daemon - - - - systemd-udevd.service - systemd-udevd-control.socket - systemd-udevd-kernel.socket - - - /usr/lib/systemd/systemd-udevd - - - - - - - - - - - - Description - systemd-udevd listens to kernel uevents. - For every event, systemd-udevd executes matching instructions - specified in udev rules. See - udev7 - . - The behavior of the running daemon can be changed with - udevadm control. - - - Options - - - - - Detach and run in the background. - - - - - - Print debug messages to stderr. - - - - - - Limit the number of events executed in parallel. - - - - - - - Delay the execution of RUN instruction by the given - number of seconds. This option might be useful when - debugging system crashes during coldplug caused by loading - non-working kernel modules. - - - - - - Specify when systemd-udevd should resolve names of users and groups. - When set to (the default) names will be - resolved when the rules are parsed. When set to - names will be resolved for every event. - When set to names will never be resolved - and all devices will be owned by root. - - - - - - Print version number. - - - - - - Print help text. - - - - - - Environment - - - UDEV_LOG= - - Set the logging priority. - - - - - - Kernel command line - - Parameters starting with "rd." will be read when - systemd-udevd is used in an initrd. - - udev.log-priority= - rd.udev.log-priority= - - Set the logging priority. - - - - udev.children-max= - rd.udev.children-max= - - Limit the number of events executed in parallel. - - - - udev.exec-delay= - rd.udev.exec-delay= - - Delay the execution of RUN instruction by the given - number of seconds. This option might be useful when - debugging system crashes during coldplug caused by loading - non-working kernel modules. - - - - - - - See Also - - udev7 - , - udevadm8 - - - diff --git a/man/systemd-update-utmp-runlevel.service.xml b/man/systemd-update-utmp-runlevel.service.xml deleted file mode 100644 index 0e19581f98..0000000000 --- a/man/systemd-update-utmp-runlevel.service.xml +++ /dev/null @@ -1,76 +0,0 @@ - - - - - - - - systemd-update-utmp-runlevel.service - systemd - - - - Developer - Lennart - Poettering - lennart@poettering.net - - - - - - systemd-update-utmp-runlevel.service - 8 - - - - systemd-update-utmp-runlevel.service - systemd-update-utmp-shutdown.service - systemd-update-utmp - Write audit and utmp updates at runlevel - changes and shutdown - - - - systemd-update-utmp-runlevel.service - systemd-update-utmp-shutdown.service - /usr/lib/systemd/systemd-update-utmp - - - - 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-shutdown.service - does the same for shut-down requests. - - - - See Also - - systemd1, - utmp5, - auditd8 - - - - diff --git a/man/systemd-user-sessions.service.xml b/man/systemd-user-sessions.service.xml deleted file mode 100644 index 9214ec9c35..0000000000 --- a/man/systemd-user-sessions.service.xml +++ /dev/null @@ -1,77 +0,0 @@ - - - - - - - - systemd-user-sessions.service - systemd - - - - Developer - Lennart - Poettering - lennart@poettering.net - - - - - - 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 - /usr/lib/systemd/systemd-user-sessions - - - - 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. - - - - See Also - - systemd1, - systemd-logind.service8, - pam_nologin8 - - - - diff --git a/man/systemd-vconsole-setup.service.xml b/man/systemd-vconsole-setup.service.xml deleted file mode 100644 index c1ef80dae4..0000000000 --- a/man/systemd-vconsole-setup.service.xml +++ /dev/null @@ -1,118 +0,0 @@ - - - - - - - - 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 deleted file mode 100644 index fe559e1dcb..0000000000 --- a/man/systemd.automount.xml +++ /dev/null @@ -1,167 +0,0 @@ - - - - - - - - - systemd.automount - systemd - - - - Developer - Lennart - Poettering - lennart@poettering.net - - - - - - systemd.automount - 5 - - - - systemd.automount - Automount unit configuration - - - - systemd.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 is not - existing at time that the automount - point is installed it is created. This - string must be reflected in the unit - file name. (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, - systemctl8, - systemd.unit5, - systemd.mount5, - mount8, - automount8 - - - - diff --git a/man/systemd.conf.xml b/man/systemd.conf.xml deleted file mode 100644 index a6be932c73..0000000000 --- a/man/systemd.conf.xml +++ /dev/null @@ -1,284 +0,0 @@ - - - - - - - - - systemd.conf - systemd - - - - Developer - Lennart - Poettering - lennart@poettering.net - - - - - - systemd.conf - 5 - - - - systemd.conf - System and service manager configuration file - - - - /etc/systemd/system.conf - /etc/systemd/user.conf - - - - Description - - When run as system instance systemd reads the - configuration file system.conf, - otherwise user.conf. 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 indexes. - - - - DefaultControllers=cpu - - Configures in which - cgroup controller hierarchies to - create per-service cgroups - automatically, in addition to the - name=systemd named hierarchy. Defaults - to 'cpu'. Takes a space separated list - of controller names. Pass an empty - string to ensure that systemd does not - touch any hierarchies but its - own. - - - - JoinControllers=cpu,cpuacct,cpuset 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. - - - - 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. - - - - TimerSlackNSec= - - Sets the timer slack - in nanoseconds for PID 1 which is then - inherited to 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 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. - - - - 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 - - - - diff --git a/man/systemd.device.xml b/man/systemd.device.xml deleted file mode 100644 index 141d72e3dc..0000000000 --- a/man/systemd.device.xml +++ /dev/null @@ -1,168 +0,0 @@ - - - - - - - - - systemd.device - systemd - - - - Developer - Lennart - Poettering - lennart@poettering.net - - - - - - systemd.device - 5 - - - - systemd.device - Device unit configuration - - - - systemd.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 automatically create dynamic 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. - - 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 - properties are understood by systemd: - - - - SYSTEMD_WANTS= - Adds dependencies of - type Wants from - this unit to all listed units. This - 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 systemd - unit. - - - - 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 the moment it shows up 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. - - - - ID_MODEL_FROM_DATABASE= - ID_MODEL= - - If set, this property is - used as description string for the - device unit. - - - - - - - - - See Also - - systemd1, - systemctl8, - systemd.unit5, - udev7 - - - - diff --git a/man/systemd.exec.xml b/man/systemd.exec.xml deleted file mode 100644 index 7b6514375d..0000000000 --- a/man/systemd.exec.xml +++ /dev/null @@ -1,1154 +0,0 @@ - - - - - - - - - systemd.exec - systemd - - - - Developer - Lennart - Poettering - lennart@poettering.net - - - - - - systemd.exec - 5 - - - - systemd.exec - Execution environment configuration - - - - systemd.service, - systemd.socket, - systemd.mount, - systemd.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. 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. Takes an integer between 1 - (lowest priority) and 99 (highest - priority). The available priority - range depends on the selected CPU - scheduling policy (see above). 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 indexes. 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. See - environ7 - for details. - - - 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. The - parser strips leading and - trailing whitespace from the values - of assignments, unless you use - double quotes ("). - The - argument passed should be an absolute - file name, optionally prefixed with - "-", which indicates that if the file - does not exist it won't be read and no - error or warning message is - logged. The files listed with this - directive will be read shortly before - the process is executed. 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 - . If set to - the file - descriptor of standard input is - duplicated for standard output. If set - to standard - output will be connected to - /dev/null, - i.e. everything written to it will be - lost. If set to - standard output will be connected 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 to the - syslog3 - system syslog - service. - connects it with the kernel log buffer - which is accessible via - dmesg1. - connects it with the journal which is - accessible via - journalctl1 - (Note that everything that is written - to syslog or kmsg is implicitly stored - in the journal as well, those options - are hence supersets of this - one). , - and - work - similarly but copy the output to the - system console as - well. connects - standard output to a socket from - socket activation, semantics are - similar to the respective option of - StandardInput=. - This setting defaults to the value set - with - - in - systemd.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.conf5, - which defaults to - . - - - TTYPath= - Sets the terminal - device node to use if standard input, - output or stderr 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 syslog 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 - . - - - 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 control - various resource limits for executed - processes. See - setrlimit2 - for details. Use the string - infinity to - configure no limit on a specific - resource. - - - - 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. - - - - TCPWrapName= - If this is a - socket-activated service this sets the - tcpwrap service name to check the - permission for the current connection - with. This is only useful in - conjunction with socket-activated - services, and stream sockets (TCP) in - particular. It has no effect on other - socket types (e.g. datagram/UDP) and - on processes unrelated to socket-based - activation. If the tcpwrap - verification fails daemon start-up - will fail and the connection is - terminated. See - tcpd8 - for details. Note that this option may - be used to do access control checks - only. Shell commands and commands - described in - hosts_options5 - are not supported. - - - - 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. - 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 - effects 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. - - - - SecureBits= - Controls the secure - bits set for the executed process. See - capabilities7 - for details. Takes a list of strings: - , - , - , - , - and/or - . - - - - - 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 by the capabilities - attached to the executed file. Due to - that - CapabilityBoundingSet= - is probably the much more useful - setting. - - - - ControlGroup= - - Controls the control - groups the executed processes shall be - made members of. Takes a - space-separated list of cgroup - identifiers. A cgroup identifier has a - format like - cpu:/foo/bar, - where "cpu" identifies the kernel - control group controller used, and - /foo/bar is the - control group path. The controller - name and ":" may be omitted in which - case the named systemd control group - hierarchy is implied. Alternatively, - the path and ":" may be omitted, in - which case the default control group - path for this unit is implied. This - option may be used to place executed - processes in arbitrary groups in - arbitrary hierarchies -- which can be - configured externally with additional - execution limits. By default systemd - will place all executed processes in - separate per-unit control groups - (named after the unit) in the systemd - named hierarchy. Since every process - can be in one group per hierarchy only - overriding the control group path in - the named systemd hierarchy will - disable automatic placement in the - default group. This option is - primarily intended to place executed - processes in specific paths in - specific kernel controller - hierarchies. It is however not - recommended to manipulate the service - control group path in the systemd - named hierarchy. For details about - control groups see cgroups.txt. - - - - ControlGroupModify= - Takes a boolean - argument. If true, the control groups - created for this unit will be owned by - the user specified with - User= (and the - appropriate group), and he/she can create - subgroups as well as add processes to - the group. - - - - ControlGroupPersistent= - Takes a boolean - argument. If true, the control groups - created for this unit will be marked - to be persistent, i.e. systemd will - not remove them when stopping the - unit. The default is false, meaning - that the control groups will be - removed when the unit is stopped. For - details about the semantics of this - logic see PaxControlGroups. - - - - ControlGroupAttribute= - - Set a specific control - group attribute for executed - processes, and (if needed) add the - executed processes to a cgroup in the - hierarchy of the controller the - attribute belongs to. Takes two - space-separated arguments: the - attribute name (syntax is - cpu.shares where - cpu refers to a - specific controller and - shares to the - attribute name), and the attribute - value. Example: - ControlGroupAttribute=cpu.shares - 512. If this option is used - for an attribute that belongs to a - kernel controller hierarchy the unit - is not already configured to be added - to (for example via the - ControlGroup= - option) then the unit will be added to - the controller and the default unit - cgroup path is implied. Thus, using - ControlGroupAttribute= - is in most case sufficient to make use - of control group enforcements, - explicit - ControlGroup= are - only necessary in case the implied - default control group path for a - service is not desirable. For details - about control group attributes see - cgroups.txt. This - option may appear more than once, in - order to set multiple control group - attributes. - - - - CPUShares= - - Assign the specified - overall CPU time shares to the - processes executed. Takes an integer - value. This controls the - cpu.shares control - group attribute, which defaults to - 1024. For details about this control - group attribute see sched-design-CFS.txt. - - - - MemoryLimit= - MemorySoftLimit= - - Limit the overall memory usage - of the executed processes to a certain - size. Takes a memory size in bytes. If - the value is suffixed with K, M, G or - T the specified memory size is parsed - as Kilobytes, Megabytes, Gigabytes, - or Terabytes (to the base - 1024), respectively. This controls the - memory.limit_in_bytes - and - memory.soft_limit_in_bytes - control group attributes. For details - about these control group attributes - see memory.txt. - - - - DeviceAllow= - DeviceDeny= - - Control access to - specific device nodes by the executed processes. Takes two - space separated strings: a device node - path (such as - /dev/null) - followed by a combination of r, w, m - to control reading, writing, or - creating of the specific device node - by the unit, respectively. This controls the - devices.allow - and - devices.deny - control group attributes. For details - about these control group attributes - see devices.txt. - - - - BlockIOWeight= - - Set the default or - per-device overall block IO weight - value for the executed - processes. Takes either a single - weight value (between 10 and 1000) to - set the default block IO weight, or a - space separated pair of a file path - and a weight value to specify the - device specific weight value (Example: - "/dev/sda 500"). The file path may be - specified as path to a block device - node or as any other file in which - case the backing block device of the - file system of the file is - determined. This controls the - blkio.weight and - blkio.weight_device - control group attributes, which - default to 1000. Use this option - multiple times to set weights for - multiple devices. For details about - these control group attributes see - blkio-controller.txt. - - - - BlockIOReadBandwidth= - BlockIOWriteBandwidth= - - Set the per-device - overall block IO bandwidth limit for - the executed processes. Takes a space - separated pair of a file path and a - bandwidth value (in bytes per second) - to specify the device specific - bandwidth. The file path may be - specified as path to a block device - node or as any other file in which - case the backing block device of the - file system of the file is determined. - If the bandwidth is suffixed with K, M, - G, or T the specified bandwidth is - parsed as Kilobytes, Megabytes, - Gigabytes, or Terabytes, respectively (Example: - "/dev/disk/by-path/pci-0000:00:1f.2-scsi-0:0:0:0 - 5M"). This controls the - blkio.read_bps_device - and - blkio.write_bps_device - control group attributes. Use this - option multiple times to set bandwidth - limits for multiple devices. For - details about these control group - attributes see blkio-controller.txt. - - - - ReadWriteDirectories= - ReadOnlyDirectories= - InaccessibleDirectories= - - Sets up a new - file-system name space 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. You must list submounts - separately in these settings to - ensure the same limited access. These - options may be specified more than - once in which case all directories - listed will have limited access from - within the - namespace. - - - - PrivateTmp= - - Takes a boolean - argument. If true sets up a new file - system namespace for the executed - processes and mounts a private - /tmp directory - 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 - impossible. Defaults to - false. - - - - 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. - - - - MountFlags= - - Takes a mount - propagation flag: - , - or - , which - control whether the file system - namespace set up for this unit's - processes will receive or propagate - new mounts. See - mount1 - for details. Default 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. - - - - IgnoreSIGPIPE= - - Takes a boolean - argument. If true causes SIGPIPE to be - ignored in the executed - process. Defaults to true, since - 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 - process 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 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 don't - need to be listed - explicitly. - - - - - - - See Also - - systemd1, - systemctl8, - journalctl8, - systemd.unit5, - systemd.service5, - systemd.socket5, - systemd.swap5, - systemd.mount5, - systemd.kill5 - - - - diff --git a/man/systemd.journal-fields.xml b/man/systemd.journal-fields.xml deleted file mode 100644 index 76a436d650..0000000000 --- a/man/systemd.journal-fields.xml +++ /dev/null @@ -1,450 +0,0 @@ - - - - - - - - - systemd.journal-fields - systemd - - - - Developer - Lennart - Poettering - lennart@poettering.net - - - - - - systemd.journal-fields - 7 - - - - systemd.journal-fields - Special journal fields - - - - Description - - Entries in the journal resemble an environment - block in their syntax, however with fields that can - include binary data. Primarily, fields are formatted - UTF-8 text strings, and binary formatting is used only - where formatting as UTF-8 text strings makes little - sense. New fields may freely be defined by - applications, but a few fields have special - meaning. All fields with special meanings are - optional. In some cases fields may appear more than - once per entry. - - - - User Journal Fields - - User fields are fields that are directly passed - from clients and stored in the journal. - - - - MESSAGE= - - The human readable - message string for this - entry. This is supposed to be - the primary text shown to the - user. It is usually not - translated (but might be in - some cases), and is not - supposed to be parsed for meta - data. - - - - - MESSAGE_ID= - - A 128bit message - identifier ID for recognizing - certain message types, if this - is desirable. This should - contain a 128bit id formatted - as lower-case hexadecimal - string, without any separating - dashes or suchlike. This is - recommended to be a UUID - compatible ID, but this is not - enforced, and formatted - differently. Developers can - generate a new ID for this - purpose with - journalctl - --new-id. - - - - - PRIORITY= - - A priority value between - 0 (emerg) - and 7 - (debug) - formatted as decimal - string. This field is - compatible with syslog's - priority concept. - - - - - CODE_FILE= - CODE_LINE= - CODE_FUNC= - - The code location - generating this message, if - known. Contains the source - file name, the line number and - the function name. - - - - - ERRNO= - - The low-level Unix error - number causing this entry, if - any. Contains the numeric - value of - errno3 - formatted as decimal - string. - - - - - SYSLOG_FACILITY= - SYSLOG_IDENTIFIER= - SYSLOG_PID= - - Syslog compatibility - fields containing the facility - (formatted as decimal string), - the identifier string - (i.e. "tag"), and the client - PID. - - - - - - - - Trusted Journal Fields - - Fields prefixed with an underscore are trusted - fields, i.e. fields that are implicitly added by the - journal and cannot be altered by client code. - - - - _PID= - _UID= - _GID= - - The process, user and - group ID of the process the - journal entry originates from - formatted as decimal - string. - - - - - _COMM= - _EXE= - _CMDLINE= - - The name, the executable - path and the command line of - the process the journal entry - originates from. - - - - - _AUDIT_SESSION= - _AUDIT_LOGINUID= - - The session and login - UID of the process the journal - entry originates from, as - maintained by the kernel audit - subsystem. - - - - - _SYSTEMD_CGROUP= - _SYSTEMD_SESSION= - _SYSTEMD_UNIT= - _SYSTEMD_OWNER_UID= - - - The control group path in - the systemd hierarchy, the - systemd session ID (if any), - the systemd unit name (if any) - and the owner UID of the - systemd session (if any) of - the process the journal entry - originates from. - - - - - _SELINUX_CONTEXT= - - The SELinux security - context of the process the - journal entry originates - from. - - - - - _SOURCE_REALTIME_TIMESTAMP= - - The earliest trusted - timestamp of the message, if - any is known that is different - from the reception time of the - journal. This is the time in - usec since the epoch UTC - formatted as decimal - string. - - - - - _BOOT_ID= - - The kernel boot ID for - the boot the message was - generated in, formatted as - 128bit hexadecimal - string. - - - - - _MACHINE_ID= - - The machine ID of the - originating host, as available - in - machine-id5. - - - - - _HOSTNAME= - - The name of the - originating host. - - - - - _TRANSPORT= - - How the entry was - received by the journal - service. One of - driver, - syslog, - journal, - stdout, - kernel for - internally generated messages, - for those received via the - local syslog socket with the - syslog protocol, for those - received via the native - journal protocol, for the - those read from a services' - standard output or error - output, or for those read - from the kernel, respectively. - - - - - - - - Kernel Journal Fields - - Kernel fields are fields that are used by - messages originating in the kernel and stored in the - journal. - - - - _KERNEL_DEVICE= - - The kernel device - name. If the entry is - associated to a block device, - the major and minor of the - device node, separated by ':' - and prefixed by 'b'. Similar - for character devices, but - prefixed by 'c'. For network - devices the interface index, - prefixed by 'n'. For all other - devices '+' followed by the - subsystem name, followed by - ':', followed by the kernel - device name. - - - - _KERNEL_SUBSYSTEM= - - The kernel subsystem name. - - - - _UDEV_SYSNAME= - - The kernel device name - as it shows up in the device - tree below - /sys. - - - - _UDEV_DEVNODE= - - The device node path of - this device in - /dev. - - - - _UDEV_DEVLINK= - - Additional symlink names - pointing to the device node in - /dev. This - field is frequently set more - than once per entry. - - - - - - - Address Fields - - During serialization into external formats, such - as the Journal - Export Format or the Journal - JSON Format, the addresses of journal entries - are serialized into fields prefixed with double - underscores. Note that these aren't proper fields when - stored in the journal, but addressing meta data of - entries. They cannot be written as part of structured - log entries via calls such as - sd_journal_send3. They - may also not be used as matches for - sd_journal_add_match3 - - - - __CURSOR= - - The cursor for the - entry. A cursor is an opaque - text string that uniquely - describes the position of an - entry in the journal and is - portable across machines, - platforms and journal - files. - - - - - __REALTIME_TIMESTAMP= - - The wallclock time - (CLOCK_REALTIME) at the point - in time the entry was received - by the journal, in usec since - the epoch UTC formatted as - decimal string. This has - different properties from - _SOURCE_REALTIME_TIMESTAMP= - as it is usually a bit later - but more likely to be - monotonic. - - - - - __MONOTONIC_TIMESTAMP= - - The monotonic time - (CLOCK_MONOTONIC) at the point - in time the entry was received - by the journal in usec - formatted as decimal - string. To be useful as an - address for the entry this - should be combined with with - boot ID in - _BOOT_ID=. - - - - - - - See Also - - systemd1, - journalctl1, - journald.conf5, - sd-journal3 - - - - diff --git a/man/systemd.kill.xml b/man/systemd.kill.xml deleted file mode 100644 index 3fff2f57e6..0000000000 --- a/man/systemd.kill.xml +++ /dev/null @@ -1,170 +0,0 @@ - - - - - - - - - systemd.kill - systemd - - - - Developer - Lennart - Poettering - lennart@poettering.net - - - - - - systemd.kill - 5 - - - - systemd.kill - Kill environment configuration - - - - systemd.service, - systemd.socket, - systemd.mount, - systemd.swap - - - - Description - - Unit configuration files for services, sockets, - mount points and swap devices share a subset of - configuration options which define the process killing - parameters 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] section, depending on the unit - type. - - - - Options - - - - - KillMode= - Specifies how - processes of this service shall be - killed. One of - , - , - . - - If set to - all - remaining processes in the control - group of this unit will be terminated - 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 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. Defaults to - . - - Processes will first be - terminated via SIGTERM (unless the - signal to send is changed via - KillSignal=). If - then after a delay (configured via the - TimeoutSec= 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. - - - - KillSignal= - Specifies which signal - to use when killing a - service. Defaults to SIGTERM. - - - - - 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, - systemctl8, - journalctl8, - systemd.unit5, - systemd.service5, - systemd.socket5, - systemd.swap5, - systemd.mount5, - systemd.exec5 - - - - diff --git a/man/systemd.mount.xml b/man/systemd.mount.xml deleted file mode 100644 index 219ef6531e..0000000000 --- a/man/systemd.mount.xml +++ /dev/null @@ -1,282 +0,0 @@ - - - - - - - - - systemd.mount - systemd - - - - Developer - Lennart - Poettering - lennart@poettering.net - - - - - - systemd.mount - 5 - - - - systemd.mount - Mount unit configuration - - - - systemd.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. - - 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 independent on - unit files or /etc/fstab will be - monitored by systemd and appear like any other mount - unit in systemd. - - - - <filename>/etc/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. 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 from /etc/fstab. systemd - will create a dependency of type - from either - local-fs.target or - remote-fs.target, depending - whether the file system is local or remote. If - is set, an - automount unit will be created for the file - system. See - systemd.automount5 - for details. If - is - specified it may be used to 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 specify a unit as - s, min, - h, ms. - - If a mount point is configured in both - /etc/fstab and a unit file, the - configuration in the latter takes precedence. - - - - 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 - file name. (See above.) This option is - mandatory. - - - - Type= - Takes a string for the - filesystem 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. - - - - 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. Defaults to - 90s. - - - - Check - systemd.exec5 - and - systemd.kill5 - for more settings. - - - - Compatibility Options - - The following option is also available in the - [Mount] section, but exists purely - for compatibility reasons and should not be used in - newly written mount files. - - - - FsckPassNo= - - The pass number for - the file system checking service for - this mount. See - systemd.service5 - for more information on this setting. - - - - - - - See Also - - systemd1, - systemctl8, - systemd.unit5, - systemd.exec5, - systemd.kill5, - systemd.service5, - systemd.device5, - mount8, - systemd-fstab-generator8 - - - - diff --git a/man/systemd.path.xml b/man/systemd.path.xml deleted file mode 100644 index a27a97be77..0000000000 --- a/man/systemd.path.xml +++ /dev/null @@ -1,220 +0,0 @@ - - - - - - - - - systemd.path - systemd - - - - Developer - Lennart - Poettering - lennart@poettering.net - - - - - - systemd.path - 5 - - - - systemd.path - Path unit configuration - - - - systemd.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= - is set to , 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 a path is already existing - (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=. - - - - 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, - systemctl8, - systemd.unit5, - systemd.service5, - inotify7 - - - - diff --git a/man/systemd.preset.xml b/man/systemd.preset.xml deleted file mode 100644 index a692053876..0000000000 --- a/man/systemd.preset.xml +++ /dev/null @@ -1,204 +0,0 @@ - - - - - - - - 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 alphabetical - order, regardless in which of the directories they - reside, to guarantee that a specific preset file takes - precedence over another file with an alphabetically - earlier name, if both files contain lines that apply - to the same unit names. It is recommended to prefix - all file names with two-digit number, to simplify - ordering. - - 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 file name. - - - - Example - - - Default off example <filename>/usr/lib/systemd/system-preset/99-default.preset</filename>: - - disable * - - - This disables all units. Due to the file name - 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. - - - Administrator policy <filename>/etc/systemd/system-preset/00-lennart.preset</filename>: - - 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 file name 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 deleted file mode 100644 index 00a6398a1e..0000000000 --- a/man/systemd.service.xml +++ /dev/null @@ -1,924 +0,0 @@ - - - - - - - - - systemd.service - systemd - - - - Developer - Lennart - Poettering - lennart@poettering.net - - - - - - systemd.service - 5 - - - - systemd.service - Service unit configuration - - - - systemd.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. - - 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 - value if BusName= - is not 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 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 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. - - 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 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 finished - starting up. systemd will proceed - 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 - . - - 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 - , but its use - is otherwise recommended as well if - the process takes a name on the D-Bus - bus. - - - - - ExecStart= - Takes a command line - that is executed when this service - shall be started up. The first token - of the command line must be an - absolute file name, then followed by - arguments for the process. It is - mandatory to set this option for all - services. This option may not be - specified more than once, except when - Type=oneshot is - used in which case more than one - ExecStart= line is - accepted which are then invoked one by - one, sequentially in the order they - appear in the unit file. - - Optionally, if the absolute 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 - first token 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 for the - same command the former must precede - the latter. Unless - Type=forking is - set, the process started via this - command line will be considered the - main process of the daemon. The - command line accepts % specifiers as - described in - systemd.unit5. - - On top of that 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 up - at whitespace, resulting in no or more - arguments. Note that the first - argument (i.e. the program to execute) - may not be a variable, and must be a - literal and absolute path - name. - - Note that this setting does not - directly support shell command - lines. 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' - - For services run by a user - instance of systemd the special - environment variable - MANAGERPID is set - to the PID of the systemd - instance. - - - - - ExecStartPre= - ExecStartPost= - Additional commands - that are executed before or after - the command in - ExecStart=, respectively. Multiple - command lines may be concatenated in a - single directive, by separating them - by semicolons (these semicolons must - be passed as separate words). In that - case, the commands are executed one - after the other, - serially. Alternatively, these - directives may be specified more than - once with the same effect. However, - the latter syntax is not recommended - for compatibility with parsers - suitable for XDG - .desktop files. - Use of these settings is - optional. Specifier and environment - variable substitution is - supported. - - - - ExecReload= - Commands to execute to - trigger a configuration reload in the - service. This argument takes multiple - command lines, following the same - scheme as pointed out for - ExecStartPre= - 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 - variables 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. - - - - ExecStop= - Commands to execute to - stop the service started via - ExecStart=. This - argument takes multiple command lines, - following the same scheme as pointed - out for - ExecStartPre= - above. Use of this setting is - optional. All processes remaining for - a service after the commands - configured in this option are run are - terminated according to the - KillMode= setting - (see - systemd.kill5). If - this option is not specified the - process is terminated right-away 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 using the commands - configured in - ExecStop=. This - argument takes multiple command lines, - following the same scheme as pointed - out for - ExecStartPre. 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 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 90s, except when - Type=oneshot is - used in which case the timeout - is disabled by default. - - - - - 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 delay of this time 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 90s. - - - - - TimeoutSec= - A shorthand for configuring - both TimeoutStartSec= - and TimeoutStopSec= - to the specified value. - - - - - WatchdogSec= - Configures the - watchdog timeout for a service. This - 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 failure state. 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 - main service process shall be - restarted when it exits. Takes one of - , - , - , - or - . If set to - (the default) the - service will not be restarted when it - exits. If set to - it will be - restarted only when it exited cleanly, - i.e. terminated with an exit code of - 0. If set to - it will be - restarted only when it exited with an - exit code not equaling 0, when - terminated by a signal (including on - core dump), when an operation (such as - service reload) times out or when the - configured watchdog timeout is - triggered. If set to - it will be - restarted only if it exits due to - reception of an uncaught signal - (including on core dump). If set to - the service - will be restarted regardless whether - it exited cleanly or not, got - terminated abnormally by a signal or - hit a timeout. - - - - 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, and - are separated by spaces. Example: - "SuccessExitStatus=1 2 8 - SIGKILL", ensures that exit - codes 1, 2, 8 and the termination - signal SIGKILL are considered clean - service - terminations. - - - - 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. Example: - "RestartPreventExitStatus=1 6 - SIGABRT", ensures that exit - codes 1 and 6 and the termination signal - SIGABRT will not result in automatic - service restarting. - - - - 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=, - 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=, - ExecStopPost= - commands. If false, the setting is - applied to all configured commands the - same way. Defaults to - false. - - - - NonBlocking= - Set O_NONBLOCK flag - for all file descriptors passed via - socket-based activation. If true, all - file descriptors >= 3 (i.e. all except - STDIN/STDOUT/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 - WatchdogUsec= (see - above). If those options are used but - NotifyAccess= not - configured it will be implicitly set - to - . - - - - Sockets= - Specifies the name of - the socket units this service shall - inherit the sockets from when the - service is started. Normally it - should not be necessary to use this - setting as all sockets whose unit - shares the same name as the service - (ignoring the different suffix of course) - are passed to the spawned - process. - - Note that the same socket may be - passed to multiple processes at the - same time. Also note that a different - service may be activated on incoming - traffic than inherits the sockets. Or - in other words: The - Service= setting of - .socket units - doesn't have to match the inverse of the - Sockets= setting of - the .service it - refers to. - - - - StartLimitInterval= - StartLimitBurst= - - Configure service - start rate limiting. By default - services which are started more often - than 5 times within 10s are not - permitted to start any more times - until the 10s interval ends. With - these two options this rate limiting - may be modified. Use - StartLimitInterval= - to configure the checking interval - (defaults to 10s, set to 0 to disable - any kind of rate limiting). Use - StartLimitBurst= to - configure how many starts per interval - are allowed (defaults to 5). These - configuration options are particularly - useful in conjunction with - Restart=, however - 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 - an 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. Defaults to - . - - - - - Check - systemd.exec5 - and - systemd.kill5 - for more settings. - - - - - Compatibility Options - - The following options are also available in the - [Service] section, but exist purely - for compatibility reasons and should not be used in - newly written service files. - - - - SysVStartPriority= - Set the SysV start - priority to use to order this service - in relation to SysV services lacking - LSB headers. This option is only - necessary to fix ordering in relation - to legacy SysV services, that have no - ordering information encoded in the - script headers. As such it should only - be used as temporary compatibility - option, and not be used in new unit - files. Almost always it is a better - choice to add explicit ordering - directives via - After= or - Before=, - instead. For more details see - systemd.unit5. If - used, pass an integer value in the - range 0-99. - - - - FsckPassNo= - Set the fsck passno - priority to use to order this service - in relation to other file system - checking services. This option is only - necessary to fix ordering in relation - to fsck jobs automatically created for - all /etc/fstab - entries with a value in the fs_passno - column > 0. As such it should only be - used as option for fsck - services. Almost always it is a better - choice to add explicit ordering - directives via - After= or - Before=, - instead. For more details see - systemd.unit5. If - used, pass an integer value in the - same range as - /etc/fstab's - fs_passno column. See - fstab5 - for details. - - - - - - - See Also - - systemd1, - systemctl8, - systemd.unit5, - systemd.exec5, - systemd.kill5 - - - - diff --git a/man/systemd.snapshot.xml b/man/systemd.snapshot.xml deleted file mode 100644 index b432682a48..0000000000 --- a/man/systemd.snapshot.xml +++ /dev/null @@ -1,87 +0,0 @@ - - - - - - - - - systemd.snapshot - systemd - - - - Developer - Lennart - Poettering - lennart@poettering.net - - - - - - systemd.snapshot - 5 - - - - systemd.snapshot - Snapshot unit configuration - - - - systemd.snapshot - - - - Description - - Snapshot units are not configured via unit - configuration files. Nonetheless they are named - similar to filenames. A unit name 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 - systemctl8 - 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, - systemctl8, - systemd.unit5 - - - - diff --git a/man/systemd.socket.xml b/man/systemd.socket.xml deleted file mode 100644 index 4b1fcc8b0c..0000000000 --- a/man/systemd.socket.xml +++ /dev/null @@ -1,685 +0,0 @@ - - - - - - - - - systemd.socket - systemd - - - - Developer - Lennart - Poettering - lennart@poettering.net - - - - - - systemd.socket - 5 - - - - systemd.socket - Socket unit configuration - - - - systemd.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. - - For each socket file a matching service file - (see - systemd.service5 - for details) must exist, describing the service to - start on incoming traffic on the socket. Depending on - the setting of (see below), - this must either be named like the socket unit, but - with the suffix replaced; or it must be a template - file 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 may be used to implement on-demand - starting of services, as well as parallelized starting - of services. - - 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 STDIN and - STDOUT, 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 whether there is incoming - traffic on them or not. - - 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 whether it will be up and - running ever at all. 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. - - - - 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. - - - - 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. - - - - 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 - . This - option 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 for 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 - . - - - - 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.). - - - - 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.). - - - - 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. - - - - 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. - - - - PipeSize= - Takes an integer - value. Controls the pipe buffer size - of FIFOs configured in this socket - unit. See - fcntl2 - for details. - - - - 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 file name, - 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 - 90s. - - - - Service= - Specifies the service - unit name to activate on incoming - traffic. This defaults to the service - that bears the same name as the socket - (ignoring the different suffixes). In - most cases it should not be necessary - to use this option. - - - - - Check - systemd.exec5 - and - systemd.kill5 - for more settings. - - - - - See Also - - systemd1, - systemctl8, - systemd.unit5, - systemd.exec5, - systemd.kill5, - systemd.service5 - - - - diff --git a/man/systemd.special.xml b/man/systemd.special.xml deleted file mode 100644 index 9ea288e337..0000000000 --- a/man/systemd.special.xml +++ /dev/null @@ -1,817 +0,0 @@ - - - - - - - - - systemd.special - systemd - - - - Developer - Lennart - Poettering - lennart@poettering.net - - - - - - systemd.special - 7 - - - - systemd.special - Special systemd units - - - - basic.target, - bluetooth.target, - ctrl-alt-del.target, - cryptsetup.target, - dbus.service, - dbus.socket, - default.target, - display-manager.service, - emergency.target, - exit.target, - final.target, - getty.target, - graphical.target, - halt.target, - hibernate.target, - hybrid-sleep.target, - kbrequest.target, - kexec.target, - local-fs.target, - local-fs-pre.target, - mail-transfer-agent.target, - multi-user.target, - network.target, - nss-lookup.target, - nss-user-lookup.target, - poweroff.target, - printer.target, - reboot.target, - remote-fs.target, - remote-fs-pre.target, - rescue.target, - rpcbind.target, - runlevel2.target, - runlevel3.target, - runlevel4.target, - runlevel5.target, - shutdown.target, - sigpwr.target, - sleep.target, - smartcard.target, - sockets.target, - sound.target, - suspend.target, - swap.target, - sysinit.target, - syslog.socket, - syslog.target, - system-update.target, - time-sync.target, - umount.target - - - - Description - - A few units are treated specially by - systemd. They have special internal semantics and - cannot be renamed. - - - - Special System Units - - - - basic.target - - A special target unit - covering early boot-up. - systemd automatically - adds dependencies of the types - Requires and After for this - target unit to all SysV - service units configured for - runlevel 1 to 5. - Usually this should pull-in - all sockets, mount points, - swap devices and other basic - initialization necessary for - the general purpose - daemons. Most normal daemons - should have dependencies of - type After and Requires on - this unit. - - - - bluetooth.target - - This target is started - automatically as soon as a - bluetooth controller is - plugged in or becomes - available at boot. - - - - ctrl-alt-del.target - - systemd starts this - target whenever - Control+Alt+Del is pressed on - the console. Usually this - should be aliased (symlinked) - to - reboot.target. - - - - cryptsetup.target - - A target that pulls in - setup services for all - encrypted block - devices. - - - - dbus.service - - A special unit for the - D-Bus system bus. As soon as - this service is fully started - up systemd will connect to it - and register its - service. - - - - dbus.socket - - A special unit for the - D-Bus system bus socket. All - units with - Type=dbus - automatically gain a - dependency on this - unit. - - - - default.target - - The default unit systemd - starts at bootup. Usually this - should be aliased (symlinked) - to - multi-user.target - or - graphical.target. - The default unit systemd - starts at bootup can be - overridden with the - systemd.unit= - kernel command line option. - - - - display-manager.service - - The display manager - service. Usually this should - be aliased (symlinked) to - gdm.service - or a similar display manager - service. - systemd automatically - adds dependencies of type - After for this target unit to - all SysV init script service - units with a LSB header - referring to the - $x-display-manager - facility. - - - - emergency.target - - A special target unit - that starts an emergency - shell on the main - console. This unit is supposed - to be used with the kernel - command line option - systemd.unit= - and has otherwise little use. - - - - - final.target - - A special target unit - that is used during the - shutdown logic and may be used - to pull in late services after - all normal services are - already terminated and all - mounts unmounted. - - - - - getty.target - - A special target unit - that pulls in all local TTY - getty instances. - - - - - graphical.target - - A special target unit - for setting up a graphical - login screen. This pulls in - multi-user.target. - - Units that are needed - for graphical login shall add - Wants dependencies for their - unit to this unit (or - multi-user.target) - during installation. - - - - hibernate.target - - A special target unit - for hibernating the - system. This pulls in - sleep.target. - - - - hybrid-sleep.target - - A special target unit - for hibernating and suspending the - system at the same time. This pulls in - sleep.target. - - - - halt.target - - A special target unit - for shutting down and halting the system. - - Applications wanting to - halt the system should start - this unit. - - - - kbrequest.target - - systemd starts this - target whenever Alt+ArrowUp is - pressed on the console. This - is a good candidate to be - aliased (symlinked) to - rescue.target. - - - - kexec.target - - A special target unit - for shutting down and rebooting the system via kexec. - - Applications wanting to - reboot the system with kexec should start - this unit. - - - - local-fs.target - - systemd automatically - adds dependencies of type - After to all mount units that - refer to local mount points - for this target unit. In - addition, systemd adds - dependencies of type Wants to - this target unit for those - mounts listed in - /etc/fstab - that have the - and - - mount options set. - - systemd automatically - adds dependencies of type - After for this target unit to - all SysV init script service - units with an LSB header - referring to the - $local_fs - facility. - - - - local-fs-pre.target - - This target unit is - automatically ordered before - all local mount points marked - with - (see above). It can be used to - execute certain units before - all local mounts. - - - - mail-transfer-agent.target - - The mail transfer agent - (MTA) service. Usually this - should pull-in all units - necessary for - sending/receiving mails on the - local host. - - systemd automatically - adds dependencies of type - After for this target unit to - all SysV init script service - units with an LSB header - referring to the - $mail-transfer-agent. - - - - multi-user.target - - A special target unit - for setting up a multi-user - system (non-graphical). This - is pulled in by - graphical.target. - - Units that are needed - for a multi-user system shall - add Wants dependencies to - this unit for their unit during - installation. - - - - network.target - - systemd automatically - adds dependencies of type - After for this target unit to - all SysV init script service - units with an LSB header - referring to the - $network - facility. - - - - nss-lookup.target - - A target that should be - used as synchronization point - for all host/network name - service lookups. Note that - this is independent of - user/group name lookups for - which - nss-user-lookup.target - should be used. systemd - automatically adds - dependencies of type After for - this target unit to all SysV - init script service units with - an LSB header referring to the - $named - facility. - - - - nss-user-lookup.target - - A target that should be - used as synchronization point - for all user/group name - service lookups. Note that - this is independent of - host/network name lookups for - which - nss-lookup.target - should be used. - - - - poweroff.target - - A special target unit - for shutting down and powering off the system. - - Applications wanting to - power off the system should start - this unit. - - runlevel0.target - is an alias for this target - unit, for compatibility with SysV. - - - - printer.target - - This target is started - automatically as soon as a - printer is plugged in or - becomes available at - boot. - - - - reboot.target - - A special target unit - for shutting down and rebooting the system. - - Applications wanting to - reboot the system should start - this unit. - - runlevel6.target - is an alias for this target - unit, for compatibility with SysV. - - - - remote-fs.target - - Similar to - local-fs.target, - but for remote mount - points. - - systemd automatically - adds dependencies of type - After for this target unit to - all SysV init script service - units with an LSB header - referring to the - $remote_fs - facility. - - - - remote-fs-pre.target - - This target unit is - automatically ordered before - all remote mount points marked - with - (see above). It can be used to - execute certain units before - all remote mounts. - - - - rescue.target - - A special target unit - for setting up the base system - and a rescue shell. - - runlevel1.target - is an alias for this target - unit, for compatibility with SysV. - - - - rpcbind.target - - systemd automatically - adds dependencies of type - After for this target unit to - all SysV init script service - units with an LSB header - referring to the - $portmap - facility. - - - - runlevel2.target - runlevel3.target - runlevel4.target - runlevel5.target - - These are targets that - are called whenever the SysV - compatibility code asks for - runlevel 2, 3, 4, 5, - respectively. It is a good - idea to make this an alias for - (i.e. symlink to) - multi-user.target - (for runlevel 2) or - graphical.target - (the others). - - - - shutdown.target - - A special target unit - that terminates the services - on system shutdown. - - Services that shall be - terminated on system shutdown - shall add Conflicts - dependencies to this unit for - their service unit, which is - implicitly done when - DefaultDependencies=yes - is set (the default). - - systemd automatically - adds dependencies of type - Conflicts to this target unit - for all SysV init script - service units that shall be - terminated in SysV runlevels 0 - or 6. - - - - sigpwr.target - - A special target that is - started when systemd receives - the SIGPWR process signal, - which is normally sent by the - kernel or UPS daemons when - power fails. - - - - sleep.target - - A special target unit - that is pulled in by - suspend.target, - hibernate.target and hybrid-sleep.target - and may be used to hook units - into the sleep state - logic. - - - - smartcard.target - - This target is started - automatically as soon as a - smartcard controller is - plugged in or becomes - available at boot. - - - - sockets.target - - A special target unit - that sets up all service - sockets. - - Services that can be - socket-activated shall add - Wants dependencies to this - unit for their socket unit - during installation. - - - - sound.target - - This target is started - automatically as soon as a - sound card is plugged in or - becomes available at - boot. - - - - suspend.target - - A special target unit - for suspending the - system. This pulls in - sleep.target. - - - - swap.target - - Similar to - local-fs.target, but for swap - partitions and swap - files. - - - - sysinit.target - - A special target unit - covering early boot-up scripts. - systemd automatically - adds dependencies of the types - Wants and After for all - SysV service units configured - for runlevels that are not 0 - to 6 to this target unit. - This covers the special - boot-up runlevels some - distributions have, such as S - or b. - - - - syslog.socket - - The socket unit - syslog implementations should - listen on. All userspace log - messages will be made - available on this socket. For - more information about syslog - integration, please consult - the Syslog - Interface - document. - - - - syslog.target - - systemd automatically - adds dependencies of type - After for this target unit to - all SysV init script service - units with an LSB header - referring to the - $syslog - facility. - - - - system-update.target - - A special target unit - that is used for off-line - system updates. - systemd-system-update-generator8 - will redirect the boot process - to this target if - /system-update - exists. For more information - see the System - Updates - Specification. - - - - time-sync.target - - systemd automatically - adds dependencies of type - After for this target unit to - all SysV init script service - units with an LSB header - referring to the - $time - facility. - - - - umount.target - - A special target unit - that umounts all mount and - automount points on system - shutdown. - - Mounts that shall be - unmounted on system shutdown - shall add Conflicts - dependencies to this unit for - their mount unit, which is - implicitly done when - DefaultDependencies=yes - is set (the default). - - - - - - - - Special User Units - - When systemd runs as a user instance, the - following special units are available, which have - similar definitions as their system counterparts: - default.target, - shutdown.target, - sockets.target - - In addition the following special unit is - understood only when systemd runs as service instance: - - - - exit.target - - A special service unit - for shutting down the - user service manager. - - Applications wanting to - terminate the user service - manager should start this - unit. If systemd receives - SIGTERM or SIGINT when running - as user service daemon it will - start this unit. - - Normally, this pulls in - shutdown.target - which in turn should be - conflicted by all units that - want to be shut down on - user service manager exit. - - - - - - - See Also - - systemd1, - systemd.unit5, - systemd.service5, - systemd.socket5, - systemd.target5, - bootup7 - - - - diff --git a/man/systemd.swap.xml b/man/systemd.swap.xml deleted file mode 100644 index a932143d43..0000000000 --- a/man/systemd.swap.xml +++ /dev/null @@ -1,213 +0,0 @@ - - - - - - - - - systemd.swap - systemd - - - - Developer - Lennart - Poettering - lennart@poettering.net - - - - - - systemd.swap - 5 - - - - systemd.swap - Swap unit configuration - - - - systemd.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. - - 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. - - Unless the option is set - for them all swap units configured in - /etc/fstab are also added as - requirements to swap.target, so - that they are waited for and activated during - boot. - - - - 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. - - - - 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 - 90s. - - - - Check - systemd.exec5 - and - systemd.kill5 - for more settings. - - - - See Also - - systemd1, - systemctl8, - systemd.unit5, - systemd.exec5, - systemd.kill5, - systemd.device5, - systemd.mount5, - swapon8, - systemd-fstab-generator8 - - - - diff --git a/man/systemd.target.xml b/man/systemd.target.xml deleted file mode 100644 index d1f4d22674..0000000000 --- a/man/systemd.target.xml +++ /dev/null @@ -1,108 +0,0 @@ - - - - - - - - - systemd.target - systemd - - - - Developer - Lennart - Poettering - lennart@poettering.net - - - - - - systemd.target - 5 - - - - systemd.target - Target unit configuration - - - - systemd.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, - systemctl8, - systemd.unit5, - systemd.special7 - - - - diff --git a/man/systemd.timer.xml b/man/systemd.timer.xml deleted file mode 100644 index 6fc26a5536..0000000000 --- a/man/systemd.timer.xml +++ /dev/null @@ -1,192 +0,0 @@ - - - - - - - - - systemd.timer - systemd - - - - Developer - Lennart - Poettering - lennart@poettering.net - - - - - - systemd.timer - 5 - - - - systemd.timer - Timer unit configuration - - - - systemd.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 , timer units will - implicitly have dependencies of type - Conflicts= and - Before= on - shutdown.target. These ensure - that timer units are stopped cleanly prior to system - shutdown. Only timer units involved with early boot or - late system shutdown should disable this - 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 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 - 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. - - - - 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. - - - - - - See Also - - systemd1, - systemctl8, - systemd.unit5, - systemd.service5 - - - - diff --git a/man/systemd.unit.xml b/man/systemd.unit.xml deleted file mode 100644 index c20efe5527..0000000000 --- a/man/systemd.unit.xml +++ /dev/null @@ -1,1084 +0,0 @@ - - - - - - - - - systemd.unit - systemd - - - - Developer - Lennart - Poettering - lennart@poettering.net - - - - - - systemd.unit - 5 - - - - systemd.unit - Unit configuration - - - - systemd.service, - systemd.socket, - systemd.device, - systemd.mount, - systemd.automount, - systemd.swap, - systemd.target, - systemd.path, - systemd.timer, - systemd.snapshot - - - - 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 file system path or a timer controlled and - supervised by - systemd1. 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 should have a - type-specific section, e.g. [Service] for a service - unit. See the respective man pages for more - information. - - 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 is prefixed - with it is ignored completely by - systemd. 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. - - 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. - - If a line starts with - followed by a file name, the specified file will be - parsed at this point. Make sure that the file that is - included has the appropriate section headers before - any directives. - - Along with a unit file - foo.service a directory - foo.service.wants/ may exist. All - units symlinked from such a directory are implicitly - added as dependencies of type - Wanted= to the unit. This is useful - to hook units into the start-up of other units, - without having to modify their unit configuration - files. For details about the semantics of - Wanted= see below. The preferred - way to create symlinks in the - .wants/ directory of a service 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. - - Note that while systemd offers a flexible - dependency system between units it is recommended to - use this functionality only sparsely and instead rely - on techniques such as bus-based or socket-based - activation which makes dependencies implicit, which - both results in a simpler and more flexible - system. - - Some unit names reflect paths existing in the - file system name space. 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 file name. Basically, - given a path, "/" is replaced by "-", and all - unprintable characters and the "-" are replaced by - C-style "\x20" escapes. The root directory "/" is - encoded as single dash, while otherwise the initial - and ending "/" is removed from all paths during - transformation. This escaping is reversible. - - 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 - filesystem. 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. Other specifiers exist, the - full list is: - - - Specifiers available in unit files - - - - - - - Specifier - Meaning - Details - - - - - %n - Full unit name - - - - %N - Unescaped full unit name - - - - %p - Prefix name - This refers to the string before the @, i.e. "getty" in the example above, where "tty3" is the instance name. - - - %P - Unescaped prefix name - - - - %i - Instance name - This is the string between the @ character and the suffix. - - - %I - Unescaped instance name - - - - %f - Unescaped file name - This is either the unescaped instance name (if set) with / prepended (if necessary), or the prefix name similarly prepended with /. - - - %c - Control group path of the unit - - - - %r - Root control group path of systemd - - - - %R - Parent directory of the root control group path of systemd - - - - %t - Runtime socket dir - This is either /run (for the system manager) or $XDG_RUNTIME_DIR (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. - - - %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 instance. - - - %s - User shell - This is the shell of the configured user of the unit, or (if none is set) the user running the systemd instance. - - - %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 host name of the running system. - - - -
- - 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. - - - - 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. - - - - 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. - - - - 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, in which - case requirement dependencies for all - listed names are 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 a unit listed here is not started - already it will not be started and the - transaction fails - immediately. - - - - Wants= - - A weaker version of - Requires=. A unit - listed in this option will be started - if the configuring unit is. However, - if the listed unit fails to start up - 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 a symlink 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= - - 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= - - 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 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= - - Lists one or more - units that are activated when this - unit enters the - 'failed' - state. - - - - PropagatesReloadTo= - ReloadPropagatedFrom= - - Lists one or more - units where reload requests on the - unit will be propagated to/on the - other unit will be propagated - from. 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. - - - - 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. - - - - OnFailureIsolate= - - Takes a boolean - argument. If the - unit listed in - OnFailure= will be - enqueued in isolation mode, i.e. all - units that are not its dependency will - be stopped. If this is set only a - single unit may be listed in - OnFailure=. Defaults - to - . - - - - 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= - - When clients are - waiting for a job of this unit to - complete, time out after the specified - time. 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 - Timeout= 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. - - - - ConditionPathExists= - ConditionPathExistsGlob= - ConditionPathIsDirectory= - ConditionPathIsSymbolicLink= - ConditionPathIsMountPoint= - ConditionPathIsReadWrite= - ConditionDirectoryNotEmpty= - ConditionFileNotEmpty= - ConditionFileIsExecutable= - ConditionKernelCommandLine= - ConditionVirtualization= - ConditionSecurity= - ConditionCapability= - ConditionHost= - ConditionNull= - - 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. - - 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. - - Similar, - 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. - - 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, - vmware, - microsoft, - oracle, - xen, - bochs, - chroot, - openvz, - lxc, - lxc-libvirt, - systemd-nspawn to - test against a specific - implementation. If multiple - virtualization technologies are nested - only the innermost is considered. The - test may be negated by prepending an - exclamation mark. - - ConditionSecurity= - may be used to check whether the given - security module is enabled on the - system. Currently the only recognized - value is selinux. - 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. - - ConditionHost= - may be used to match against the - host name or machine ID of the - host. This either takes a host name - string (optionally with shell style - globs) which is tested against the - locally set host name as returned by - gethostname2, - or a machine ID formatted as string - (see - machine-id5). - The test may be negated by prepending - an exclamation mark. - - Finally, - ConditionNull= may - be used to add a constant condition - check value to the unit. It takes a - boolean argument. If set to - false the condition - will always fail, otherwise - succeed. - - 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. - - - - 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. Thus - functionality should not be used in - normal units. - - - - Unit file may include a [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= - - 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 file name. - - - - WantedBy= - RequiredBy= - - Installs a symlink in - the .wants/ - or .requires/ - subdirectory for a unit, respectively. This has the - effect that when the listed unit name - is activated the unit listing it is - activated - too. WantedBy=foo.service - in a service - bar.service is - mostly equivalent to - Alias=foo.service.wants/bar.service - in the same file. - - - - Also= - - Additional units to - install when this unit is - installed. If the user requests - installation of a unit with this - option configured, - systemctl enable - will automatically install units - listed in this option as - well. - - - - - - - See Also - - systemd1, - systemctl8, - systemd.special7, - systemd.service5, - systemd.socket5, - systemd.device5, - systemd.mount5, - systemd.automount5, - systemd.swap5, - systemd.target5, - systemd.path5, - systemd.timer5, - systemd.snapshot5, - capabilities7 - - - - diff --git a/man/systemd.xml b/man/systemd.xml deleted file mode 100644 index 7b3d265b8d..0000000000 --- a/man/systemd.xml +++ /dev/null @@ -1,1272 +0,0 @@ - - - - - - - - - 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 system instance, systemd interprets - the configuration file - system.conf, otherwise - user.conf. See - systemd.conf5 - for more information. - - - - Options - - The following options are understood: - - - - - - - Prints a short help - text and exits. - - - - - Prints a systemd version - identifier and exits. - - - - - 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. - - - - - Extract D-Bus - interface introspection data. This is - mostly useful at install time - to generate data suitable for the - D-Bus interfaces - repository. Optionally the interface - name for the introspection data may be - specified. If omitted, the - introspection data for all interfaces - is dumped. - - - - - 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". 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 or dynamically from system state. 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 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. - - - - 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 host name 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. - - - - - - 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. - - - - - - 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. - - 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 systemctl - 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 - SIGRTMIN+29 - - Sets the log level to - journal-or-kmsg - (or console on - SIGRTMIN+27, - kmsg on - SIGRTMIN+28, - or syslog-or-kmsg - on SIGRTMIN+29), as - controlled via - systemd.log_target=journal-or-kmsg - (or systemd.log_target=console - on SIGRTMIN+27, - systemd.log_target=kmsg - on SIGRTMIN+28, - or - systemd.log_target=syslog-or-kmsg - on SIGRTMIN+29) 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 isn't 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. If - shows terse service status updates on - the console during bootup. Defaults to - , unless - is passed as - kernel command line option in which - case it defaults to - . - - - - 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 - environment variables for the init - process and all its children at boot - time. May be used more than once to - set multiple variables. If the equal - sign and variable are missing it unsets - an environment variable which might be - passed in from the initial ram - disk. - - - - quiet - - If passed turns 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 to the - kernel. Passing this option hence - turns off the usual output from both - the system manager and the - kernel. - - - - emergency - - Boot into emergency - mode. This is equivalent to - systemd.unit=emergency.target - and provided for compatibility - reasons and to be easier to type. - - - - 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 - - systemd.conf5, - locale.conf5, - systemctl1, - journalctl1, - systemd-notify1, - daemon7, - sd-daemon3, - systemd.unit5, - systemd.special5, - pkg-config1, - kernel-command-line7, - bootup7 - - - - diff --git a/man/telinit.xml b/man/telinit.xml deleted file mode 100644 index 4c6064f54a..0000000000 --- a/man/telinit.xml +++ /dev/null @@ -1,195 +0,0 @@ - - - - - - - - - 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: - - - - - - Prints a short help - text and exits. - - - - - - Don't 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 deleted file mode 100644 index 01ca0a73d5..0000000000 --- a/man/timedatectl.xml +++ /dev/null @@ -1,293 +0,0 @@ - - - - - - - - - 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. - - - - Options - - The following options are understood: - - - - - - - Prints a short help - text and exits. - - - - - - Prints a short version - string and exits. - - - - - - Do not pipe output into a - pager. - - - - - - Don't query the user - for authentication for privileged - operations. - - - - - - - Execute the operation - remotely. Specify a hostname, or - username and hostname separated by @, - to connect to. This will use SSH to - talk to a remote - system. - - - - - - 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 - time zones 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 - time zone 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 - time zone is not fully supported and - will create various problems with time - zone changes and daylight saving - adjustments. If at all possible use - RTC in UTC. 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. - - - - Environment - - - - $SYSTEMD_PAGER - Pager to use when - is not given; - overrides $PAGER. Setting - this to an empty string or the value - cat is equivalent to passing - . - - - - - - 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 - 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 - 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 - - - - 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 -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 -... - - - - - - See Also - - systemd1, - hwclock8, - date1, - localtime5, - systemctl1, - systemd-timedated.service8 - - - - diff --git a/man/tmpfiles.d.xml b/man/tmpfiles.d.xml deleted file mode 100644 index 785264e3cf..0000000000 --- a/man/tmpfiles.d.xml +++ /dev/null @@ -1,321 +0,0 @@ - - - - - - - - tmpfiles.d - systemd - - - - Documentation - Brandon - Philips - brandon@ifup.org - - - - - - tmpfiles.d - 5 - - - - tmpfiles.d - Configuration for creation, deletion and - cleaning of volatile and temporary files - - - - /etc/tmpfiles.d/*.conf - /run/tmpfiles.d/*.conf - /usr/lib/tmpfiles.d/*.conf - - - - Description - - systemd-tmpfiles uses the - configuration files from the above directories to describe the - creation, cleaning and removal of volatile and - temporary files and directories which usually reside - in directories such as /run - or /tmp. - - - - Configuration Format - - Each configuration file shall be named in the - style of <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 configuration files in - /usr/lib/. Files in - /etc/ are reserved for the local - administrator, who may use this logic to override the - configuration files installed by vendor packages. All - configuration files are sorted by their filename in - alphabetical order, regardless in which of the - directories they reside, to guarantee that a specific - configuration file takes precedence over another file - with an alphabetically later name. - - If the administrator wants to disable a - configuration file supplied by the vendor the - recommended way is to place a symlink to - /dev/null in - /etc/tmpfiles.d/ bearing the - same file name. - - The configuration format is one line per path - containing action, path, mode, ownership, age and argument - fields: - - Type Path Mode UID GID Age Argument -d /run/user 0755 root root 10d - -L /tmp/foobar - - - - /dev/null - - - Type - - - f - Create a file if it doesn't exist yet (optionally writing a short string into it, if the argument parameter is passed) - - - - F - Create or truncate a file (optionally writing a short string into it, if the argument parameter is passed) - - - - w - Write the argument parameter to a file, if the file exists. - Lines of this type accept shell-style globs in place of normal path - names. The argument parameter will be written without a trailing - newline. C-style backslash escapes are interpreted. - - - - d - Create a directory if it doesn't exist yet - - - - D - Create or empty a directory - - - - p - Create a named pipe (FIFO) if it doesn't exist yet - - - - L - Create a symlink if it doesn't exist yet - - - - c - Create a character device node if it doesn't exist yet - - - - b - Create a block device node if it doesn't exist yet - - - - x - Ignore a path - during cleaning. Use this type - to exclude paths from clean-up - as controlled with the Age - parameter. Note that lines of - this type do not influence the - effect of r or R lines. Lines - of this type accept - shell-style globs in place of - normal path - names. - - - - r - Remove a file - or directory if it - exists. This may not be used - to remove non-empty - directories, use R for - that. Lines of this type - accept shell-style globs in - place of normal path - names. - - - - R - Recursively - remove a path and all its - subdirectories (if it is a - directory). Lines of this type - accept shell-style globs in - place of normal path - names. - - - - z - Restore - SELinux security context label - and set ownership and access - mode of a file or directory if - it exists. Lines of this type - accept shell-style globs in - place of normal path names. - - - - - Z - Recursively - restore SELinux security - context label and set - ownership and access mode of a - path and all its - subdirectories (if it is a - directory). Lines of this type - accept shell-style globs in - place of normal path - names. - - - - - - Mode - - The file access mode to use when - creating this file or directory. If omitted or - when set to - the default is used: 0755 for - directories, 0644 for all other file - objects. For z, Z lines if omitted or when set - to - the file access mode will not be - modified. This parameter is ignored for x, r, - R, L lines. - - - - UID, GID - - The user and group to use for this file - or directory. This may either be a numeric - user/group ID or a user or group name. If - omitted or when set to - the default 0 (root) - is used. For z, Z lines when omitted or when set to - - the file ownership will not be modified. - These parameters are ignored for x, r, R, L lines. - - - - Age - The date field, when set, is used to - decide what files to delete when cleaning. If - a file or directory is older than the current - time minus the age field it is deleted. The - field format is a series of integers each - followed by one of the following - postfixes for the respective time units: - - - - s - min - h - d - w - ms - m - us - - - If multiple integers and units are specified the time - values are summed up. If an integer is given without a unit, - s is assumed. - - - When the age is set to zero, the files are cleaned - unconditionally. - - The age field only applies to lines starting with - d, D and x. If omitted or set to - no automatic clean-up - is done. - - If the age field starts with a tilde - character (~) the clean-up is only applied to - files and directories one level inside the - directory specified, but not the files and - directories immediately inside it. - - - - Argument - - For L lines determines the destination - path of the symlink. For c, b determines the - major/minor of the device node, with major and - minor formatted as integers, separated by :, - e.g. "1:3". For f, F, w may be used to specify - a short string that is written to the file, - suffixed by a newline. Ignored for all other - lines. - - - - - - Example - - /etc/tmpfiles.d/screen.conf example - screen needs two directories created at boot with specific modes and ownership. - - d /var/run/screens 1777 root root 10d -d /var/run/uscreens 0755 root root 10d12h - - - - - See Also - - systemd1, - systemd-tmpfiles8, - systemd-delta1 - - - - diff --git a/man/vconsole.conf.xml b/man/vconsole.conf.xml deleted file mode 100644 index 45156b7447..0000000000 --- a/man/vconsole.conf.xml +++ /dev/null @@ -1,147 +0,0 @@ - - - - - - - - - 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=latarcyrheb-sun16 - - - - - - See Also - - systemd1, - systemd-vconsole-setup.service8, - loadkeys1, - setfont8, - locale.conf5, - systemd-localed.service8 - - - - -- cgit v1.2.3-54-g00ecf