systemd-userdbd.service

title: systemd-userdbd.service(8)

text:
# systemd-userdbd.service(8)

## NAME
systemd-userdbd.service, systemd-userdbd - JSON User/Group Record Query Multiplexer/NSS Compatibility

## SYNOPSIS
systemd-userdbd.service

/lib/systemd/systemd-userdbd

## DESCRIPTION
systemd-userdbd is a system service that multiplexes user/group lookups to all local services that provide JSON user/group record definitions to the system. In addition it synthesizes JSON user/group records from classic UNIX/glibc NSS user/group records in order to provide full backwards compatibility. It may also pick up statically defined JSON user/group records from drop-in files in /etc/userdb/, /run/userdb/, /run/host/userdb/ and /usr/lib/userdb/.

Most of systemd-userdbd's functionality is accessible through the userdbctl(1) command.

The user and group records this service provides access to follow the JSON User Records[1] and JSON Group Record[2] definitions. This service implements the User/Group Record Lookup API via Varlink[3], and multiplexes access other services implementing this API, too. It is thus both server and client of this API.

This service provides three distinct Varlink[4] services: io.systemd.Multiplexer provides a single, unified API for querying JSON user and group records. Internally it talks to all other user/group record services running on the system in parallel and forwards any information discovered. This simplifies clients substantially since they need to talk to a single service only instead of all of them in parallel. io.systemd.NameServiceSwitch provides compatibility with classic UNIX/glibc NSS user records, i.e. converts struct passwd and struct group records as acquired with APIs such as getpwnam(1) to JSON user/group records, thus hiding the differences between the services as much as possible. io.systemd.Dropin makes JSON user/group records from the aforementioned drop-in directories available.

## SEE ALSO
systemd(1), nss-systemd(8), userdbctl(1), systemd-homed.service(8)

## NOTES
1.

JSON User Records

https://systemd.io/USER_RECORD

2.

JSON Group Record

https://systemd.io/GROUP_RECORD

3.

User/Group Record Lookup API via Varlink

https://systemd.io/USER_GROUP_API

4.

Varlink

https://varlink.org/


systemd-vconsole-setup.service

package: systemd

title: systemd-vconsole-setup.service(8)

summary: Configure the virtual consoles

text:
# systemd-vconsole-setup.service(8)

## NAME
systemd-vconsole-setup.service, systemd-vconsole-setup - Configure the virtual consoles

## SYNOPSIS
systemd-vconsole-setup.service

/lib/systemd/systemd-vconsole-setup [TTY]

## DESCRIPTION
systemd-vconsole-setup sets up and configures either all virtual consoles, or — if the optional TTY parameter is provided — a specific one. When the system is booting up, it's called by systemd-udevd(8) during VT console subsystem initialization. Also, systemd-localed.service(8) invokes it as needed when language or console changes are made. Internally, this program calls loadkeys(1) and setfont(8).

Execute systemctl restart systemd-vconsole-setup.service in order to apply any manual changes made to /etc/vconsole.conf.

See vconsole.conf(5) for information about the configuration files and kernel command line options understood by this program.

## SEE ALSO
systemd(1), vconsole.conf(5), loadkeys(1), setfont(8), systemd-localed.service(8)


systemd-veritysetup-generator

title: systemd-veritysetup-generator(8)

text:
# systemd-veritysetup-generator(8)

## NAME
systemd-veritysetup-generator - Unit generator for verity protected block devices

## SYNOPSIS
/lib/systemd/system-generators/systemd-veritysetup-generator

## DESCRIPTION
systemd-veritysetup-generator is a generator that translates kernel command line options configuring verity protected block devices into native systemd units early at boot and when configuration of the system manager is reloaded. This will create systemd-veritysetup@.service(8) units as necessary.

Currently, only a single verity device may be set up with this generator, backing the root file system of the OS.

systemd-veritysetup-generator implements systemd.generator(7).

## KERNEL COMMAND LINE
systemd-veritysetup-generator understands the following kernel command line parameters:

systemd.verity=, rd.systemd.verity=

Takes a boolean argument. Defaults to "yes". If "no", disables the generator entirely. rd.systemd.verity= is honored only by the initial RAM disk (initrd) while systemd.verity= is honored by both the host system and the initrd.

roothash=

Takes a root hash value for the root file system. Expects a hash value formatted in hexadecimal characters of the appropriate length (i.e. most likely 256 bit/64 characters, or longer). If not specified via systemd.verity_root_data= and systemd.verity_root_hash=, the hash and data devices to use are automatically derived from the specified hash value. Specifically, the data partition device is looked for under a GPT partition UUID derived from the first 128bit of the root hash, the hash partition device is looked for under a GPT partition UUID derived from the last 128bit of the root hash. Hence it is usually sufficient to specify the root hash to boot from a verity protected root file system, as device paths are automatically determined from it — as long as the partition table is properly set up.

systemd.verity_root_data=, systemd.verity_root_hash=

These two settings take block device paths as arguments and may be used to explicitly configure the data partition and hash partition to use for setting up the verity protection for the root file system. If not specified, these paths are automatically derived from the roothash= argument (see above).

systemd.verity_root_options=

Takes a comma-separated list of dm-verity options. Expects the following options ignore-corruption, restart-on-corruption, ignore-zero-blocks, check-at-most-once, panic-on-corruption and root-hash-signature. See veritysetup(8) for more details.

## SEE ALSO
systemd(1), systemd-veritysetup@.service(8), veritysetup(8), systemd-fstab-generator(8)


systemd-veritysetup@.service

title: systemd-veritysetup@.service(8)

summary: Disk verity protection logic

text:
# systemd-veritysetup@.service(8)

## NAME
systemd-veritysetup@.service, systemd-veritysetup - Disk verity protection logic

## SYNOPSIS
systemd-veritysetup@.service

/lib/systemd/systemd-veritysetup

## DESCRIPTION
systemd-veritysetup@.service is a service responsible for setting up verity protection block devices. It should be instantiated for each device that requires verity protection.

At early boot and when the system manager configuration is reloaded kernel command line configuration for verity protected block devices is translated into systemd-veritysetup@.service units by systemd-veritysetup-generator(8).

systemd-veritysetup@.service calls systemd-veritysetup.

## COMMANDS
The following commands are understood by systemd-veritysetup:

attach volume datadevice hashdevice roothash [option...]

Create a block device volume using datadevice and hashdevice as the backing devices. roothash forms the root of the tree of hashes stored on hashdevice. See Kernel dm-verity[1] documentation for details.

detach volume

Detach (destroy) the block device volume.

help

Print short information about command syntax.

## SEE ALSO
systemd(1), systemd-veritysetup-generator(8), veritysetup(8)

## NOTES
1.

Kernel dm-verity

https://www.kernel.org/doc/html/latest/admin-guide/device-mapper/verity.html


systemd-volatile-root.service

title: systemd-volatile-root.service(8)

summary: Make the root file system volatile

text:
# systemd-volatile-root.service(8)

## NAME
systemd-volatile-root.service, systemd-volatile-root - Make the root file system volatile

## SYNOPSIS
systemd-volatile-root.service

/lib/systemd/systemd-volatile-root

## DESCRIPTION
systemd-volatile-root.service is a service that replaces the root directory with a volatile memory file system ("tmpfs"), mounting the original (non-volatile) /usr/ inside it read-only. This way, vendor data from /usr/ is available as usual, but all configuration data in /etc/, all state data in /var/ and all other resources stored directly under the root directory are reset on boot and lost at shutdown, enabling fully stateless systems.

This service is only enabled if full volatile mode is selected, for example by specifying "systemd.volatile=yes" on the kernel command line. This service runs only in the initial RAM disk ("initrd"), before the system transitions to the host's root directory. Note that this service is not used if "systemd.volatile=state" is used, as in that mode the root directory is non-volatile.

## SEE ALSO
systemd(1), systemd-fstab-generator(8), kernel-command-line(7)


systemd-xdg-autostart-generator

title: systemd-xdg-autostart-generator(8)

text:
# systemd-xdg-autostart-generator(8)

## NAME
systemd-xdg-autostart-generator - User unit generator for XDG autostart files

## SYNOPSIS
/lib/systemd/user-generators/systemd-xdg-autostart-generator

## DESCRIPTION
systemd-xdg-autostart-generator is a generator that creates .service units for XDG autostart[1] files. This permits desktop environments to delegate startup of these applications to systemd(1) .

Units created by systemd-xdg-autostart-generator can be started by the desktop environment using "xdg-desktop-autostart.target". See systemd.special(7) for more details.

systemd-xdg-autostart-generator implements systemd.generator(7).

## SEE ALSO
systemd(1), systemd.service(5), systemd.target(5)

## NOTES
1.

XDG autostart

https://specifications.freedesktop.org/autostart-spec/autostart-spec-latest.html


systemd-bless-boot-generator

package: systemd-boot-efi

title: systemd-bless-boot-generator(8)

summary: Pull systemd\-bless\-boot.service into the initial boot transaction when boot counting is in effect

text:
# systemd-bless-boot-generator(8)

## NAME
systemd-bless-boot-generator - Pull systemd-bless-boot.service into the initial boot transaction when boot counting is in effect

## SYNOPSIS
/lib/systemd/system-generators/systemd-bless-boot-generator

## DESCRIPTION
systemd-bless-boot-generator is a generator that pulls systemd-bless-boot.service into the initial boot transaction when boot counting, as implemented by systemd-boot(7), is enabled.

systemd-bless-boot-generator implements systemd.generator(7).

## SEE ALSO
systemd(1), systemd-bless-boot.service(8), systemd-boot(7)


systemd-bless-boot.service

title: systemd-bless-boot.service(8)

summary: Mark current boot process as successful

text:
# systemd-bless-boot.service(8)

## NAME
systemd-bless-boot.service, systemd-bless-boot - Mark current boot process as successful

## SYNOPSIS
systemd-bless-boot.service

/lib/systemd/system-bless-boot

## DESCRIPTION
systemd-bless-boot.service is a system service that marks the current boot process as successful. It's automatically pulled into the initial transaction when systemd-bless-boot-generator(8) detects that systemd-boot(7) style boot counting is used.

Internally, the service operates based on the LoaderBootCountPath EFI variable (of the vendor UUID 4a67b082-0a4c-41cf-b6c7-440b29bb8c4), which is passed from the boot loader to the OS. It contains a file system path (relative to the EFI system partition) of the Boot Loader Specification[1] compliant boot loader entry file or unified kernel image file that was used to boot up the system. systemd-bless-boot.service removes the two 'tries done' and 'tries left' numeric boot counters from the filename, which indicates to future invocations of the boot loader that the entry has completed booting successfully at least once. (This service will hence rename the boot loader entry file or unified kernel image file on the first successful boot.)

## OPTIONS
The /lib/systemd/system-bless-boot executable may also be invoked from the command line, taking one of the following command arguments:

status

The current status of the boot loader entry file or unified kernel image file is shown. This outputs one of "good", "bad", "indeterminate", "clean", depending on the state and previous invocations of the command. The string "indeterminate" is shown initially after boot, before it has been marked as "good" or "bad". The string "good" is shown after the boot was marked as "good" with the good command below, and "bad" conversely after the bad command was invoked. The string "clean" is returned when boot counting is currently not in effect. This command is implied if no command argument is specified.

good

When invoked, the current boot loader entry file or unified kernel image file will be marked as "good", executing the file rename operation described above. This command is intended to be invoked at the end of a successful boot. The systemd-bless-boot.service unit invokes this command.

bad

When called the 'tries left' counter in the boot loader entry file name or unified kernel image file name is set to zero, marking the boot loader entry or kernel image as "bad", so that the boot loader won't consider it anymore on future boots (at least as long as there are other entries available that are not marked "bad" yet). This command is normally not executed, but can be used to instantly put an end to the boot counting logic if a problem is detected and persistently mark the boot entry as bad.

indeterminate

This command undoes any marking of the current boot loader entry file or unified kernel image file as good or bad. This is implemented by renaming the boot loader entry file or unified kernel image file back to the path encoded in the LoaderBootCountPath EFI variable.

-h, --help

Print a short help text and exit.

--version

Print a short version string and exit.

## SEE ALSO
systemd(1), systemd-boot(7), systemd.special(7)

## NOTES
1.

Boot Loader Specification

https://systemd.io/BOOT_LOADER_SPECIFICATION


systemd-boot-check-no-failures.service

text:
# systemd-boot-check-no-failures.service(8)

## NAME
systemd-boot-check-no-failures.service, systemd-boot-check-no-failures - verify that the system booted up cleanly

## SYNOPSIS
systemd-boot-check-no-failures.service

/lib/systemd/system-boot-check-no-failures

## DESCRIPTION
systemd-boot-check-no-failures.service is a system service that checks whether the system booted up successfully. This service implements a very minimal test only: whether there are any failed units on the system. This service is disabled by default. When enabled, it is ordered before boot-complete.target, thus ensuring the target cannot be reached when the system booted up with failed services.

Note that due the simple nature of this check this service is probably not suitable for deployment in most scenarios. It is primarily useful only as example for developing more fine-grained checks to order before boot-complete.target.

## SEE ALSO
systemd(1), systemd.special(7)


systemd-boot-system-token.service

title: systemd-boot-system-token.service(8)

text:
# systemd-boot-system-token.service(8)

## NAME
systemd-boot-system-token.service - Generate an initial boot loader system token and random seed

## SYNOPSIS
systemd-boot-system-token.service

## DESCRIPTION
systemd-boot-system-token.service is a system service that automatically generates a 'system token' to store in an EFI variable in the system's NVRAM and a random seed to store on the EFI System Partition ESP on disk. The boot loader may then combine these two randomized data fields by cryptographic hashing, and pass it to the OS it boots as initialization seed for its entropy pool. The random seed stored in the ESP is refreshed on each reboot ensuring that multiple subsequent boots will boot with different seeds. The 'system token' is generated randomly once, and then persistently stored in the system's EFI variable storage.

The systemd-boot-system-token.service unit invokes the bootctl random-seed command, which updates the random seed in the ESP, and initializes the 'system token' if it's not initialized yet. The service is conditionalized so that it is run only when all of the below apply:

•A boot loader is used that implements the Boot Loader Interface[1] (which defines the 'system token' concept).

•Either a 'system token' was not set yet, or the boot loader has not passed the OS a random seed yet (and thus most likely has been missing the random seed file in the ESP).

•The system is not running in a VM environment. This case is explicitly excluded since on VM environments the ESP backing storage and EFI variable storage is typically not physically separated and hence booting the same OS image in multiple instances would replicate both, thus reusing the same random seed and 'system token' among all instances, which defeats its purpose. Note that it's still possible to use boot loader random seed provisioning in this mode, but the automatic logic implemented by this service has no effect then, and the user instead has to manually invoke the bootctl random-seed acknowledging these restrictions.

For further details see bootctl(1), regarding the command this service invokes.

## SEE ALSO
systemd(1), bootctl(1), systemd-boot(7)

## NOTES
1.

Boot Loader Interface

https://systemd.io/BOOT_LOADER_INTERFACE


systemd-importd.service

package: systemd-container

title: systemd-importd.service(8)

text:
# systemd-importd.service(8)

## NAME
systemd-importd.service, systemd-importd - VM and container image import and export service

## SYNOPSIS
systemd-importd.service

/lib/systemd/systemd-importd

## DESCRIPTION
systemd-importd is a system service that allows importing, exporting and downloading of system images suitable for running as VM or containers. It is a companion service for systemd-machined.service(8), and provides the implementation for machinectl(1)'s pull-raw, pull-tar, import-raw, import-tar, import-fs, export-raw, and export-tar commands.

See org.freedesktop.import1(5) and org.freedesktop.LogControl1(5) for a description of the D-Bus API.

## SEE ALSO
systemd(1), machinectl(1), systemd-machined.service(8), systemd-nspawn(1)


systemd-machined.service

title: systemd-machined.service(8)

text:
# systemd-machined.service(8)

## NAME
systemd-machined.service, systemd-machined - Virtual machine and container registration manager

## SYNOPSIS
systemd-machined.service

/lib/systemd/systemd-machined

## DESCRIPTION
systemd-machined is a system service that keeps track of locally running virtual machines and containers.

systemd-machined is useful for registering and keeping track of both OS containers (containers that share the host kernel but run a full init system of their own and behave in most regards like a full virtual operating system rather than just one virtualized app) and full virtual machines (virtualized hardware running normal operating systems and possibly different kernels).

systemd-machined should not be used for registering/keeping track of application sandbox containers. A machine in the context of systemd-machined is supposed to be an abstract term covering both OS containers and full virtual machines, but not application sandboxes.

Machines registered with machined are exposed in various ways in the system. For example:

•Tools like ps(1) will show to which machine a specific process belongs in a column of its own, and so will gnome-system-monitor[1] or systemd-cgls(1).

•systemd's various tools (systemctl(1), journalctl(1), loginctl(1), hostnamectl(1), timedatectl(1), localectl(1), machinectl(1), ...) support the -M switch to operate on local containers instead of the host system.

•systemctl list-machines will show the system state of all local containers, connecting to the container's init system for that.

•systemctl's --recursive switch has the effect of not only showing the locally running services, but recursively showing the services of all registered containers.

•The machinectl command provides access to a number of useful operations on registered containers, such as introspecting them, rebooting, shutting them down, and getting a login prompt on them.

•The sd-bus(3) library exposes the sd_bus_open_system_machine(3) call to connect to the system bus of any registered container.

•The nss-mymachines(8) module makes sure all registered containers can be resolved via normal glibc gethostbyname(3) or getaddrinfo(3) calls.

See systemd-nspawn(1) for some examples on how to run containers with OS tools.

If you are interested in writing a VM or container manager that makes use of machined, please have look at Writing Virtual Machine or Container Managers[2]. Also see the New Control Group Interfaces[3].

The daemon provides both a C library interface (which is shared with systemd-logind.service(8)) as well as a D-Bus interface. The library interface may be used to introspect and watch the state of virtual machines/containers. The bus interface provides the same but in addition may also be used to register or terminate machines. For more information please consult sd-login(3) and org.freedesktop.machine1(5) and org.freedesktop.LogControl1(5).

A small companion daemon systemd-importd.service(8) is also available, which implements importing, exporting, and downloading of container and VM images.

For each container registered with systemd-machined.service that employs user namespacing, users/groups are synthesized for the used UIDs/GIDs. These are made available to the system using the User/Group Record Lookup API via Varlink[4], and thus may be resolved with userdbctl(1) or the usual glibc NSS calls.

## SEE ALSO
systemd(1), machinectl(1), systemd-nspawn(1), nss-mymachines(8), systemd.special(7)

## NOTES
1.

gnome-system-monitor

https://help.gnome.org/users/gnome-system-monitor/

2.

Writing Virtual Machine or Container Managers

https://www.freedesktop.org/wiki/Software/systemd/writing-vm-managers

3.

New Control Group Interfaces

https://www.freedesktop.org/wiki/Software/systemd/ControlGroupInterface/

4.

User/Group Record Lookup API via Varlink

https://systemd.io/USER_GROUP_API


systemd-coredump

package: systemd-coredump

title: systemd-coredump(8)

summary: Acquire, save and process core dumps

text:
# systemd-coredump(8)

## NAME
systemd-coredump, systemd-coredump.socket, systemd-coredump@.service - Acquire, save and process core dumps

## SYNOPSIS
/lib/systemd/systemd-coredump

/lib/systemd/systemd-coredump --backtrace

systemd-coredump@.service

systemd-coredump.socket

## DESCRIPTION
systemd-coredump@.service is a system service to process core dumps. It will log a summary of the event to systemd-journald.service(8), including information about the process identifier, owner, the signal that killed the process, and the stack trace if possible. It may also save the core dump for later processing. See the "Information about the crashed process" section below.

The behavior of a specific program upon reception of a signal is governed by a few factors which are described in detail in core(5). In particular, the core dump will only be processed when the related resource limits are sufficient.

Core dumps can be written to the journal or saved as a file. In both cases, they can be retrieved for further processing, for example in gdb(1). See coredumpctl(1), in particular the list and debug verbs.

By default, systemd-coredump will log the core dump to the journal, including a backtrace if possible, and store the core dump (an image of the memory contents of the process) itself in an external file in /var/lib/systemd/coredump. These core dumps are deleted after a few days by default; see /usr/lib/tmpfiles.d/systemd.conf for details. Note that the removal of core files from the file system and the purging of journal entries are independent, and the core file may be present without the journal entry, and journal entries may point to since-removed core files. Some metadata is attached to core files in the form of extended attributes, so the core files are useful for some purposes even without the full metadata available in the journal entry.

### Invocation of systemd-coredump
The systemd-coredump executable does the actual work. It is invoked twice: once as the handler by the kernel, and the second time in the systemd-coredump@.service to actually write the data to the journal and process and save the core file.

When the kernel invokes systemd-coredump to handle a core dump, it runs in privileged mode, and will connect to the socket created by the systemd-coredump.socket unit, which in turn will spawn an unprivileged systemd-coredump@.service instance to process the core dump. Hence systemd-coredump.socket and systemd-coredump@.service are helper units which do the actual processing of core dumps and are subject to normal service management.

It is also possible to invoke systemd-coredump with --backtrace option. In this case, systemd-coredump expects a journal entry in the journal Journal Export Format[1] on standard input. The entry should contain a MESSAGE= field and any additional metadata fields the caller deems reasonable. systemd-coredump will append additional metadata fields in the same way it does for core dumps received from the kernel. In this mode, no core dump is stored in the journal.

## CONFIGURATION
For programs started by systemd, process resource limits can be set by directive LimitCORE=, see systemd.exec(5).

In order to be used by the kernel to handle core dumps, systemd-coredump must be configured in sysctl(8) parameter kernel.core_pattern. The syntax of this parameter is explained in core(5). systemd installs the file /lib/sysctl.d/50-coredump.conf which configures kernel.core_pattern accordingly. This file may be masked or overridden to use a different setting following normal sysctl.d(5) rules. If the sysctl configuration is modified, it must be updated in the kernel before it takes effect, see sysctl(8) and systemd-sysctl(8).

In order to be used in the --backtrace mode, an appropriate backtrace handler must be installed on the sender side. For example, in case of python(1), this means a sys.excepthook must be installed, see systemd-coredump-python[2].

The behavior of systemd-coredump itself is configured through the configuration file /etc/systemd/coredump.conf and corresponding snippets /etc/systemd/coredump.conf.d/*.conf, see coredump.conf(5). A new instance of systemd-coredump is invoked upon receiving every core dump. Therefore, changes in these files will take effect the next time a core dump is received.

Resources used by core dump files are restricted in two ways. Parameters like maximum size of acquired core dumps and files can be set in files /etc/systemd/coredump.conf and snippets mentioned above. In addition the storage time of core dump files is restricted by systemd-tmpfiles, corresponding settings are by default in /lib/tmpfiles.d/systemd.conf. The default is to delete core dumps after a few days; see the above file for details.

### Disabling coredump processing
To disable potentially resource-intensive processing by systemd-coredump, set

```
Storage=none ProcessSizeMax=0
```

in coredump.conf(5).

## INFORMATION ABOUT THE CRASHED PROCESS
coredumpctl(1) can be used to retrieve saved core dumps independently of their location, to display information, and to process them e.g. by passing to the GNU debugger (gdb).

Data stored in the journal can be also viewed with journalctl(1) as usual (or from any other process, using the sd-journal(3) API). The relevant messages have MESSAGE_ID=fc2e22bc6ee647b6b90729ab34a250b1:

```
$ journalctl MESSAGE_ID=fc2e22bc6ee647b6b90729ab34a250b1 -o verbose
...
MESSAGE_ID=fc2e22bc6ee647b6b90729ab34a250b1
COREDUMP_PID=552351
COREDUMP_UID=1000
COREDUMP_GID=1000
COREDUMP_SIGNAL_NAME=SIGSEGV
COREDUMP_SIGNAL=11
COREDUMP_TIMESTAMP=1614342930000000
COREDUMP_COMM=Web Content
COREDUMP_EXE=/usr/lib64/firefox/firefox
COREDUMP_USER_UNIT=app-gnome-firefox-552136.scope
COREDUMP_CMDLINE=/usr/lib64/firefox/firefox -contentproc -childID 5 -isForBrowser ...
COREDUMP_CGROUP=/user.slice/user-1000.slice/user@1000.service/app.slice/app-....scope
COREDUMP_FILENAME=/var/lib/systemd/coredump/core.Web....552351.....zst
...

```

The following fields are saved (if known) with the journal entry

COREDUMP_UID=, COREDUMP_PID=, COREDUMP_GID=

The process number (PID), owner user number (UID), and group number (GID) of the crashed process. When the crashed process was part of a container (or in a process or user namespace in general), those are the values as seen outside, in the namespace where systemd-coredump is running.

COREDUMP_TIMESTAMP=

The time of the crash as reported by the kernel (in µs since the epoch).

COREDUMP_RLIMIT=

The core file size soft resource limit, see getrlimit(2).

COREDUMP_UNIT=, COREDUMP_SLICE=

The system unit and slice names. When the crashed process was in container, those are the units names outside, in the main system manager.

COREDUMP_CGROUP=

Control group information in the format used in /proc/self/cgroup. On systems with the unified cgroup hierarchy, this is a single path prefixed with "0::", and multiple paths prefixed with controller numbers on legacy systems. When the crashed process was in a container, this is the full path, as seen outside of the container.

COREDUMP_OWNER_UID=, COREDUMP_USER_UNIT=

The numerical UID of the user owning the login session or systemd user unit of the crashed process, and the user manager unit. Both fields are only present for user processes. When the crashed process was in container, those are the values outside, in the main system.

COREDUMP_SIGNAL_NAME=, COREDUMP_SIGNAL=

The terminating signal name (with the "SIG" prefix [3]) and numerical value. (Both are included because signal numbers vary by architecture.)

COREDUMP_CWD=, COREDUMP_ROOT=

The current working directory and root directory of the crashed process. When the crashed process is in a container, those paths are relative to the root of the container's mount namespace.

COREDUMP_OPEN_FDS=

Information about open file descriptors, in the following format:

```
fd:/path/to/file
pos:     ...
flags:   ...
...
fd:/path/to/file
pos:     ...
flags:   ...
...

```

The first line contains the file descriptor number fd and the path, while subsequent lines show the contents of /proc/pid/fdinfo/fd.

COREDUMP_EXE=

The destination of the /proc/pid/exe symlink. When the crashed process is in a container, that path is relative to the root of the container's mount namespace.

COREDUMP_COMM=, COREDUMP_PROC_STATUS=, COREDUMP_PROC_MAPS=, COREDUMP_PROC_LIMITS=, COREDUMP_PROC_MOUNTINFO=, COREDUMP_ENVIRON=

Fields that map the per-process entries in the /proc/ filesystem: /proc/pid/comm (the command name associated with the process), /proc/pid/exe (the filename of the executed command), /proc/pid/status (various metadata about the process), /proc/pid/maps (memory regions visible to the process and their access permissions), /proc/pid/limits (the soft and hard resource limits), /proc/pid/mountinfo (mount points in the process's mount namespace), /proc/pid/environ (the environment block of the crashed process). See proc(5) for more information.

COREDUMP_HOSTNAME=

The system hostname. When the crashed process was in container, this is the container hostname.

COREDUMP_CONTAINER_CMDLINE=

For processes running in a container, the commandline of the process spawning the container (the first parent process with a different mount namespace).

COREDUMP=

When the core is stored in the journal, the core image itself.

COREDUMP_FILENAME=

When the core is stored externally, the path to the core file.

COREDUMP_TRUNCATED=

Set to "1" when the saved coredump was truncated. (A partial core image may still be processed by some tools, though obviously not all information is available.)

COREDUMP_PACKAGE_NAME=, COREDUMP_PACKAGE_VERSION=, COREDUMP_PACKAGE_JSON=

If the executable contained .package metadata ELF notes, they will be parsed and attached. The package and packageVersion of the 'main' ELF module (ie: the executable) will be appended individually. The JSON-formatted content of all modules will be appended as a single JSON object, each with the module name as the key. For more information about this metadata format and content, see the coredump metadata spec[4].

MESSAGE=

The message generated by systemd-coredump that includes the backtrace if it was successfully generated. When systemd-coredump is invoked with --backtrace, this field is provided by the caller.

Various other fields exist in the journal entry, but pertain to the logging process, i.e. systemd-coredump, not the crashed process. See systemd.journal-fields(7).

The following fields are saved (if known) with the external file listed in COREDUMP_FILENAME= as extended attributes:

user.coredump.pid, user.coredump.uid, user.coredump.gid, user.coredump.signal, user.coredump.timestamp, user.coredump.rlimit, user.coredump.hostname, user.coredump.comm, user.coredump.exe

Those are the same as COREDUMP_PID=, COREDUMP_UID=, COREDUMP_GID=, COREDUMP_SIGNAL=, COREDUMP_TIMESTAMP=, COREDUMP_RLIMIT=, COREDUMP_HOSTNAME=, COREDUMP_COMM=, and COREDUMP_EXE=, described above.

Those can be viewed using getfattr(1). For the core file described in the journal entry shown above:

```
$ getfattr --absolute-names -d /var/lib/systemd/coredump/core.Web....552351.....zst
# file: /var/lib/systemd/coredump/core.Web....552351.....zst
user.coredump.pid="552351"
user.coredump.uid="1000"
user.coredump.gid="1000"
user.coredump.signal="11"
user.coredump.timestamp="1614342930000000"
user.coredump.comm="Web Content"
user.coredump.exe="/usr/lib64/firefox/firefox"
...
```

## SEE ALSO
coredump.conf(5), coredumpctl(1), systemd-journald.service(8), systemd-tmpfiles(8), core(5), sysctl.d(5), systemd-sysctl.service(8).

## NOTES
1.

Journal Export Format

https://systemd.io/JOURNAL_EXPORT_FORMATS#journal-export-format

2.

systemd-coredump-python

https://github.com/systemd/systemd-coredump-python

3.

kill(1) expects signal names without the prefix; kill(2) uses the prefix; all systemd tools accept signal names both with and without the prefix.

4.

the coredump metadata spec

https://systemd.io/COREDUMP_PACKAGE_METADATA/


systemd-homed.service

package: systemd-homed

title: systemd-homed.service(8)

summary: Home Area/User Account Manager

text:
# systemd-homed.service(8)

## NAME
systemd-homed.service, systemd-homed - Home Area/User Account Manager

## SYNOPSIS
systemd-homed.service

/lib/systemd/systemd-homed

## DESCRIPTION
systemd-homed is a system service that may be used to create, remove, change or inspect home areas (directories and network mounts and real or loopback block devices with a filesystem, optionally encrypted).

Most of systemd-homed's functionality is accessible through the homectl(1) command.

See the Home Directories[1] documentation for details about the format and design of home areas managed by systemd-homed.service.

Each home directory managed by systemd-homed.service synthesizes a local user and group. These are made available to the system using the User/Group Record Lookup API via Varlink[2], and thus may be browsed with userdbctl(1).

## KEY MANAGEMENT
User records are cryptographically signed with a public/private key pair (the signature is part of the JSON record itself). For a user to be permitted to log in locally the public key matching the signature of their user record must be installed. For a user record to be modified locally the private key matching the signature must be installed locally, too. The keys are stored in the /var/lib/systemd/home/ directory:

/var/lib/systemd/home/local.private

The private key of the public/private key pair used for local records. Currently, only a single such key may be installed.

/var/lib/systemd/home/local.public

The public key of the public/private key pair used for local records. Currently, only a single such key may be installed.

/var/lib/systemd/home/*.public

Additional public keys. Any users whose user records are signed with any of these keys are permitted to log in locally. An arbitrary number of keys may be installed this way.

All key files listed above are in PEM format.

In order to migrate a home directory from a host "foobar" to another host "quux" it is hence sufficient to copy /var/lib/systemd/home/local.public from the host "foobar" to "quux", maybe calling the file on the destination /var/lib/systemd/home/foobar.public, reflecting the origin of the key. If the user record should be modifiable on "quux" the pair /var/lib/systemd/home/local.public and /var/lib/systemd/home/local.private need to be copied from "foobar" to "quux", and placed under the identical paths there, as currently only a single private key is supported per host. Note of course that the latter means that user records generated/signed before the key pair is copied in, lose their validity.

## SEE ALSO
systemd(1), homed.conf(5), homectl(1), pam_systemd_home(8), userdbctl(1), org.freedesktop.home1(5)

## NOTES
1.

Home Directories

https://systemd.io/HOME_DIRECTORY

2.

User/Group Record Lookup API via Varlink

https://systemd.io/USER_GROUP_API


systemd-journal-gatewayd.service

package: systemd-journal-remote

title: systemd-journal-gatewayd.service(8)

summary: HTTP server for journal events

text:
# systemd-journal-gatewayd.service(8)

## NAME
systemd-journal-gatewayd.service, systemd-journal-gatewayd.socket, systemd-journal-gatewayd - HTTP server for journal events

## SYNOPSIS
systemd-journal-gatewayd.service

systemd-journal-gatewayd.socket

/lib/systemd/systemd-journal-gatewayd [OPTIONS...]

## DESCRIPTION
systemd-journal-gatewayd serves journal events over the network. Clients must connect using HTTP. The server listens on port 19531 by default. If --cert= is specified, the server expects HTTPS connections.

The program is started by systemd(1) and expects to receive a single socket. Use systemctl start systemd-journal-gatewayd.socket to start the service, and systemctl enable systemd-journal-gatewayd.socket to have it started on boot.

## OPTIONS
The following options are understood:

--cert=

Specify the path to a file or AF_UNIX stream socket to read the server certificate from. The certificate must be in PEM format. This option switches systemd-journal-gatewayd into HTTPS mode and must be used together with --key=.

--key=

Specify the path to a file or AF_UNIX stream socket to read the secret server key corresponding to the certificate specified with --cert= from. The key must be in PEM format.

--trust=

Specify the path to a file or AF_UNIX stream socket to read a CA certificate from. The certificate must be in PEM format.

--system, --user

Limit served entries to entries from system services and the kernel, or to entries from services of current user. This has the same meaning as --system and --user options for journalctl(1). If neither is specified, all accessible entries are served.

-m, --merge

Serve entries interleaved from all available journals, including other machines. This has the same meaning as --merge option for journalctl(1).

-D DIR, --directory=DIR

Takes a directory path as argument. If specified, systemd-journal-gatewayd will serve the specified journal directory DIR instead of the default runtime and system journal paths.

--file=GLOB

Takes a file glob as an argument. Serve entries from the specified journal files matching GLOB instead of the default runtime and system journal paths. May be specified multiple times, in which case files will be suitably interleaved. This has the same meaning as --file= option for journalctl(1).

-h, --help

Print a short help text and exit.

--version

Print a short version string and exit.

## SUPPORTED URLS
The following URLs are recognized:

/browse

Interactive browsing.

/entries[?option1&option2=value...]

Retrieval of events in various formats. The Accept: part of the HTTP header determines the format. Supported values are described below.

The Range: part of the HTTP header determines the range of events returned. Supported values are described below.

GET parameters can be used to modify what events are returned. Supported parameters are described below.

/machine

Return a JSON structure describing the machine. Example:

```
{ "machine_id" : "8cf7ed9d451ea194b77a9f118f3dc446",

  "boot_id" : "3d3c9efaf556496a9b04259ee35df7f7",

  "hostname" : "fedora",

  "os_pretty_name" : "Fedora 19 (Rawhide)",

  "virtualization" : "kvm",

  ...}
```

/fields/FIELD_NAME

Return a list of values of this field present in the logs.

## ACCEPT HEADER
Accept: format

Recognized formats:

text/plain

The default. Plaintext syslog-like output, one line per journal entry (like journalctl --output short).

application/json

Entries are formatted as JSON data structures, one per line (like journalctl --output json). See Journal JSON Format[1] for more information.

text/event-stream

Entries are formatted as JSON data structures, wrapped in a format suitable for Server-Sent Events[2] (like journalctl --output json-sse).

application/vnd.fdo.journal

Entries are serialized into a binary (but mostly text-based) stream suitable for backups and network transfer (like journalctl --output export). See Journal Export Format[3] for more information.

## RANGE HEADER
Range: entries=cursor[[:num_skip]:num_entries]

where cursor is a cursor string, num_skip is an integer, num_entries is an unsigned integer.

Range defaults to all available events.

## URL GET PARAMETERS
Following parameters can be used as part of the URL:

follow

wait for new events (like journalctl --follow, except that the number of events returned is not limited).

discrete

Test that the specified cursor refers to an entry in the journal. Returns just this entry.

boot

Limit events to the current boot of the system (like journalctl -b).

KEY=match

Match journal fields. See systemd.journal-fields(7).

## EXAMPLES
Retrieve events from this boot from local journal in Journal Export Format[3]:

```
curl --silent -H'Accept: application/vnd.fdo.journal' \

       'http://localhost:19531/entries?boot'
```

Listen for core dumps:

```
curl 'http://localhost:19531/entries?follow&MESSAGE_ID=fc2e22bc6ee647b6b90729ab34a250b1'
```

## SEE ALSO
systemd(1), journalctl(1), systemd.journal-fields(7), systemd-journald.service(8), systemd-journal-remote.service(8), systemd-journal-upload.service(8)

## NOTES
1.

Journal JSON Format

https://systemd.io/JOURNAL_EXPORT_FORMATS#journal-json-format

2.

Server-Sent Events

https://developer.mozilla.org/en-US/docs/Server-sent_events/Using_server-sent_events

3.

Journal Export Format

https://systemd.io/JOURNAL_EXPORT_FORMATS#journal-export-format


systemd-journal-remote.service

title: systemd-journal-remote.service(8)

text:
# systemd-journal-remote.service(8)

## NAME
systemd-journal-remote.service, systemd-journal-remote.socket, systemd-journal-remote - Receive journal messages over the network

## SYNOPSIS
systemd-journal-remote.service

systemd-journal-remote.socket

/lib/systemd/systemd-journal-remote [OPTIONS...] [-o/--output=DIR|FILE] [SOURCES...]

## DESCRIPTION
systemd-journal-remote is a command to receive serialized journal events and store them to journal files. Input streams are in the Journal Export Format[1], i.e. like the output from journalctl --output=export. For transport over the network, this serialized stream is usually carried over an HTTPS connection.

systemd-journal-remote.service is a system service that uses systemd-journal-remote to listen for connections. systemd-journal-remote.socket configures the network address that systemd-journal-remote.service listens on. By default this is port 19532. What connections are accepted and how the received data is stored can be configured through the journal-remote.conf(5) configuration file.

## SOURCES
Sources can be either "active" (systemd-journal-remote requests and pulls the data), or "passive" (systemd-journal-remote waits for a connection and then receives events pushed by the other side).

systemd-journal-remote can read more than one event stream at a time. They will be interleaved in the output file. In case of "active" connections, each "source" is one stream, and in case of "passive" connections, each connection can result in a separate stream. Sockets can be configured in "accept" mode (i.e. only one connection), or "listen" mode (i.e. multiple connections, each resulting in a stream).

When there are no more connections, and no more can be created (there are no listening sockets), then systemd-journal-remote will exit.

Active sources can be specified in the following ways:

[SOURCES...]

When - is given as a positional argument, events will be read from standard input. Other positional arguments will be treated as filenames to open and read from.

--url=ADDRESS

With the --url=ADDRESS option, events will be retrieved using HTTP from ADDRESS. This URL should refer to the root of a remote systemd-journal-gatewayd(8) instance, e.g. http://some.host:19531/ or https://some.host:19531/.

--getter='PROG [OPTIONS...]'

Program to invoke to retrieve data. The journal event stream must be generated on standard output. Examples:

```
--getter='curl "-HAccept: application/vnd.fdo.journal" https://some.host:19531/'
```

```
--getter='wget --header="Accept: application/vnd.fdo.journal" -O- https://some.host:19531/'
```

Passive sources can be specified in the following ways:

--listen-raw=ADDRESS

ADDRESS must be an address suitable for ListenStream= (cf. systemd.socket(5)). systemd-journal-remote will listen on this socket for connections. Each connection is expected to be a stream of journal events.

--listen-http=ADDRESS, --listen-https=ADDRESS

ADDRESS must be either a negative integer, in which case it will be interpreted as the (negated) file descriptor number, or an address suitable for ListenStream= (c.f. systemd.socket(5)). In the first case, the server listens on port 19532 by default, and the matching file descriptor must be inherited through $LISTEN_FDS/$LISTEN_PID. In the second case, an HTTP or HTTPS server will be spawned on this port, respectively for --listen-http= and --listen-https=. Currently, only POST requests to /upload with "Content-Type: application/vnd.fdo.journal" are supported.

$LISTEN_FDS

systemd-journal-remote supports the $LISTEN_FDS/$LISTEN_PID protocol. Open sockets inherited through socket activation behave like those opened with --listen-raw= described above, unless they are specified as an argument in --listen-http=-n or --listen-https=-n above. In the latter case, an HTTP or HTTPS server will be spawned using this descriptor and connections must be made over the HTTP protocol.

--key=

Takes a path to a SSL secret key file in PEM format. Defaults to /etc/pki/tls/private/journal-remote.pem. This option can be used with --listen-https=. If the path refers to an AF_UNIX stream socket in the file system a connection is made to it and the key read from it.

--cert=

Takes a path to a SSL certificate file in PEM format. Defaults to /etc/pki/tls/certs/journal-remote.pem. This option can be used with --listen-https=. If the path refers to an AF_UNIX stream socket in the file system a connection is made to it and the certificate read from it.

--trust=

Takes a path to a SSL CA certificate file in PEM format, or all. If all is set, then certificate checking will be disabled. Defaults to /etc/pki/tls/ca/trusted.pem. This option can be used with --listen-https=. If the path refers to an AF_UNIX stream socket in the file system a connection is made to it and the certificate read from it.

--gnutls-log=

Takes a comma separated list of gnutls logging categories. This option can be used with --listen-http= or --listen-https=.

## SINKS
The location of the output journal can be specified with -o or --output=.

--output=FILE

Will write to this journal file. The filename must end with .journal. The file will be created if it does not exist. If necessary (journal file full, or corrupted), the file will be renamed following normal journald rules and a new journal file will be created in its stead.

--output=DIR

Will create journal files underneath directory DIR. The directory must exist. If necessary (journal files over size, or corrupted), journal files will be rotated following normal journald rules. Names of files underneath DIR will be generated using the rules described below.

If --output= is not used, the output directory /var/log/journal/remote/ will be used. In case the output file is not specified, journal files will be created underneath the selected directory. Files will be called remote-hostname.journal, where the hostname part is the escaped hostname of the source endpoint of the connection, or the numerical address if the hostname cannot be determined.

In the case that "active" sources are given by the positional arguments or --getter= option, the output file name must always be given explicitly.

## OPTIONS
The following options are understood:

--split-mode

One of none or host. For the first, only one output journal file is used. For the latter, a separate output file is used, based on the hostname of the other endpoint of a connection. In the case that "active" sources are given by the positional arguments or --getter= option, the output file name must always be given explicitly and only none is allowed.

--compress [BOOL]

If this is set to "yes" then compress the data in the journal using XZ. The default is "yes".

--seal [BOOL]

If this is set to "yes" then periodically sign the data in the journal using Forward Secure Sealing. The default is "no".

-h, --help

Print a short help text and exit.

--version

Print a short version string and exit.

## EXAMPLES
Copy local journal events to a different journal directory:

```
journalctl -o export | systemd-journal-remote -o /tmp/dir/foo.journal -

```

Retrieve all available events from a remote systemd-journal-gatewayd(8) instance and store them in /var/log/journal/remote/remote-some.host.journal:

```
systemd-journal-remote --url http://some.host:19531/

```

Retrieve current boot events and wait for new events from a remote systemd-journal-gatewayd(8) instance, and store them in /var/log/journal/remote/remote-some.host.journal:

```
systemd-journal-remote --url http://some.host:19531/entries?boot&follow

```

## SEE ALSO
journal-remote.conf(5), journalctl(1), systemd-journal-gatewayd.service(8), systemd-journal-upload.service(8), systemd-journald.service(8)

## NOTES
1.

Journal Export Format

https://systemd.io/JOURNAL_EXPORT_FORMATS#journal-export-format


systemd-journal-upload.service

title: systemd-journal-upload.service(8)

summary: Send journal messages over the network

text:
# systemd-journal-upload.service(8)

## NAME
systemd-journal-upload.service, systemd-journal-upload - Send journal messages over the network

## SYNOPSIS
systemd-journal-upload.service

/lib/systemd/systemd-journal-upload [OPTIONS...] [-u/--url=URL] [SOURCES...]

## DESCRIPTION
systemd-journal-upload will upload journal entries to the URL specified with --url=. This program reads journal entries from one or more journal files, similarly to journalctl(1). Unless limited by one of the options specified below, all journal entries accessible to the user the program is running as will be uploaded, and then the program will wait and send new entries as they become available.

systemd-journal-upload.service is a system service that uses systemd-journal-upload to upload journal entries to a server. It uses the configuration in journal-upload.conf(5). At least the URL= option must be specified.

## OPTIONS
-u, --url=[https://]URL[:PORT], --url=[http://]URL[:PORT]

Upload to the specified address. URL may specify either just the hostname or both the protocol and hostname. https is the default. The port number may be specified after a colon (":"), otherwise 19532 will be used by default.

--system, --user

Limit uploaded entries to entries from system services and the kernel, or to entries from services of current user. This has the same meaning as --system and --user options for journalctl(1). If neither is specified, all accessible entries are uploaded.

-m, --merge

Upload entries interleaved from all available journals, including other machines. This has the same meaning as --merge option for journalctl(1).

-D, --directory=DIR

Takes a directory path as argument. Upload entries from the specified journal directory DIR instead of the default runtime and system journal paths. This has the same meaning as --directory= option for journalctl(1).

--file=GLOB

Takes a file glob as an argument. Upload entries from the specified journal files matching GLOB instead of the default runtime and system journal paths. May be specified multiple times, in which case files will be suitably interleaved. This has the same meaning as --file= option for journalctl(1).

--cursor=

Upload entries from the location in the journal specified by the passed cursor. This has the same meaning as --cursor= option for journalctl(1).

--after-cursor=

Upload entries from the location in the journal after the location specified by the this cursor. This has the same meaning as --after-cursor= option for journalctl(1).

--save-state[=PATH]

Upload entries from the location in the journal after the location specified by the cursor saved in file at PATH (/var/lib/systemd/journal-upload/state by default). After an entry is successfully uploaded, update this file with the cursor of that entry.

--follow[=BOOL]

If set to yes, then systemd-journal-upload waits for input.

--key=

Takes a path to a SSL key file in PEM format, or -. If - is set, then client certificate authentication checking will be disabled. Defaults to /etc/pki/tls/private/journal-upload.pem.

--cert=

Takes a path to a SSL certificate file in PEM format, or -. If - is set, then client certificate authentication checking will be disabled. Defaults to /etc/pki/tls/certs/journal-upload.pem.

--trust=

Takes a path to a SSL CA certificate file in PEM format, or -/all. If -/all is set, then certificate checking will be disabled. Defaults to /etc/pki/tls/ca/trusted.pem.

-h, --help

Print a short help text and exit.

--version

Print a short version string and exit.

## EXIT STATUS
On success, 0 is returned; otherwise, a non-zero failure code is returned.

## EXAMPLES
Example 1. Setting up certificates for authentication

Certificates signed by a trusted authority are used to verify that the server to which messages are uploaded is legitimate, and vice versa, that the client is trusted.

A suitable set of certificates can be generated with openssl. Note, 2048 bits of key length is minimally recommended to use for security reasons:

```
openssl req -newkey rsa:2048 -days 3650 -x509 -nodes \

      -out ca.pem -keyout ca.key -subj '/CN=Certificate authority/'
cat >ca.conf <<EOF
[ ca ]
default_ca = this
[ this ]
new_certs_dir = .
certificate = ca.pem
database = ./index
private_key = ca.key
serial = ./serial
default_days = 3650
default_md = default
policy = policy_anything
[ policy_anything ]
countryName             = optional
stateOrProvinceName     = optional
localityName            = optional
organizationName        = optional
organizationalUnitName  = optional
commonName              = supplied
emailAddress            = optional
EOF
touch index
echo 0001 >serial
SERVER=server
CLIENT=client
openssl req -newkey rsa:2048 -nodes -out $SERVER.csr -keyout $SERVER.key -subj "/CN=$SERVER/"
openssl ca -batch -config ca.conf -notext -in $SERVER.csr -out $SERVER.pem
openssl req -newkey rsa:2048 -nodes -out $CLIENT.csr -keyout $CLIENT.key -subj "/CN=$CLIENT/"
openssl ca -batch -config ca.conf -notext -in $CLIENT.csr -out $CLIENT.pem
```

Generated files ca.pem, server.pem, and server.key should be installed on server, and ca.pem, client.pem, and client.key on the client. The location of those files can be specified using TrustedCertificateFile=, ServerCertificateFile=, and ServerKeyFile= in /etc/systemd/journal-remote.conf and /etc/systemd/journal-upload.conf, respectively. The default locations can be queried by using systemd-journal-remote --help and systemd-journal-upload --help.

## SEE ALSO
journal-upload.conf(5), systemd-journal-remote.service(8), journalctl(1), systemd-journald.service(8), systemd-journal-gatewayd.service(8)


systemd-network-generator.service

package: systemd-networkd

title: systemd-network-generator.service(8)

text:
# systemd-network-generator.service(8)

## NAME
systemd-network-generator.service, systemd-network-generator - Generate network configuration from the kernel command line

## SYNOPSIS
systemd-network-generator.service

/lib/systemd/systemd-network-generator

## DESCRIPTION
systemd-network-generator.service is a system service that translates ip= and the related settings on the kernel command line (see below) into systemd.network(5), systemd.netdev(5), and systemd.link(5) configuration files understood by systemd-networkd.service(8) and systemd-udevd.service(8).

Files are generated in /run/systemd/network/.

## KERNEL COMMAND LINE OPTIONS
This tool understands the following options:

ip=, rd.route=, rd.peerdns=

— translated into systemd.network(5) files.

ifname=

— translated into systemd.link(5) files.

vlan=, bond=, bridge=, bootdev=

— translated into systemd.netdev(5) files.

See dracut.kernel(7) for option syntax and details.

## SEE ALSO
systemd(1), systemd-networkd.service(8), dracut(8)


systemd-networkd-wait-online.service

title: systemd-networkd-wait-online.service(8)

summary: Wait for network to come online

text:
# systemd-networkd-wait-online.service(8)

## NAME
systemd-networkd-wait-online.service, systemd-networkd-wait-online - Wait for network to come online

## SYNOPSIS
systemd-networkd-wait-online.service

/lib/systemd/systemd-networkd-wait-online

## DESCRIPTION
systemd-networkd-wait-online is a oneshot system service (see systemd.service(5)), that waits for the network to be configured. By default, it will wait for all links it is aware of and which are managed by systemd-networkd.service(8) to be fully configured or failed, and for at least one link to be online. Here, online means that the link's operational state is equal or higher than "degraded". The threshold can be configured by --operational-state= option.

## OPTIONS
The following options are understood:

-i INTERFACE[:MIN_OPERSTATE[:MAX_OPERSTATE]], --interface=INTERFACE[:MIN_OPERSTATE[:MAX_OPERSTATE]]

Network interface to wait for before deciding if the system is online. This is useful when a system has several interfaces which will be configured, but a particular one is necessary to access some network resources. When used, all other interfaces are ignored. This option may be used more than once to wait for multiple network interfaces. When this option is specified multiple times, then systemd-networkd-wait-online waits for all specified interfaces to be online. Optionally, required minimum and maximum operational states can be specified after a colon ":". Please see networkctl(1) for possible operational states. If the operational state is not specified here, then the value from RequiredForOnline= in the corresponding .network file is used if present, and "degraded" otherwise.

--ignore=INTERFACE

Network interfaces to be ignored when deciding if the system is online. By default, only the loopback interface is ignored. This option may be used more than once to ignore multiple network interfaces.

-o MIN_OPERSTATE[:MAX_OPERSTATE], --operational-state=MIN_OPERSTATE[:MAX_OPERSTATE]

Takes a minimum operational state and an optional maximum operational state. Please see networkctl(1) for possible operational states. If set, the specified value overrides RequiredForOnline= settings in .network files. But this does not override operational states specified in --interface= option.

-4, --ipv4

Waiting for an IPv4 address of each network interface to be configured. If this option is specified with --any, then systemd-networkd-wait-online exits with success when at least one interface becomes online and has an IPv4 address. The option is applied only for the operational state "degraded" or above. If neither --ipv4 nor --ipv6 is specified, then the value from RequiredFamilyForOnline= in the corresponding .network file is used if present.

-6, --ipv6

Waiting for an IPv6 address of each network interface to be configured. If this option is specified with --any, then systemd-networkd-wait-online exits with success when at least one interface becomes online and has an IPv6 address. The option is applied only for the operational state "degraded" or above. If neither --ipv4 nor --ipv6 is specified, then the value from RequiredFamilyForOnline= in the corresponding .network file is used if present.

--any

Even if several interfaces are in configuring state, systemd-networkd-wait-online exits with success when at least one interface becomes online. When this option is specified with --interface=, then systemd-networkd-wait-online waits for one of the specified interfaces to be online. This option is useful when some interfaces may not have carrier on boot.

--timeout=SECS

Fail the service if the network is not online by the time the timeout elapses. A timeout of 0 disables the timeout. Defaults to 120 seconds.

-q, --quiet

Suppress log messages.

-h, --help

Print a short help text and exit.

--version

Print a short version string and exit.

## SEE ALSO
systemd(1), systemd.service(5), systemd-networkd.service(8), networkctl(1)


systemd-networkd.service

title: systemd-networkd.service(8)

summary: Network manager

text:
# systemd-networkd.service(8)

## NAME
systemd-networkd.service, systemd-networkd - Network manager

## SYNOPSIS
systemd-networkd.service

/lib/systemd/systemd-networkd

## DESCRIPTION
systemd-networkd is a system service that manages networks. It detects and configures network devices as they appear, as well as creating virtual network devices.

To configure low-level link settings independently of networks, see systemd.link(5).

systemd-networkd will create network devices based on the configuration in systemd.netdev(5) files, respecting the [Match] sections in those files.

systemd-networkd will manage network addresses and routes for any link for which it finds a .network file with an appropriate [Match] section, see systemd.network(5). For those links, it will flush existing network addresses and routes when bringing up the device. Any links not matched by one of the .network files will be ignored. It is also possible to explicitly tell systemd-networkd to ignore a link by using Unmanaged=yes option, see systemd.network(5).

When systemd-networkd exits, it generally leaves existing network devices and configuration intact. This makes it possible to transition from the initramfs and to restart the service without breaking connectivity. This also means that when configuration is updated and systemd-networkd is restarted, netdev interfaces for which configuration was removed will not be dropped, and may need to be cleaned up manually.

systemd-networkd may be introspected and controlled at runtime using networkctl(1).

## CONFIGURATION FILES
The configuration files are read from the files located in the system network directory /lib/systemd/network, the volatile runtime network directory /run/systemd/network and the local administration network directory /etc/systemd/network.

Networks are configured in .network files, see systemd.network(5), and virtual network devices are configured in .netdev files, see systemd.netdev(5).

## SEE ALSO
networkctl(1), systemd(1), systemd.link(5), systemd.network(5), systemd.netdev(5), systemd-networkd-wait-online.service(8), systemd-network-generator.service(8)


systemd-resolved.service

title: systemd-resolved.service(8)

summary: Network Name Resolution manager

text:
# systemd-resolved.service(8)

## NAME
systemd-resolved.service, systemd-resolved - Network Name Resolution manager

## SYNOPSIS
systemd-resolved.service

/lib/systemd/systemd-resolved

## DESCRIPTION
systemd-resolved is a system service that provides network name resolution to local applications. It implements a caching and validating DNS/DNSSEC stub resolver, as well as an LLMNR and MulticastDNS resolver and responder. Local applications may submit network name resolution requests via three interfaces:

•The native, fully-featured API systemd-resolved exposes on the bus, see org.freedesktop.resolve1(5) and org.freedesktop.LogControl1(5) for details. Usage of this API is generally recommended to clients as it is asynchronous and fully featured (for example, properly returns DNSSEC validation status and interface scope for addresses as necessary for supporting link-local networking).

•The glibc getaddrinfo(3) API as defined by RFC3493[1] and its related resolver functions, including gethostbyname(3). This API is widely supported, including beyond the Linux platform. In its current form it does not expose DNSSEC validation status information however, and is synchronous only. This API is backed by the glibc Name Service Switch (nss(5)). Usage of the glibc NSS module nss-resolve(8) is required in order to allow glibc's NSS resolver functions to resolve hostnames via systemd-resolved.

•Additionally, systemd-resolved provides a local DNS stub listener on IP address 127.0.0.53 on the local loopback interface. Programs issuing DNS requests directly, bypassing any local API may be directed to this stub, in order to connect them to systemd-resolved. Note however that it is strongly recommended that local programs use the glibc NSS or bus APIs instead (as described above), as various network resolution concepts (such as link-local addressing, or LLMNR Unicode domains) cannot be mapped to the unicast DNS protocol.

The DNS servers contacted are determined from the global settings in /etc/systemd/resolved.conf, the per-link static settings in /etc/systemd/network/*.network files (in case systemd-networkd.service(8) is used), the per-link dynamic settings received over DHCP, information provided via resolvectl(1), and any DNS server information made available by other system services. See resolved.conf(5) and systemd.network(5) for details about systemd's own configuration files for DNS servers. To improve compatibility, /etc/resolv.conf is read in order to discover configured system DNS servers, but only if it is not a symlink to /run/systemd/resolve/stub-resolv.conf, /lib/systemd/resolv.conf or /run/systemd/resolve/resolv.conf (see below).

## SYNTHETIC RECORDS
systemd-resolved synthesizes DNS resource records (RRs) for the following cases:

•The local, configured hostname is resolved to all locally configured IP addresses ordered by their scope, or — if none are configured — the IPv4 address 127.0.0.2 (which is on the local loopback interface) and the IPv6 address ::1 (which is the local host).

•The hostnames "localhost" and "localhost.localdomain" as well as any hostname ending in ".localhost" or ".localhost.localdomain" are resolved to the IP addresses 127.0.0.1 and ::1.

•The hostname "_gateway" is resolved to all current default routing gateway addresses, ordered by their metric. This assigns a stable hostname to the current gateway, useful for referencing it independently of the current network configuration state.

•The hostname "_outbound" is resolved to the local IPv4 and IPv6 addresses that are most likely used for communication with other hosts. This is determined by requesting a routing decision to the configured default gateways from the kernel and then using the local IP addresses selected by this decision. This hostname is only available if there is at least one local default gateway configured. This assigns a stable hostname to the local outbound IP addresses, useful for referencing them independently of the current network configuration state.

•The mappings defined in /etc/hosts are resolved to their configured addresses and back, but they will not affect lookups for non-address types (like MX). Support for /etc/hosts may be disabled with ReadEtcHosts=no, see resolved.conf(5).

## PROTOCOLS AND ROUTING
The lookup requests that systemd-resolved.service receives are routed to the available DNS servers, LLMNR, and MulticastDNS interfaces according to the following rules:

•Names for which synthetic records are generated (the local hostname, "localhost" and "localdomain", local gateway, as listed in the previous section) and addresses configured in /etc/hosts are never routed to the network and a reply is sent immediately.

•Single-label names are resolved using LLMNR on all local interfaces where LLMNR is enabled. Lookups for IPv4 addresses are only sent via LLMNR on IPv4, and lookups for IPv6 addresses are only sent via LLMNR on IPv6. Note that lookups for single-label synthesized names are not routed to LLMNR, MulticastDNS or unicast DNS.

•Queries for the address records (A and AAAA) of single-label non-synthesized names are resolved via unicast DNS using search domains. For any interface which defines search domains, such look-ups are routed to the servers defined for that interface, suffixed with each of those search domains. When global search domains are defined, such look-ups are routed to the global servers. For each search domain, queries are performed by suffixing the name with each of the search domains in turn. Additionally, lookup of single-label names via unicast DNS may be enabled with the ResolveUnicastSingleLabel=yes setting. The details of which servers are queried and how the final reply is chosen are described below. Note that this means that address queries for single-label names are never sent out to remote DNS servers by default, and resolution is only possible if search domains are defined.

•Multi-label names with the domain suffix ".local" are resolved using MulticastDNS on all local interfaces where MulticastDNS is enabled. As with LLMNR, IPv4 address lookups are sent via IPv4 and IPv6 address lookups are sent via IPv6.

•Queries for multi-label names are routed via unicast DNS on local interfaces that have a DNS server configured, plus the globally configured DNS servers if there are any. Which interfaces are used is determined by the routing logic based on search and route-only domains, described below. Note that by default, lookups for domains with the ".local" suffix are not routed to DNS servers, unless the domain is specified explicitly as routing or search domain for the DNS server and interface. This means that on networks where the ".local" domain is defined in a site-specific DNS server, explicit search or routing domains need to be configured to make lookups work within this DNS domain. Note that these days, it's generally recommended to avoid defining ".local" in a DNS server, as RFC6762[2] reserves this domain for exclusive MulticastDNS use.

•Address lookups (reverse lookups) are routed similarly to multi-label names, with the exception that addresses from the link-local address range are never routed to unicast DNS and are only resolved using LLMNR and MulticastDNS (when enabled).

If lookups are routed to multiple interfaces, the first successful response is returned (thus effectively merging the lookup zones on all matching interfaces). If the lookup failed on all interfaces, the last failing response is returned.

Routing of lookups is determined by the per-interface routing domains (search and route-only) and global search domains. See systemd.network(5) and resolvectl(1) for a description how those settings are set dynamically and the discussion of Domains= in resolved.conf(5) for a description of globally configured DNS settings.

The following query routing logic applies for unicast DNS lookups initiated by systemd-resolved.service:

•If a name to look up matches (that is: is equal to or has as suffix) any of the configured routing domains (search or route-only) of any link, or the globally configured DNS settings, "best matching" routing domain is determined: the matching one with the most labels. The query is then sent to all DNS servers of any links or the globally configured DNS servers associated with this "best matching" routing domain. (Note that more than one link might have this same "best matching" routing domain configured, in which case the query is sent to all of them in parallel). In case of single-label names, when search domains are defined, the same logic applies, except that the name is first suffixed by each of the search domains in turn. Note that this search logic doesn't apply to any names with at least one dot. Also see the discussion about compatibility with the traditional glibc resolver below.

•If a query does not match any configured routing domain (either per-link or global), it is sent to all DNS servers that are configured on links with the DefaultRoute= option set, as well as the globally configured DNS server.

•If there is no link configured as DefaultRoute= and no global DNS server configured, one of the compiled-in fallback DNS servers is used.

•Otherwise the unicast DNS query fails, as no suitable DNS servers can be determined.

The DefaultRoute= option is a boolean setting configurable with resolvectl or in .network files. If not set, it is implicitly determined based on the configured DNS domains for a link: if there's a route-only domain other than "~.", it defaults to false, otherwise to true.

Effectively this means: in order to support single-label non-synthesized names, define appropriate search domains. In order to preferably route all DNS queries not explicitly matched by routing domain configuration to a specific link, configure a "~." route-only domain on it. This will ensure that other links will not be considered for these queries (unless they too carry such a routing domain). In order to route all such DNS queries to a specific link only if no other link is preferred, set the DefaultRoute= option for the link to true and do not configure a "~." route-only domain on it. Finally, in order to ensure that a specific link never receives any DNS traffic not matching any of its configured routing domains, set the DefaultRoute= option for it to false.

See org.freedesktop.resolve1(5) for information about the D-Bus APIs systemd-resolved provides.

## COMPATIBILITY WITH THE TRADITIONAL GLIBC STUB RESOLVER
This section provides a short summary of differences in the stub resolver implemented by nss-resolve(8) together with systemd-resolved and the traditional stub resolver implemented in nss-dns.

•Some names are always resolved internally (see Synthetic Records above). Traditionally they would be resolved by nss-files if provided in /etc/hosts. But note that the details of how a query is constructed are under the control of the client library. nss-dns will first try to resolve names using search domains and even if those queries are routed to systemd-resolved, it will send them out over the network using the usual rules for multi-label name routing [3].

•Single-label names are not resolved for A and AAAA records using unicast DNS (unless overridden with ResolveUnicastSingleLabel=, see resolved.conf(5)). This is similar to the no-tld-query option being set in resolv.conf(5).

•Search domains are not used for suffixing of multi-label names. (Search domains are nevertheless used for lookup routing, for names that were originally specified as single-label or multi-label.) Any name with at least one dot is always interpreted as a FQDN. nss-dns would resolve names both as relative (using search domains) and absolute FQDN names. Some names would be resolved as relative first, and after that query has failed, as absolute, while other names would be resolved in opposite order. The ndots option in /etc/resolv.conf was used to control how many dots the name needs to have to be resolved as relative first. This stub resolver does not implement this at all: multi-label names are only resolved as FQDNs.[4]

•This resolver has a notion of the special ".local" domain used for MulticastDNS, and will not route queries with that suffix to unicast DNS servers unless explicitly configured, see above. Also, reverse lookups for link-local addresses are not sent to unicast DNS servers.

•This resolver reads and caches /etc/hosts internally. (In other words, nss-resolve replaces nss-files in addition to nss-dns). Entries in /etc/hosts have highest priority.

•This resolver also implements LLMNR and MulticastDNS in addition to the classic unicast DNS protocol, and will resolve single-label names using LLMNR (when enabled) and names ending in ".local" using MulticastDNS (when enabled).

•Environment variables $LOCALDOMAIN and $RES_OPTIONS described in resolv.conf(5) are not supported currently.

## /ETC/RESOLV.CONF
Four modes of handling /etc/resolv.conf (see resolv.conf(5)) are supported:

•systemd-resolved maintains the /run/systemd/resolve/stub-resolv.conf file for compatibility with traditional Linux programs. This file may be symlinked from /etc/resolv.conf. This file lists the 127.0.0.53 DNS stub (see above) as the only DNS server. It also contains a list of search domains that are in use by systemd-resolved. The list of search domains is always kept up-to-date. Note that /run/systemd/resolve/stub-resolv.conf should not be used directly by applications, but only through a symlink from /etc/resolv.conf. This file may be symlinked from /etc/resolv.conf in order to connect all local clients that bypass local DNS APIs to systemd-resolved with correct search domains settings. This mode of operation is recommended.

•A static file /lib/systemd/resolv.conf is provided that lists the 127.0.0.53 DNS stub (see above) as only DNS server. This file may be symlinked from /etc/resolv.conf in order to connect all local clients that bypass local DNS APIs to systemd-resolved. This file does not contain any search domains.

•systemd-resolved maintains the /run/systemd/resolve/resolv.conf file for compatibility with traditional Linux programs. This file may be symlinked from /etc/resolv.conf and is always kept up-to-date, containing information about all known DNS servers. Note the file format's limitations: it does not know a concept of per-interface DNS servers and hence only contains system-wide DNS server definitions. Note that /run/systemd/resolve/resolv.conf should not be used directly by applications, but only through a symlink from /etc/resolv.conf. If this mode of operation is used local clients that bypass any local DNS API will also bypass systemd-resolved and will talk directly to the known DNS servers.

•Alternatively, /etc/resolv.conf may be managed by other packages, in which case systemd-resolved will read it for DNS configuration data. In this mode of operation systemd-resolved is consumer rather than provider of this configuration file.

Note that the selected mode of operation for this file is detected fully automatically, depending on whether /etc/resolv.conf is a symlink to /run/systemd/resolve/resolv.conf or lists 127.0.0.53 as DNS server.

## SIGNALS
SIGUSR1

Upon reception of the SIGUSR1 process signal systemd-resolved will dump the contents of all DNS resource record caches it maintains, as well as all feature level information it learnt about configured DNS servers into the system logs.

SIGUSR2

Upon reception of the SIGUSR2 process signal systemd-resolved will flush all caches it maintains. Note that it should normally not be necessary to request this explicitly – except for debugging purposes – as systemd-resolved flushes the caches automatically anyway any time the host's network configuration changes. Sending this signal to systemd-resolved is equivalent to the resolvectl flush-caches command, however the latter is recommended since it operates in a synchronous way.

SIGRTMIN+1

Upon reception of the SIGRTMIN+1 process signal systemd-resolved will forget everything it learnt about the configured DNS servers. Specifically any information about server feature support is flushed out, and the server feature probing logic is restarted on the next request, starting with the most fully featured level. Note that it should normally not be necessary to request this explicitly – except for debugging purposes – as systemd-resolved automatically forgets learnt information any time the DNS server configuration changes. Sending this signal to systemd-resolved is equivalent to the resolvectl reset-server-features command, however the latter is recommended since it operates in a synchronous way.

## SEE ALSO
systemd(1), resolved.conf(5), dnssec-trust-anchors.d(5), nss-resolve(8), resolvectl(1), resolv.conf(5), hosts(5), systemd.network(5), systemd-networkd.service(8)

## NOTES
1.

RFC3493

https://tools.ietf.org/html/rfc3493

2.

RFC6762

https://tools.ietf.org/html/rfc6762

3.

For example, if /etc/resolv.conf has

```
nameserver 127.0.0.53
search foobar.com barbar.com

```

and we look up "localhost", nss-dns will send the following queries to systemd-resolved listening on 127.0.0.53:53: first "localhost.foobar.com", then "localhost.barbar.com", and finally "localhost". If (hopefully) the first two queries fail, systemd-resolved will synthesize an answer for the third query.

When using nss-dns with any search domains, it is thus crucial to always configure nss-files with higher priority and provide mappings for names that should not be resolved using search domains.

4.

There are currently more than 1500 top-level domain names defined, and new ones are added regularly, often using "attractive" names that are also likely to be used locally. Not looking up multi-label names in this fashion avoids fragility in both directions: a valid global name could be obscured by a local name, and resolution of a relative local name could suddenly break when a new top-level domain is created, or when a new subdomain of a top-level domain in registered. Resolving any given name as either relative or absolute avoids this ambiguity.


systemd-portabled.service

package: systemd-portable

title: systemd-portabled.service(8)

summary: Portable service manager

text:
# systemd-portabled.service(8)

## NAME
systemd-portabled.service, systemd-portabled - Portable service manager

## SYNOPSIS
systemd-portabled.service

/lib/systemd/systemd-portabled

## DESCRIPTION
systemd-portabled is a system service that may be used to attach, detach and inspect portable service images.

Most of systemd-portabled's functionality is accessible through the portablectl(1) command.

See Portable Services[1] for details about the concepts this service implements.

## SEE ALSO
systemd(1), portablectl(1), org.freedesktop.portable1(5)

## NOTES
1.

Portable Services

https://systemd.io/PORTABLE_SERVICES


halt

package: systemd-sysvinit

title: halt(8)

summary: Halt, power\-off or reboot the machine

text:
# halt(8)

## NAME
halt, poweroff, reboot - Halt, power-off or reboot the machine

## SYNOPSIS
halt [OPTIONS...]

poweroff [OPTIONS...]

reboot [OPTIONS...]

## DESCRIPTION
halt, poweroff, reboot may be used to halt, power-off, or reboot the machine. All three commands take the same options.

## OPTIONS
The following options are understood:

--help

Print a short help text and exit.

--halt

Halt the machine, regardless of which one of the three commands is invoked.

-p, --poweroff

Power-off the machine, regardless of which one of the three commands is invoked.

--reboot

Reboot the machine, regardless of which one of the three commands is invoked.

-f, --force

Force immediate halt, power-off, or reboot. When specified once, this results in an immediate but clean shutdown by the system manager. When specified twice, this results in an immediate shutdown without contacting the system manager. See the description of --force in systemctl(1) for more details.

-w, --wtmp-only

Only write wtmp shutdown entry, do not actually halt, power-off, reboot.

-d, --no-wtmp

Do not write wtmp shutdown entry.

-n, --no-sync

Don't sync hard disks/storage media before halt, power-off, reboot.

--no-wall

Do not send wall message before halt, power-off, reboot.

## EXIT STATUS
On success, 0 is returned, a non-zero failure code otherwise.

## NOTES
These commands are implemented in a way that preserves basic compatibility with the original SysV commands. systemctl(1) verbs halt, poweroff, reboot provide the same functionality with some additional features.

Note that on many SysV systems halt used to be synonymous to poweroff, i.e. both commands would equally result in powering the machine off. systemd is more accurate here, and halt results in halting the machine only (leaving power on), and poweroff is required to actually power it off.

## SEE ALSO
systemd(1), systemctl(1), shutdown(8), wall(1)


runlevel

title: runlevel(8)

text:
# runlevel(8)

## NAME
runlevel - Print previous and current SysV runlevel

## SYNOPSIS
runlevel [options...]

## OVERVIEW
"Runlevels" are an obsolete way to start and stop groups of services used in SysV init. systemd provides a compatibility layer that maps runlevels to targets, and associated binaries like runlevel. Nevertheless, only one runlevel can be "active" at a given time, while systemd can activate multiple targets concurrently, so the mapping to runlevels is confusing and only approximate. Runlevels should not be used in new code, and are mostly useful as a shorthand way to refer the matching systemd targets in kernel boot parameters.

Table 1. Mapping between runlevels and systemd targets

Runlevel

Target

0

poweroff.target

1

rescue.target

2, 3, 4

multi-user.target

5

graphical.target

6

reboot.target

## 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:

--help

Print a short help text and exit.

## 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
/run/utmp

The utmp database runlevel reads the previous and current runlevel from.

## SEE ALSO
systemd(1), systemd.target(5), systemctl(1)


shutdown

title: shutdown(8)

summary: Halt, power\-off or reboot the machine

text:
# shutdown(8)

## NAME
shutdown - Halt, power-off or reboot the machine

## SYNOPSIS
shutdown [OPTIONS...] [TIME] [WALL...]

## DESCRIPTION
shutdown may be used to halt, power-off or reboot the machine.

The first argument may be a time string (which is usually "now"). Optionally, this may be followed by a wall message to be sent to all logged-in users before going down.

The time string may either be in the format "hh:mm" for hour/minutes specifying the time to execute the shutdown at, specified in 24h clock format. Alternatively it may be in the syntax "+m" referring to the specified number of minutes m from now. "now" is an alias for "+0", i.e. for triggering an immediate shutdown. If no time argument is specified, "+1" is implied.

Note that to specify a wall message you must specify a time argument, too.

If the time argument is used, 5 minutes before the system goes down the /run/nologin file is created to ensure that further logins shall not be allowed.

## OPTIONS
The following options are understood:

--help

Print a short help text and exit.

-H, --halt

Halt the machine.

-P, --poweroff

Power-off the machine (the default).

-r, --reboot

Reboot the machine.

-h

Equivalent to --poweroff, unless --halt is specified.

-k

Do not halt, power-off, reboot, just write wall message.

--no-wall

Do not send wall message before halt, power-off, reboot.

-c

Cancel a pending shutdown. This may be used to cancel the effect of an invocation of shutdown with a time argument that is not "+0" or "now".

## EXIT STATUS
On success, 0 is returned, a non-zero failure code otherwise.

## SEE ALSO
systemd(1), systemctl(1), halt(8), wall(1)


telinit

title: telinit(8)

summary: Change SysV runlevel

text:
# telinit(8)

## NAME
telinit - Change SysV runlevel

## SYNOPSIS
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:

--help

Print a short help text and exit.

--no-wall

Do not send wall message before reboot/halt/power-off.

The following commands are understood:

0

Power-off the machine. This is translated into an activation request for poweroff.target and is equivalent to systemctl poweroff.

6

Reboot the machine. This is translated into an activation request for reboot.target and is equivalent to systemctl reboot.

2, 3, 4, 5

Change the SysV runlevel. This is translated into an activation request for runlevel2.target, runlevel3.target, ... and is equivalent to systemctl isolate runlevel2.target, systemctl isolate runlevel3.target, ...

1, s, S

Change into system rescue mode. This is translated into an activation request for rescue.target and is equivalent to systemctl rescue.

q, Q

Reload daemon configuration. This is equivalent to systemctl daemon-reload.

u, U

Serialize state, reexecute daemon and deserialize state again. This is equivalent to systemctl daemon-reexec.

## EXIT STATUS
On success, 0 is returned, a non-zero failure code otherwise.

## NOTES
This is a legacy command available for compatibility only. It should not be used anymore, as the concept of runlevels is obsolete.

## SEE ALSO
systemd(1), systemctl(1), wall(1)


systemd-time-wait-sync.service

package: systemd-timesyncd

title: systemd-time-wait-sync.service(8)

summary: Wait until kernel time is synchronized

text:
# systemd-time-wait-sync.service(8)

## NAME
systemd-time-wait-sync.service, systemd-time-wait-sync - Wait until kernel time is synchronized

## SYNOPSIS
systemd-time-wait-sync.service

/lib/systemd/systemd-time-wait-sync

## DESCRIPTION
systemd-time-wait-sync is a system service that delays the start of units that are ordered after time-sync.target (see systemd.special(7) for details) until the system time has been synchronized with an accurate remote reference time source by systemd-timesyncd.service.

systemd-timesyncd.service notifies systemd-time-wait-sync about successful synchronization. systemd-time-wait-sync also tries to detect when the kernel marks the system clock as synchronized, but this detection is not reliable and is intended only as a fallback for compatibility with alternative NTP services that can be used to synchronize time (e.g., ntpd, chronyd).

## FILES
/run/systemd/timesync/synchronized

The presence of this file indicates to this service that the system clock has been synchronized.

## SEE ALSO
systemd(1), systemd.special(7), systemd-timesyncd.service(8),


systemd-timesyncd.service

title: systemd-timesyncd.service(8)

summary: Network Time Synchronization

text:
# systemd-timesyncd.service(8)

## NAME
systemd-timesyncd.service, systemd-timesyncd - Network Time Synchronization

## SYNOPSIS
systemd-timesyncd.service

/lib/systemd/systemd-timesyncd

## DESCRIPTION
systemd-timesyncd is a system service that may be used to synchronize the local system clock with a remote Network Time Protocol (NTP) server. It also saves the local time to disk every time the clock has been synchronized and uses this to possibly advance the system realtime clock on subsequent reboots to ensure it (roughly) monotonically advances even if the system lacks a battery-buffered RTC chip.

The systemd-timesyncd service implements SNTP only. This minimalistic service will step the system clock for large offsets or slowly adjust it for smaller deltas. Complex use cases that require full NTP support (and where SNTP is not sufficient) are not covered by systemd-timesyncd.

The NTP servers contacted are determined from the global settings in timesyncd.conf(5), the per-link static settings in .network files, and the per-link dynamic settings received over DHCP. See systemd.network(5) for further details.

timedatectl(1)'s set-ntp command may be used to enable and start, or disable and stop this service.

timedatectl(1)'s timesync-status or show-timesync command can be used to show the current status of this service.

systemd-timesyncd initialization delays the start of units that are ordered after time-set.target (see systemd.special(7) for details) until the local time has been updated from /var/lib/systemd/timesync/clock (see below) in order to make it roughly monotonic. It does not delay other units until synchronization with an accurate reference time sources has been reached. Use systemd-time-wait-sync.service(8) to achieve that, which will delay start of units that are ordered after time-sync.target until synchronization to an accurate reference clock is reached.

## FILES
/var/lib/systemd/timesync/clock

The modification time ("mtime") of this file indicates the timestamp of the last successful synchronization (or at least the systemd build date, in case synchronization was not possible). It is used to ensure that the system clock remains roughly monotonic across reboots, in case no local RTC is available.

/run/systemd/timesync/synchronized

A file that is touched on each successful synchronization, to assist systemd-time-wait-sync and other applications to detecting synchronization with accurate reference clocks.

## SEE ALSO
systemd(1), timesyncd.conf(5), systemd.network(5), systemd-networkd.service(8), systemd-time-wait-sync.service(8), systemd.special(7), timedatectl(1), localtime(5), hwclock(8)


fstab-decode

package: sysvinit

title: fstab-decode(8)

text:
# fstab-decode(8)

## NAME
fstab-decode - run a command with fstab-encoded arguments

## SYNOPSIS
fstab-decode COMMAND [ARGUMENT]...

## DESCRIPTION
fstab-decode decodes escapes in the specified ARGUMENTs and uses them to run COMMAND. The argument escaping uses the same rules as path escaping in /etc/fstab, /etc/mtab and /proc/mtab.

## EXIT STATUS
fstab-decode exits with status 127 if COMMAND can't be run. Otherwise it exits with the status returned by COMMAND.

## EXAMPLES
fstab-decode umount $(awk '$3 == vfat { print $2 }' /etc/fstab)


halt

title: halt(8)

summary: stop the system.

text:
# halt(8)

## NAME
halt, reboot, poweroff - stop the system.

## SYNOPSIS
/sbin/halt [-n] [-w] [-d] [-f] [-i] [-p] [-h]

/sbin/reboot [-n] [-w] [-d] [-f] [-i] [-k]

/sbin/poweroff [-n] [-w] [-d] [-f] [-i] [-h]

## DESCRIPTION
Halt notes that the system is being brought down in the file /var/log/wtmp, and then either tells the kernel to halt, reboot or power-off the system.

If halt or reboot is called when the system is not in runlevel 0 or 6, in other words when it's running normally, shutdown will be invoked instead (with the -h or -r flag). For more info see the shutdown(8) manpage.

The rest of this manpage describes the behaviour in runlevels 0 and 6, that is when the systems shutdown scripts are being run.

## OPTIONS
-n

Don't sync before reboot or halt. Note that the kernel and storage drivers may still sync.

-w

Don't actually reboot or halt but only write the wtmp record (in the /var/log/wtmp file).

-d

Don't write the wtmp record. The -n flag implies -d.

-f

Force halt or reboot, don't call shutdown(8).

-i

Shut down all network interfaces just before halt or reboot.

-h

Put all hard drives on the system in stand-by mode just before halt or power-off.

-p

When halting the system, switch off the power. This is the default when halt is called as poweroff.

-k

Try to reboot using kexec, if kernel supports it.

## DIAGNOSTICS
If you're not the superuser, you will get the message `operation not permitted'.

## NOTES
Under older sysvinit releases , reboot and halt should never be called directly. From release 2.74 on halt and reboot invoke shutdown(8) if the system is not in runlevel 0 or 6. This means that if halt or reboot cannot find out the current runlevel (for example, when /var/run/utmp hasn't been initialized correctly) shutdown will be called, which might not be what you want. Use the -f flag if you want to do a hard halt or reboot.

The -h flag puts all hard disks in standby mode just before halt or power-off. Right now this is only implemented for IDE drives. A side effect of putting the drive in stand-by mode is that the write cache on the disk is flushed. This is important for IDE drives, since the kernel doesn't flush the write cache itself before power-off.

The halt program uses /proc/ide/hd* to find all IDE disk devices, which means that /proc needs to be mounted when halt or poweroff is called or the -h switch will do nothing.

## AUTHOR
Miquel van Smoorenburg, miquels@cistron.nl

## SEE ALSO
shutdown(8), init(8)