systemd-hibernate-resume@.service

title: systemd-hibernate-resume@.service(8)

summary: Resume from hibernation

text:
# systemd-hibernate-resume@.service(8)

## NAME
systemd-hibernate-resume@.service, systemd-hibernate-resume - Resume from hibernation

## SYNOPSIS
systemd-hibernate-resume@.service

/lib/systemd/systemd-hibernate-resume

## DESCRIPTION
systemd-hibernate-resume@.service initiates the resume from hibernation. It is instantiated with the device to resume from as the template argument.

systemd-hibernate-resume only supports the in-kernel hibernation implementation, known as swsusp[1]. Internally, it works by writing the major:minor of specified device node to /sys/power/resume.

Failing to initiate a resume is not an error condition. It may mean that there was no resume image (e. g. if the system has been simply powered off and not hibernated). In such case, the boot is ordinarily continued.

## SEE ALSO
systemd(1), systemd-hibernate-resume-generator(8)

## NOTES
1.

swsusp

https://www.kernel.org/doc/Documentation/power/swsusp.txt


systemd-hostnamed.service

package: systemd

title: systemd-hostnamed.service(8)

text:
# systemd-hostnamed.service(8)

## NAME
systemd-hostnamed.service, systemd-hostnamed - Daemon to control system hostname from programs

## SYNOPSIS
systemd-hostnamed.service

/lib/systemd/systemd-hostnamed

## DESCRIPTION
systemd-hostnamed.service is a system service that may be used to change the system's hostname and related machine metadata from user programs. It is automatically activated on request and terminates itself when unused.

It currently offers access to five variables:

•The current hostname (Example: "dhcp-192-168-47-11")

•The static (configured) hostname (Example: "lennarts-computer")

•The pretty hostname (Example: "Lennart's Computer")

•A suitable icon name for the local host (Example: "computer-laptop")

•A chassis type (Example: "tablet")

The static hostname is stored in /etc/hostname, see hostname(5) for more information. The pretty hostname, chassis type, and icon name are stored in /etc/machine-info, see machine-info(5).

The tool hostnamectl(1) is a command line client to this service.

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

## SEE ALSO
systemd(1), hostname(5), machine-info(5), hostnamectl(1), sethostname(2)


systemd-initctl.service

title: systemd-initctl.service(8)

summary: /dev/initctl compatibility

text:
# systemd-initctl.service(8)

## NAME
systemd-initctl.service, systemd-initctl.socket, systemd-initctl - /dev/initctl compatibility

## SYNOPSIS
systemd-initctl.service

systemd-initctl.socket

/lib/systemd/systemd-initctl

## DESCRIPTION
systemd-initctl is a system service that implements compatibility with the /dev/initctl FIFO file system object, as implemented by the SysV init system. systemd-initctl is automatically activated on request and terminates itself when it is unused.

## SEE ALSO
systemd(1)


systemd-journald.service

title: systemd-journald.service(8)

summary: Journal service

text:
# systemd-journald.service(8)

## NAME
systemd-journald.service, systemd-journald.socket, systemd-journald-dev-log.socket, systemd-journald-audit.socket, systemd-journald@.service, systemd-journald@.socket, systemd-journald-varlink@.socket, systemd-journald - Journal service

## SYNOPSIS
systemd-journald.service

systemd-journald.socket

systemd-journald-dev-log.socket

systemd-journald-audit.socket

systemd-journald@.service

systemd-journald@.socket

systemd-journald-varlink@.socket

/lib/systemd/systemd-journald

## DESCRIPTION
systemd-journald is a system service that collects and stores logging data. It creates and maintains structured, indexed journals based on logging information that is received from a variety of sources:

•Kernel log messages, via kmsg

•Simple system log messages, via the libc syslog(3) call

•Structured system log messages via the native Journal API, see sd_journal_print(3) and Native Journal Protocol[1]

•Standard output and standard error of service units. For further details see below.

•Audit records, originating from the kernel audit subsystem

The daemon will implicitly collect numerous metadata fields for each log messages in a secure and unfakeable way. See systemd.journal-fields(7) for more information about the collected metadata.

Log data collected by the journal is primarily text-based but can also include binary data where necessary. Individual fields making up a log record stored in the journal may be up to 2^64-1 bytes in size.

The journal service stores log data either persistently below /var/log/journal or in a volatile way below /run/log/journal/ (in the latter case it is lost at reboot). By default, log data is stored persistently if /var/log/journal/ exists during boot, with an implicit fallback to volatile storage otherwise. Use Storage= in journald.conf(5) to configure where log data is placed, independently of the existence of /var/log/journal/.

Note that journald will initially use volatile storage, until a call to journalctl --flush (or sending SIGUSR1 to journald) will cause it to switch to persistent logging (under the conditions mentioned above). This is done automatically on boot via "systemd-journal-flush.service".

On systems where /var/log/journal/ does not exist yet but where persistent logging is desired (and the default journald.conf is used), it is sufficient to create the directory, and ensure it has the correct access modes and ownership:

```
mkdir -p /var/log/journal
systemd-tmpfiles --create --prefix /var/log/journal
```

See journald.conf(5) for information about the configuration of this service.

## STREAM LOGGING
The systemd service manager invokes all service processes with standard output and standard error connected to the journal by default. This behaviour may be altered via the StandardOutput=/StandardError= unit file settings, see systemd.exec(5) for details. The journal converts the log byte stream received this way into individual log records, splitting the stream at newline ("\n", ASCII 10) and NUL bytes.

If systemd-journald.service is stopped, the stream connections associated with all services are terminated. Further writes to those streams by the service will result in EPIPE errors. In order to react gracefully in this case it is recommended that programs logging to standard output/error ignore such errors. If the SIGPIPE UNIX signal handler is not blocked or turned off, such write attempts will also result in such process signals being generated, see signal(7). To mitigate this issue, systemd service manager explicitly turns off the SIGPIPE signal for all invoked processes by default (this may be changed for each unit individually via the IgnoreSIGPIPE= option, see systemd.exec(5) for details). After the standard output/standard error streams have been terminated they may not be recovered until the services they are associated with are restarted. Note that during normal operation, systemd-journald.service stores copies of the file descriptors for those streams in the service manager. If systemd-journald.service is restarted using systemctl restart or equivalent operation instead of a pair of separate systemctl stop and systemctl start commands (or equivalent operations), these stream connections are not terminated and survive the restart. It is thus safe to restart systemd-journald.service, but stopping it is not recommended.

Note that the log record metadata for records transferred via such standard output/error streams reflect the metadata of the peer the stream was originally created for. If the stream connection is passed on to other processes (such as further child processes forked off the main service process), the log records will not reflect their metadata, but will continue to describe the original process. This is different from the other logging transports listed above, which are inherently record based and where the metadata is always associated with the individual record.

In addition to the implicit standard output/error logging of services, stream logging is also available via the systemd-cat(1) command line tool.

Currently, the number of parallel log streams systemd-journald will accept is limited to 4096. When this limit is reached further log streams may be established but will receive EPIPE right from the beginning.

## JOURNAL NAMESPACES
Journal 'namespaces' are both a mechanism for logically isolating the log stream of projects consisting of one or more services from the rest of the system and a mechanism for improving performance. Multiple journal namespaces may exist simultaneously, each defining its own, independent log stream managed by its own instance of systemd-journald. Namespaces are independent of each other, both in the data store and in the IPC interface. By default only a single 'default' namespace exists, managed by systemd-journald.service (and its associated socket units). Additional namespaces are created by starting an instance of the systemd-journald@.service service template. The instance name is the namespace identifier, which is a short string used for referencing the journal namespace. Service units may be assigned to a specific journal namespace through the LogNamespace= unit file setting, see systemd.exec(5) for details. The --namespace= switch of journalctl(1) may be used to view the log stream of a specific namespace. If the switch is not used the log stream of the default namespace is shown, i.e. log data from other namespaces is not visible.

Services associated with a specific log namespace may log via syslog, the native logging protocol of the journal and via stdout/stderr; the logging from all three transports is associated with the namespace.

By default only the default namespace will collect kernel and audit log messages.

The systemd-journald instance of the default namespace is configured through /etc/systemd/journald.conf (see below), while the other instances are configured through /etc/systemd/journald@NAMESPACE.conf. The journal log data for the default namespace is placed in /var/log/journal/MACHINE_ID (see below) while the data for the other namespaces is located in /var/log/journal/MACHINE_ID.NAMESPACE.

## SIGNALS
SIGUSR1

Request that journal data from /run/ is flushed to /var/ in order to make it persistent (if this is enabled). This must be used after /var/ is mounted, as otherwise log data from /run/ is never flushed to /var/ regardless of the configuration. Use the journalctl --flush command to request flushing of the journal files, and wait for the operation to complete. See journalctl(1) for details.

SIGUSR2

Request immediate rotation of the journal files. Use the journalctl --rotate command to request journal file rotation, and wait for the operation to complete.

SIGRTMIN+1

Request that all unwritten log data is written to disk. Use the journalctl --sync command to trigger journal synchronization, and wait for the operation to complete.

## KERNEL COMMAND LINE
A few configuration parameters from journald.conf may be overridden on the kernel command line:

systemd.journald.forward_to_syslog=, systemd.journald.forward_to_kmsg=, systemd.journald.forward_to_console=, systemd.journald.forward_to_wall=

Enables/disables forwarding of collected log messages to syslog, the kernel log buffer, the system console or wall. See journald.conf(5) for information about these settings.

Note that these kernel command line options are only honoured by the default namespace, see above.

## ACCESS CONTROL
Journal files are, by default, owned and readable by the "systemd-journal" system group but are not writable. Adding a user to this group thus enables them to read the journal files.

By default, each user, with a UID outside the range of system users, dynamic service users, and the nobody user, will get their own set of journal files in /var/log/journal/. See Users, Groups, UIDs and GIDs on systemd systems[2] for more details about UID ranges. These journal files will not be owned by the user, however, in order to avoid that the user can write to them directly. Instead, file system ACLs are used to ensure the user gets read access only.

Additional users and groups may be granted access to journal files via file system access control lists (ACL). Distributions and administrators may choose to grant read access to all members of the "wheel" and "adm" system groups with a command such as the following:

```
# setfacl -Rnm g:wheel:rx,d:g:wheel:rx,g:adm:rx,d:g:adm:rx /var/log/journal/
```

Note that this command will update the ACLs both for existing journal files and for future journal files created in the /var/log/journal/ directory.

## FILES
/etc/systemd/journald.conf

Configure systemd-journald behavior. See journald.conf(5).

/run/log/journal/machine-id/*.journal, /run/log/journal/machine-id/*.journal~, /var/log/journal/machine-id/*.journal, /var/log/journal/machine-id/*.journal~

systemd-journald writes entries to files in /run/log/journal/machine-id/ or /var/log/journal/machine-id/ with the ".journal" suffix. If the daemon is stopped uncleanly, or if the files are found to be corrupted, they are renamed using the ".journal~" suffix, and systemd-journald starts writing to a new file. /run/ is used when /var/log/journal is not available, or when Storage=volatile is set in the journald.conf(5) configuration file. When systemd-journald ceases writing to a journal file, it will be renamed to "original-name@suffix.journal" (or "original-name@suffix.journal~"). Such files are "archived" and will not be written to any more.

In general, it is safe to read or copy any journal file (active or archived). journalctl(1) and the functions in the sd-journal(3) library should be able to read all entries that have been fully written.

systemd-journald will automatically remove the oldest archived journal files to limit disk use. See SystemMaxUse= and related settings in journald.conf(5).

/dev/kmsg, /dev/log, /run/systemd/journal/dev-log, /run/systemd/journal/socket, /run/systemd/journal/stdout

Sockets and other file node paths that systemd-journald will listen on and are visible in the file system. In addition to these, systemd-journald can listen for audit events using netlink(7).

If journal namespacing is used these paths are slightly altered to include a namespace identifier, see above.

## SEE ALSO
systemd(1), journalctl(1), journald.conf(5), systemd.journal-fields(7), sd-journal(3), systemd-coredump(8), setfacl(1), sd_journal_print(3), pydoc systemd.journal

## NOTES
1.

Native Journal Protocol

https://systemd.io/JOURNAL_NATIVE_PROTOCOL

2.

Users, Groups, UIDs and GIDs on systemd systems

https://systemd.io/UIDS-GIDS


systemd-localed.service

title: systemd-localed.service(8)

summary: Locale bus mechanism

text:
# systemd-localed.service(8)

## NAME
systemd-localed.service, systemd-localed - Locale bus mechanism

## SYNOPSIS
systemd-localed.service

/lib/systemd/systemd-localed

## DESCRIPTION
systemd-localed.service is a system service that may be used as mechanism to change the system locale settings, as well as the console key mapping and default X11 key mapping. systemd-localed is automatically activated on request and terminates itself when it is unused.

The tool localectl(1) is a command line client to this service.

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

## SEE ALSO
systemd(1), locale.conf(5), vconsole.conf(5), localectl(1), loadkeys(1)


systemd-logind.service

title: systemd-logind.service(8)

summary: Login manager

text:
# systemd-logind.service(8)

## NAME
systemd-logind.service, systemd-logind - Login manager

## SYNOPSIS
systemd-logind.service

/lib/systemd/systemd-logind

## DESCRIPTION
systemd-logind is a system service that manages user logins. It is responsible for:

•Keeping track of users and sessions, their processes and their idle state. This is implemented by allocating a systemd slice unit for each user below user.slice, and a scope unit below it for each concurrent session of a user. Also, a per-user service manager is started as system service instance of user@.service for each logged in user.

•Generating and managing session IDs. If auditing is available and an audit session ID is already set for a session, then this ID is reused as the session ID. Otherwise, an independent session counter is used.

•Providing polkit[1]-based access for users for operations such as system shutdown or sleep

•Implementing a shutdown/sleep inhibition logic for applications

•Handling of power/sleep hardware keys

•Multi-seat management

•Session switch management

•Device access management for users

•Automatic spawning of text logins (gettys) on virtual console activation and user runtime directory management

User sessions are registered with logind via the pam_systemd(8) PAM module.

See logind.conf(5) for information about the configuration of this service.

See sd-login(3) for information about the basic concepts of logind such as users, sessions and seats.

See org.freedesktop.login1(5) and org.freedesktop.LogControl1(5) for information about the D-Bus APIs systemd-logind provides.

For more information on the inhibition logic see the Inhibitor Lock Developer Documentation[2].

If you are interested in writing a display manager that makes use of logind, please have look at Writing Display Managers[3]. If you are interested in writing a desktop environment that makes use of logind, please have look at Writing Desktop Environments[4].

## SEE ALSO
systemd(1), systemd-user-sessions.service(8), loginctl(1), logind.conf(5), pam_systemd(8), sd-login(3)

## NOTES
1.

polkit

https://www.freedesktop.org/wiki/Software/polkit

2.

Inhibitor Lock Developer Documentation

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

3.

Writing Display Managers

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

4.

Writing Desktop Environments

https://www.freedesktop.org/wiki/Software/systemd/writing-desktop-environments


systemd-machine-id-commit.service

title: systemd-machine-id-commit.service(8)

summary: Commit a transient machine ID to disk

text:
# systemd-machine-id-commit.service(8)

## NAME
systemd-machine-id-commit.service - Commit a transient machine ID to disk

## SYNOPSIS
systemd-machine-id-commit.service

## DESCRIPTION
systemd-machine-id-commit.service is an early boot service responsible for committing transient /etc/machine-id files to a writable disk file system. See machine-id(5) for more information about machine IDs.

This service is started after local-fs.target in case /etc/machine-id is a mount point of its own (usually from a memory file system such as "tmpfs") and /etc is writable. The service will invoke systemd-machine-id-setup --commit, which writes the current transient machine ID to disk and unmount the /etc/machine-id file in a race-free manner to ensure that file is always valid and accessible for other processes. See systemd-machine-id-setup(8) for details.

The main use case of this service are systems where /etc/machine-id is read-only and initially not initialized. In this case, the system manager will generate a transient machine ID file on a memory file system, and mount it over /etc/machine-id, during the early boot phase. This service is then invoked in a later boot phase, as soon as /etc/ has been remounted writable and the ID may thus be committed to disk to make it permanent.

## SEE ALSO
systemd(1), systemd-machine-id-setup(8), machine-id(5), systemd-firstboot(8)


systemd-machine-id-setup

title: systemd-machine-id-setup(8)

summary: Initialize the machine ID in /etc/machine\-id

text:
# systemd-machine-id-setup(8)

## NAME
systemd-machine-id-setup - Initialize the machine ID in /etc/machine-id

## SYNOPSIS
systemd-machine-id-setup

## DESCRIPTION
systemd-machine-id-setup may be used by system installer tools to initialize the machine ID stored in /etc/machine-id at install time, with a provisioned or randomly generated ID. See machine-id(5) for more information about this file.

If the tool is invoked without the --commit switch, /etc/machine-id is initialized with a valid, new machined ID if it is missing or empty. The new machine ID will be acquired in the following fashion:

1.If a valid D-Bus machine ID is already configured for the system, the D-Bus machine ID is copied and used to initialize the machine ID in /etc/machine-id.

2.If run inside a KVM virtual machine and a UUID is configured (via the -uuid option), this UUID is used to initialize the machine ID. The caller must ensure that the UUID passed is sufficiently unique and is different for every booted instance of the VM.

3.Similarly, if run inside a Linux container environment and a UUID is configured for the container, this is used to initialize the machine ID. For details, see the documentation of the Container Interface[1].

4.Otherwise, a new ID is randomly generated.

The --commit switch may be used to commit a transient machined ID to disk, making it persistent. For details, see below.

Use systemd-firstboot(8) to initialize the machine ID on mounted (but not booted) system images.

## OPTIONS
The following options are understood:

--root=path

Takes a directory path as argument. All paths operated on will be prefixed with the given alternate root path, including the path for /etc/machine-id itself.

--image=path

Takes a path to a device node or regular file as argument. This is similar to --root= as described above, but operates on a disk image instead of a directory tree.

--commit

Commit a transient machine ID to disk. This command may be used to convert a transient machine ID into a persistent one. A transient machine ID file is one that was bind mounted from a memory file system (usually "tmpfs") to /etc/machine-id during the early phase of the boot process. This may happen because /etc/ is initially read-only and was missing a valid machine ID file at that point. This command will execute no operation if /etc/machine-id is not mounted from a memory file system, or if /etc/ is read-only. The command will write the current transient machine ID to disk and unmount the /etc/machine-id mount point in a race-free manner to ensure that this file is always valid and accessible for other processes.

This command is primarily used by the systemd-machine-id-commit.service(8) early boot service.

--print

Print the machine ID generated or committed after the operation is complete.

-h, --help

Print a short help text and exit.

--version

Print a short version string and exit.

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

## SEE ALSO
systemd(1), machine-id(5), systemd-machine-id-commit.service(8), dbus-uuidgen(1), systemd-firstboot(8)

## NOTES
1.

Container Interface

https://systemd.io/CONTAINER_INTERFACE


systemd-makefs@.service

title: systemd-makefs@.service(8)

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

## NAME
systemd-makefs@.service, systemd-mkswap@.service, systemd-growfs@.service, systemd-makefs, systemd-growfs - Creating and growing file systems on demand

## SYNOPSIS
systemd-makefs@device.service

systemd-mkswap@device.service

systemd-growfs@mountpoint.service

/lib/systemd/systemd-makefs

/lib/systemd/systemd-growfs

## DESCRIPTION
systemd-makefs@.service, systemd-mkswap@.service, and systemd-growfs@.service are used to implement the x-systemd.makefs and x-systemd.growfs options in fstab(5), see systemd.mount(5). They are instantiated for each device for which the file system or swap structure needs to be initialized, and for each mount point where the file system needs to be grown.

These services are started at boot, either right before or right after the mount point or swap device are used.

systemd-makefs knows very little about specific file systems and swap devices, and after checking that the block device does not already contain a file system or other content, it will execute binaries specific to each filesystem type (/sbin/mkfs.type or /sbin/mkswap).

systemd-growfs knows very little about specific file systems and swap devices, and will instruct the kernel to grow the mounted filesystem to full size of the underlying block device. Nevertheless, it needs to know the ioctl(2) number specific to each file system, so only certain types are supported. Currently: ext4(5), btrfs(5), xfs(5), and dm-crypt partitions (see cryptsetup(8)).

If the creation of a file system or swap device fails, the mount point or swap is failed too. If the growing of a file system fails, a warning is emitted.

## SEE ALSO
systemd(1), systemd.mount(8), systemd-fstab-generator(8), systemd-repart(8), mkfs.btrfs(8), mkfs.cramfs(8), mkfs.ext4(8), mkfs.fat(8), mkfs.hfsplus(8), mkfs.minix(8), mkfs.ntfs(8), mkfs.xfs(8)


systemd-modules-load.service

title: systemd-modules-load.service(8)

summary: Load kernel modules at boot

text:
# systemd-modules-load.service(8)

## NAME
systemd-modules-load.service, systemd-modules-load - Load kernel modules at boot

## SYNOPSIS
systemd-modules-load.service

/lib/systemd/systemd-modules-load

## DESCRIPTION
systemd-modules-load.service is an early boot service that loads kernel modules. It reads static configuration from files in /usr/ and /etc/, but also runtime configuration from /run/ and the kernel command line (see below).

See modules-load.d(5) for information about the configuration format of this service and paths where configuration files can be created.

## KERNEL COMMAND LINE
systemd-modules-load.service understands the following kernel command line parameters:

modules_load=, rd.modules_load=

Takes a comma-separated list of kernel modules to statically load during early boot. The option prefixed with "rd." is read by the initial RAM disk only.

## SEE ALSO
systemd(1), modules-load.d(5),


systemd-oomd.service

title: systemd-oomd.service(8)

summary: A userspace out\-of\-memory (OOM) killer

text:
# systemd-oomd.service(8)

## NAME
systemd-oomd.service, systemd-oomd - A userspace out-of-memory (OOM) killer

## SYNOPSIS
systemd-oomd.service

/usr/lib/systemd/systemd-oomd

## DESCRIPTION
systemd-oomd is a system service that uses cgroups-v2 and pressure stall information (PSI) to monitor and take action on processes before an OOM occurs in kernel space.

You can enable monitoring and actions on units by setting ManagedOOMSwap= and/or ManagedOOMMemoryPressure= to the appropriate value. systemd-oomd will periodically poll enabled units' cgroup data to detect when corrective action needs to occur. When an action needs to happen, it will only be performed on the descendant cgroups of the enabled units. More precisely, only cgroups with memory.oom.group set to 1 and leaf cgroup nodes are eligible candidates. Action will be taken recursively on all of the processes under the chosen candidate.

See oomd.conf(5) for more information about the configuration of this service.

## SETUP INFORMATION
The system must be running systemd with a full unified cgroup hierarchy for the expected cgroups-v2 features. Furthermore, memory accounting must be turned on for all units monitored by systemd-oomd. The easiest way to turn on memory accounting is by ensuring the value for DefaultMemoryAccounting= is set to true in systemd-system.conf(5).

You will need a kernel compiled with PSI support. This is available in Linux 4.20 and above.

It is highly recommended for the system to have swap enabled for systemd-oomd to function optimally. With swap enabled, the system spends enough time swapping pages to let systemd-oomd react. Without swap, the system enters a livelocked state much more quickly and may prevent systemd-oomd from responding in a reasonable amount of time. See "In defence of swap: common misconceptions"[1] for more details on swap. Any swap-based actions on systems without swap will be ignored. While systemd-oomd can perform pressure-based actions on a system without swap, the pressure increases will be more abrupt and may require more tuning to get the desired thresholds and behavior.

Be aware that if you intend to enable monitoring and actions on user.slice, user-$UID.slice, or their ancestor cgroups, it is highly recommended that your programs be managed by the systemd user manager to prevent running too many processes under the same session scope (and thus avoid a situation where memory intensive tasks trigger systemd-oomd to kill everything under the cgroup). If you're using a desktop environment like GNOME, it already spawns many session components with the systemd user manager.

## USAGE RECOMMENDATIONS
ManagedOOMSwap= works with the system-wide swap values, so setting it on the root slice -.slice, and allowing all descendant cgroups to be eligible candidates may make the most sense.

ManagedOOMMemoryPressure= tends to work better on the cgroups below the root slice -.slice. For units which tend to have processes that are less latency sensitive (e.g. system.slice), a higher limit like the default of 60% may be acceptable, as those processes can usually ride out slowdowns caused by lack of memory without serious consequences. However, something like user@$UID.service may prefer a much lower value like 40%.

## SEE ALSO
systemd(1), systemd-system.conf(5), systemd.resource-control(5), oomd.conf(5), oomctl(1)

## NOTES
1.

"In defence of swap: common misconceptions"

https://chrisdown.name/2018/01/02/in-defence-of-swap.html


systemd-pstore.service

title: systemd-pstore.service(8)

summary: A service to archive contents of pstore

text:
# systemd-pstore.service(8)

## NAME
systemd-pstore.service, systemd-pstore - A service to archive contents of pstore

## SYNOPSIS
/lib/systemd/systemd-pstore

systemd-pstore.service

## DESCRIPTION
systemd-pstore.service is a system service that archives the contents of the Linux persistent storage filesystem, pstore, to other storage, thus preserving the existing information contained in the pstore, and clearing pstore storage for future error events.

Linux provides a persistent storage file system, pstore, that can store error records when the kernel dies (or reboots or powers-off). These records in turn can be referenced to debug kernel problems (currently the kernel stores the tail of the kernel log, which also contains a stack backtrace, into pstore).

The pstore file system supports a variety of backends that map onto persistent storage, such as the ACPI ERST and UEFI variables. The pstore backends typically offer a relatively small amount of persistent storage, e.g. 64KiB, which can quickly fill up and thus prevent subsequent kernel crashes from recording errors. Thus there is a need to monitor and extract the pstore contents so that future kernel problems can also record information in the pstore.

The pstore service is independent of the kdump service. In cloud environments specifically, host and guest filesystems are on remote filesystems (e.g. iSCSI or NFS), thus kdump relies (implicitly and/or explicitly) upon proper operation of networking software *and* hardware *and* infrastructure. Thus it may not be possible to capture a kernel coredump to a file since writes over the network may not be possible.

The pstore backend, on the other hand, is completely local and provides a path to store error records which will survive a reboot and aid in post-mortem debugging.

The systemd-pstore executable does the actual work. Upon starting, the pstore.conf file is read and the /sys/fs/pstore/ directory contents are processed according to the options. Pstore files are written to the journal, and optionally saved into /var/lib/systemd/pstore/.

## CONFIGURATION
The behavior of systemd-pstore is configured through the configuration file /etc/systemd/pstore.conf and corresponding snippets /etc/systemd/pstore.conf.d/*.conf, see pstore.conf(5).

### Disabling pstore processing
To disable pstore processing by systemd-pstore, set

```
Storage=none
```

in pstore.conf(5).

### Kernel parameters
The kernel has two parameters, /sys/module/kernel/parameters/crash_kexec_post_notifiers and /sys/module/printk/parameters/always_kmsg_dump, that control writes into pstore. The first enables storing of the kernel log (including stack trace) into pstore upon a panic or crash, and the second enables storing of the kernel log upon a normal shutdown (shutdown, reboot, halt). These parameters can be managed via the tmpfiles.d(5) mechanism, specifically the file /usr/lib/tmpfiles/systemd-pstore.conf.

## USAGE
Data stored in the journal can be viewed with journalctl(1) as usual.

## SEE ALSO
pstore.conf(5)


systemd-quotacheck.service

title: systemd-quotacheck.service(8)

summary: File system quota checker logic

text:
# systemd-quotacheck.service(8)

## NAME
systemd-quotacheck.service, systemd-quotacheck - File system quota checker logic

## SYNOPSIS
systemd-quotacheck.service

/lib/systemd/systemd-quotacheck

## DESCRIPTION
systemd-quotacheck.service is a service responsible for file system quota checks. It is run once at boot after all necessary file systems are mounted. It is pulled in only if at least one file system has quotas enabled.

## KERNEL COMMAND LINE
systemd-quotacheck understands one kernel command line parameter:

quotacheck.mode=

One of "auto", "force", "skip". Controls the mode of operation. The default is "auto", and ensures that file system quota checks are done when the file system quota checker deems them necessary. "force" unconditionally results in full file system quota checks. "skip" skips any file system quota checks.

## SEE ALSO
systemd(1), quotacheck(8), systemd-fsck@.service(8)


systemd-random-seed.service

title: systemd-random-seed.service(8)

text:
# systemd-random-seed.service(8)

## NAME
systemd-random-seed.service, systemd-random-seed - Load and save the system random seed at boot and shutdown

## SYNOPSIS
systemd-random-seed.service

/lib/systemd/random-seed

## DESCRIPTION
systemd-random-seed.service is a service that loads an on-disk random seed into the kernel entropy pool during boot and saves it at shutdown. See random(4) for details. By default, no entropy is credited when the random seed is written into the kernel entropy pool, but this may be changed with $SYSTEMD_RANDOM_SEED_CREDIT, see below. On disk the random seed is stored in /var/lib/systemd/random-seed.

Note that this service runs relatively late during the early boot phase, i.e. generally after the initial RAM disk (initrd) completed its work, and the /var/ file system has been mounted writable. Many system services require entropy much earlier than this — this service is hence of limited use for complex system. It is recommended to use a boot loader that can pass an initial random seed to the kernel to ensure that entropy is available from earliest boot on, for example systemd-boot(7), with its bootctl random-seed functionality.

When loading the random seed from disk, the file is immediately updated with a new seed retrieved from the kernel, in order to ensure no two boots operate with the same random seed. This new seed is retrieved synchronously from the kernel, which means the service will not complete start-up until the random pool is fully initialized. On entropy-starved systems this may take a while. This functionality is intended to be used as synchronization point for ordering services that require an initialized entropy pool to function securely (i.e. services that access /dev/urandom without any further precautions).

Care should be taken when creating OS images that are replicated to multiple systems: if the random seed file is included unmodified each system will initialize its entropy pool with the same data, and thus — if otherwise entropy-starved — generate the same or at least guessable random seed streams. As a safety precaution crediting entropy is thus disabled by default. It is recommended to remove the random seed from OS images intended for replication on multiple systems, in which case it is safe to enable entropy crediting, see below.

See Random Seeds[1] for further information.

## ENVIRONMENT
$SYSTEMD_RANDOM_SEED_CREDIT

By default, systemd-random-seed.service does not credit any entropy when loading the random seed. With this option this behaviour may be changed: it either takes a boolean parameter or the special string "force". Defaults to false, in which case no entropy is credited. If true, entropy is credited if the random seed file and system state pass various superficial concisistency checks. If set to "force" entropy is credited, regardless of these checks, as long as the random seed file exists.

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

## NOTES
1.

Random Seeds

https://systemd.io/RANDOM_SEEDS


systemd-rc-local-generator

title: systemd-rc-local-generator(8)

text:
# systemd-rc-local-generator(8)

## NAME
systemd-rc-local-generator, rc-local.service - Compatibility generator and service to start /etc/rc.d/rc.local during boot

## SYNOPSIS
/lib/systemd/system-generators/systemd-rc-local-generator

rc-local.service

## DESCRIPTION
systemd-rc-local-generator is a generator that checks whether /etc/rc.d/rc.local exists and is executable, and if it is, pulls the rc-local.service unit into the boot process. This unit is responsible for running this script during late boot. The script is run after network.target, but in parallel with most other regular system services.

Note that rc-local.service runs with slightly different semantics than the original System V version, which was executed "last" in the boot process, which is a concept that does not translate to systemd.

Also note that rc-local.service is ordered after network.target, which does not mean that the network is functional, see systemd.special(7). If the script requires a configured network connection, it may be desirable to pull in and order it after network-online.target with a drop-in:

```
# /etc/systemd/system/rc-local.service.d/network.conf
[Unit]
Wants=network-online.target
After=network-online.target
```

Support for /etc/rc.d/rc.local is provided for compatibility with specific System V systems only. However, it is strongly recommended to avoid making use of this script today, and instead provide proper unit files with appropriate dependencies for any scripts to run during the boot process. Note that the path to the script is set at compile time and varies between distributions.

systemd-rc-local-generator implements systemd.generator(7).

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


systemd-remount-fs.service

title: systemd-remount-fs.service(8)

summary: Remount root and kernel file systems

text:
# systemd-remount-fs.service(8)

## NAME
systemd-remount-fs.service, systemd-remount-fs - Remount root and kernel file systems

## SYNOPSIS
systemd-remount-fs.service

/lib/systemd/systemd-remount-fs

## DESCRIPTION
systemd-remount-fs.service is an early boot service that applies mount options listed in fstab(5), or gathered from the partition table (when systemd-gpt-auto-generator(8) is active) to the root file system, the /usr/ file system, and the kernel API file systems. This is required so that the mount options of these file systems — which are pre-mounted by the kernel, the initial RAM disk, container environments or system manager code — are updated to those configured in /etc/fstab and the other sources. This service ignores normal file systems and only changes the root file system (i.e. /), /usr/, and the virtual kernel API file systems such as /proc/, /sys/ or /dev/. This service executes no operation if no configuration is found (/etc/fstab does not exist or lists no entries for the mentioned file systems, or the partition table does not contain relevant entries).

For a longer discussion of kernel API file systems see API File Systems[1].

Note: systemd-remount-fs.service is usually pulled in by systemd-fstab-generator(8), hence it is also affected by the kernel command line option fstab=, which may be used to disable the generator. It may also pulled in by systemd-gpt-auto-generator(8), which is affected by systemd.gpt_auto and other options.

## SEE ALSO
systemd(1), fstab(5), mount(8), systemd-fstab-generator(8), systemd-gpt-auto-generator(8)

## NOTES
1.

API File Systems

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


systemd-repart

title: systemd-repart(8)

summary: Automatically grow and add partitions

text:
# systemd-repart(8)

## NAME
systemd-repart, systemd-repart.service - Automatically grow and add partitions

## SYNOPSIS
systemd-repart [OPTIONS...] [[BLOCKDEVICE]...]

systemd-repart.service

## DESCRIPTION
systemd-repart grows and adds partitions to a partition table, based on the configuration files described in repart.d(5).

If invoked with no arguments, it operates on the block device backing the root file system partition of the running OS, thus growing and adding partitions of the booted OS image itself. If --image= is used it will operate on the specified image file. When called in the "initrd" it operates on the block device backing /sysroot/ instead, i.e. on the block device the system will soon transition into. The systemd-repart.service service is generally run at boot in the initial RAM disk, in order to augment the partition table of the OS before its partitions are mounted. systemd-repart (mostly) operates in a purely incremental mode: it only grows existing and adds new partitions; it does not shrink, delete or move existing partitions. The service is intended to be run on every boot, but when it detects that the partition table already matches the installed repart.d/*.conf configuration files, it executes no operation.

systemd-repart is intended to be used when deploying OS images, to automatically adjust them to the system they are running on, during first boot. This way the deployed image can be minimal in size and may be augmented automatically at boot when needed, taking possession of disk space available but not yet used. Specifically the following use cases are among those covered:

•The root partition may be grown to cover the whole available disk space.

•A /home/, swap or /srv/ partition can be added.

•A second (or third, ...) root partition may be added, to cover A/B style setups where a second version of the root file system is alternatingly used for implementing update schemes. The deployed image would carry only a single partition ("A") but on first boot a second partition ("B") for this purpose is automatically created.

The algorithm executed by systemd-repart is roughly as follows:

1.The repart.d/*.conf configuration files are loaded and parsed, and ordered by filename (without the directory prefix).

2.The partition table already existing on the block device is loaded and parsed.

3.The existing partitions in the partition table are matched up with the repart.d/*.conf files by GPT partition type UUID. The first existing partition of a specific type is assigned the first configuration file declaring the same type. The second existing partition of a specific type is then assigned the second configuration file declaring the same type, and so on. After this iterative assigning is complete any left-over existing partitions that have no matching configuration file are considered "foreign" and left as they are. And any configuration files for which no partition currently exists are understood as a request to create such a partition.

4.Taking the size constraints and weights declared in the configuration files into account, all partitions that shall be created are now allocated to the disk, taking up all free space, always respecting the size and padding requests. Similar, existing partitions that are determined to grow are grown. New partitions are always appended to the end of the existing partition table, taking the first partition table slot whose index is greater than the indexes of all existing partitions. Partition table slots are never reordered and thus partition numbers are ensured to remain stable. Note that this allocation happens in RAM only, the partition table on disk is not updated yet.

5.All existing partitions for which configuration files exist and which currently have no GPT partition label set will be assigned a label, either explicitly configured in the configuration or (if that's missing) derived automatically from the partition type. The same is done for all partitions that are newly created. These assignments are done in RAM only, too, the disk is not updated yet.

6.Similarly, all existing partitions for which configuration files exist and which currently have an all-zero identifying UUID will be assigned a new UUID. This UUID is cryptographically hashed from a common seed value together with the partition type UUID (and a counter in case multiple partitions of the same type are defined), see below. The same is done for all partitions that are created anew. These assignments are done in RAM only, too, the disk is not updated yet.

7.Similarly, if the disk's volume UUID is all zeroes it is also initialized, also cryptographically hashed from the same common seed value. Also, in RAM only, too.

8.The disk space assigned to new partitions (i.e. what was previously considered free space but is no longer) is now erased. Specifically, all file system signatures are removed, and if the device supports it the BLKDISCARD I/O control command is issued to inform the hardware that the space is empty now. In addition any "padding" between partitions and at the end of the device is similarly erased.

9.The new partition table is finally written to disk. The kernel is asked to reread the partition table.

As exception to the normally strictly incremental operation, when called in a special "factory reset" mode, systemd-repart may also be used to erase existing partitions to reset an installation back to vendor defaults. This mode of operation is used when either the --factory-reset=yes switch is passed on the tool's command line, or the systemd.factory_reset=yes option specified on the kernel command line, or the FactoryReset EFI variable (vendor UUID 8cf2644b-4b0b-428f-9387-6d876050dc67) is set to "yes". It alters the algorithm above slightly: between the 3rd and the 4th step above any partition marked explicitly via the FactoryReset= boolean is deleted, and the algorithm restarted, thus immediately re-creating these partitions anew empty.

Note that systemd-repart only changes partition tables, it does not create or resize any file systems within these partitions. A separate mechanism should be used for that, for example systemd-growfs(8) and systemd-makefs.

The UUIDs identifying the new partitions created (or assigned to existing partitions that have no UUID yet), as well as the disk as a whole are hashed cryptographically from a common seed value. This seed value is usually the machine-id(5) of the system, so that the machine ID reproducibly determines the UUIDs assigned to all partitions. If the machine ID cannot be read (or the user passes --seed=random, see below) the seed is generated randomly instead, so that the partition UUIDs are also effectively random. The seed value may also be set explicitly, formatted as UUID via the --seed= option. By hashing these UUIDs from a common seed images prepared with this tool become reproducible and the result of the algorithm above deterministic.

The positional argument should specify the block device to operate on. Instead of a block device node path a regular file may be specified too, in which case the command operates on it like it would if a loopback block device node was specified with the file attached. If --empty=create is specified the specified path is created as regular file, which is useful for generating disk images from scratch.

## OPTIONS
The following options are understood:

--dry-run=

Takes a boolean. If this switch is not specified --dry-run=yes is the implied default. Controls whether systemd-repart executes the requested re-partition operations or whether it should only show what it would do. Unless --dry-run=no is specified systemd-repart will not actually touch the device's partition table.

--empty=

Takes one of "refuse", "allow", "require", "force" or "create". Controls how to operate on block devices that are entirely empty, i.e. carry no partition table/disk label yet. If this switch is not specified the implied default is "refuse". If "refuse" systemd-repart requires that the block device it shall operate on already carries a partition table and refuses operation if none is found. If "allow" the command will extend an existing partition table or create a new one if none exists. If "require" the command will create a new partition table if none exists so far, and refuse operation if one already exists. If "force" it will create a fresh partition table unconditionally, erasing the disk fully in effect. If "force" no existing partitions will be taken into account or survive the operation. Hence: use with care, this is a great way to lose all your data. If "create" a new loopback file is create under the path passed via the device node parameter, of the size indicated with --size=, see below.

--discard=

Takes a boolean. If this switch is not specified --discard=yes is the implied default. Controls whether to issue the BLKDISCARD I/O control command on the space taken up by any added partitions or on the space in between them. Usually, it's a good idea to issue this request since it tells the underlying hardware that the covered blocks shall be considered empty, improving performance. If operating on a regular file instead of a block device node, a sparse file is generated.

--size=

Takes a size in bytes, using the usual K, M, G, T suffixes, or the special value "auto". If used the specified device node path must refer to a regular file, which is then grown to the specified size if smaller, before any change is made to the partition table. If specified as "auto" the minimal size for the disk image is automatically determined (i.e. the minimal sizes of all partitions are summed up, taking space for additional metadata into account). This switch is not supported if the specified node is a block device. This switch has no effect if the file is already as large as the specified size or larger. The specified size is implicitly rounded up to multiples of 4096. When used with --empty=create this specifies the initial size of the loopback file to create. The --size=auto option takes the sizes of pre-existing partitions into account. However, it does not accommodate for partition tables that are not tightly packed: the configured partitions might still not fit into the backing device if empty space exists between pre-existing partitions (or before the first partition) that cannot be fully filled by partitions to grow or create.

Also note that the automatic size determination does not take files or directories specified with CopyFiles= into account: operation might fail if the specified files or directories require more disk space then the configured per-partition minimal size limit.

--factory-reset=

Takes boolean. If this switch is not specified --factory=reset=no is the implied default. Controls whether to operate in "factory reset" mode, see above. If set to true this will remove all existing partitions marked with FactoryReset= set to yes early while executing the re-partitioning algorithm. Use with care, this is a great way to lose all your data. Note that partition files need to explicitly turn FactoryReset= on, as the option defaults to off. If no partitions are marked for factory reset this switch has no effect. Note that there are two other methods to request factory reset operation: via the kernel command line and via an EFI variable, see above.

--can-factory-reset

If this switch is specified the disk is not re-partitioned. Instead it is determined if any existing partitions are marked with FactoryReset=. If there are the tool will exit with exit status zero, otherwise non-zero. This switch may be used to quickly determine whether the running system supports a factory reset mechanism built on systemd-repart.

--root=

Takes a path to a directory to use as root file system when searching for repart.d/*.conf files, for the machine ID file to use as seed and for the CopyFiles= and CopyBlocks= source files and directories. By default when invoked on the regular system this defaults to the host's root file system /. If invoked from the initial RAM disk this defaults to /sysroot/, so that the tool operates on the configuration and machine ID stored in the root file system later transitioned into itself.

--image=

Takes a path to a disk image file or device to mount and use in a similar fashion to --root=, see above.

--seed=

Takes a UUID as argument or the special value random. If a UUID is specified the UUIDs to assign to partitions and the partition table itself are derived via cryptographic hashing from it. If not specified it is attempted to read the machine ID from the host (or more precisely, the root directory configured via --root=) and use it as seed instead, falling back to a randomized seed otherwise. Use --seed=random to force a randomized seed. Explicitly specifying the seed may be used to generated strictly reproducible partition tables.

--pretty=

Takes a boolean argument. If this switch is not specified, it defaults to on when called from an interactive terminal and off otherwise. Controls whether to show a user friendly table and graphic illustrating the changes applied.

--definitions=

Takes a file system path. If specified the *.conf files are read from the specified directory instead of searching in /usr/lib/repart.d/*.conf, /etc/repart.d/*.conf, /run/repart.d/*.conf.

--key-file=

Takes a file system path. Configures the encryption key to use when setting up LUKS2 volumes configured with the Encrypt=key-file setting in partition files. Should refer to a regular file containing the key, or an AF_UNIX stream socket in the file system. In the latter case a connection is made to it and the key read from it. If this switch is not specified the empty key (i.e. zero length key) is used. This behaviour is useful for setting up encrypted partitions during early first boot that receive their user-supplied password only in a later setup step.

--tpm2-device=, --tpm2-pcrs=

Configures the TPM2 device and list of PCRs to use for LUKS2 volumes configured with the Encrypt=tpm2 option. These options take the same parameters as the identically named options to systemd-cryptenroll(1) and have the same effect on partitions where TPM2 enrollment is requested.

-h, --help

Print a short help text and exit.

--version

Print a short version string and exit.

--no-pager

Do not pipe output into a pager.

--no-legend

Do not print the legend, i.e. column headers and the footer with hints.

--json=MODE

Shows output formatted as JSON. Expects one of "short" (for the shortest possible output without any redundant whitespace or line breaks), "pretty" (for a pretty version of the same, with indentation and line breaks) or "off" (to turn off JSON output, the default).

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

## SEE ALSO
systemd(1), repart.d(5), machine-id(5), systemd-cryptenroll(1)


systemd-rfkill.service

title: systemd-rfkill.service(8)

text:
# systemd-rfkill.service(8)

## NAME
systemd-rfkill.service, systemd-rfkill.socket, systemd-rfkill - Load and save the RF kill switch state at boot and change

## SYNOPSIS
systemd-rfkill.service

systemd-rfkill.socket

/lib/systemd/systemd-rfkill

## DESCRIPTION
systemd-rfkill.service is a service that restores the RF kill switch state at early boot and saves it on each change. On disk, the RF kill switch state is stored in /var/lib/systemd/rfkill/.

## KERNEL COMMAND LINE
systemd-rfkill understands the following kernel command line parameter:

systemd.restore_state=

Takes a boolean argument. Defaults to "1". If "0", does not restore the rfkill settings on boot. However, settings will still be stored on shutdown.

## SEE ALSO
systemd(1)


systemd-run-generator

title: systemd-run-generator(8)

text:
# systemd-run-generator(8)

## NAME
systemd-run-generator - Generator for invoking commands specified on the kernel command line as system service

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

## DESCRIPTION
systemd-run-generator is a generator that reads the kernel command line and understands three options:

If the systemd.run= option is specified and followed by a command line, a unit named kernel-command-line.service is generated for it and booted into. The service has Type=oneshot set, and has SuccessAction=exit and FailureAction=exit configured by default, thus ensuring that the system is shut down as soon as the command completes. The exit status of the command line is propagated to the invoking container manager, if this applies (which might propagate this further, to the calling shell — e.g. systemd-nspawn(7) does this). If this option is used multiple times the unit file will contain multiple ExecStart= lines, to execute all commands in order. The command is started as regular service, i.e. with DefaultDependencies= on.

Use systemd.run_success_action= and systemd.run_failure_action= to tweak how to react to the process completing. In particular assigning "none" will leave the system running after the command completes. For further details on supported arguments, see systemd.unit(5).

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

## EXAMPLE
Use a command like the following to add a user to the user database inside a container run with systemd-nspawn(7):

```
# systemd-nspawn -D mycontainer -b systemd.run='"adduser test"'
```

(Note the requirement for double quoting in the command line above. The first level of quoting ('') is processed and removed by the command shell used to invoke systemd-nspawn. The second level of quoting ("") is propagated to the kernel command line of the container and processed and removed by systemd-run-generator. Both together make sure both words of the specified command line adduser test end up in the generated unit file together and are neither split apart by the command shell nor by the generator.)

## SEE ALSO
systemd(1), systemctl(1), kernel-command-line(7), systemd-nspawn(7), systemd.unit(5), systemd.service(5)


systemd-socket-proxyd

title: systemd-socket-proxyd(8)

text:
# systemd-socket-proxyd(8)

## NAME
systemd-socket-proxyd - Bidirectionally proxy local sockets to another (possibly remote) socket

## SYNOPSIS
systemd-socket-proxyd [OPTIONS...] HOST:PORT

systemd-socket-proxyd [OPTIONS...] UNIX-DOMAIN-SOCKET-PATH

## DESCRIPTION
systemd-socket-proxyd is a generic socket-activated network socket forwarder proxy daemon for IPv4, IPv6 and UNIX stream sockets. It may be used to bi-directionally forward traffic from a local listening socket to a local or remote destination socket.

One use of this tool is to provide socket activation support for services that do not natively support socket activation. On behalf of the service to activate, the proxy inherits the socket from systemd, accepts each client connection, opens a connection to a configured server for each client, and then bidirectionally forwards data between the two.

This utility's behavior is similar to socat(1). The main differences for systemd-socket-proxyd are support for socket activation with "Accept=no" and an event-driven design that scales better with the number of connections.

## OPTIONS
The following options are understood:

-h, --help

Print a short help text and exit.

--version

Print a short version string and exit.

--connections-max=, -c

Sets the maximum number of simultaneous connections, defaults to 256. If the limit of concurrent connections is reached further connections will be refused.

--exit-idle-time=

Sets the time before exiting when there are no connections, defaults to infinity. Takes a unit-less value in seconds, or a time span value such as "5min 20s".

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

## EXAMPLES

### Simple Example
Use two services with a dependency and no namespace isolation.

Example 1. proxy-to-nginx.socket

```
[Socket]
ListenStream=80
[Install]
WantedBy=sockets.target
```

Example 2. proxy-to-nginx.service

```
[Unit]
Requires=nginx.service
After=nginx.service
Requires=proxy-to-nginx.socket
After=proxy-to-nginx.socket
[Service]
ExecStart=/lib/systemd/systemd-socket-proxyd /run/nginx/socket
PrivateTmp=yes
PrivateNetwork=yes
```

Example 3. nginx.conf

```
[...]
server {

    listen       unix:/run/nginx/socket;

    [...]
```

Example 4. Enabling the proxy

```
# systemctl enable --now proxy-to-nginx.socket
$ curl http://localhost:80/
```

If nginx.service has StopWhenUnneeded= set, then passing --exit-idle-time= to systemd-socket-proxyd allows both services to stop during idle periods.

### Namespace Example
Similar as above, but runs the socket proxy and the main service in the same private namespace, assuming that nginx.service has PrivateTmp= and PrivateNetwork= set, too.

Example 5. proxy-to-nginx.socket

```
[Socket]
ListenStream=80
[Install]
WantedBy=sockets.target
```

Example 6. proxy-to-nginx.service

```
[Unit]
Requires=nginx.service
After=nginx.service
Requires=proxy-to-nginx.socket
After=proxy-to-nginx.socket
JoinsNamespaceOf=nginx.service
[Service]
ExecStart=/lib/systemd/systemd-socket-proxyd 127.0.0.1:8080
PrivateTmp=yes
PrivateNetwork=yes
```

Example 7. nginx.conf

```
[...]
server {

    listen       8080;

    [...]
```

Example 8. Enabling the proxy

```
# systemctl enable --now proxy-to-nginx.socket
$ curl http://localhost:80/
```

## SEE ALSO
systemd(1), systemd.socket(5), systemd.service(5), systemctl(1), socat(1), nginx(1), curl(1)


systemd-suspend.service

title: systemd-suspend.service(8)

summary: System sleep state logic

text:
# systemd-suspend.service(8)

## NAME
systemd-suspend.service, systemd-hibernate.service, systemd-hybrid-sleep.service, systemd-suspend-then-hibernate.service, systemd-sleep - System sleep state logic

## SYNOPSIS
systemd-suspend.service

systemd-hibernate.service

systemd-hybrid-sleep.service

systemd-suspend-then-hibernate.service

/lib/systemd/system-sleep

## DESCRIPTION
systemd-suspend.service is a system service that is pulled in by suspend.target and is responsible for the actual system suspend. Similarly, systemd-hibernate.service is pulled in by hibernate.target to execute the actual hibernation. Finally, systemd-hybrid-sleep.service is pulled in by hybrid-sleep.target to execute hybrid hibernation with system suspend and pulled in by suspend-then-hibernate.target to execute system suspend with a timeout that will activate hibernate later.

Immediately before entering system suspend and/or hibernation systemd-suspend.service (and the other mentioned units, respectively) will run all executables in /lib/systemd/system-sleep/ and pass two arguments to them. The first argument will be "pre", the second either "suspend", "hibernate", "hybrid-sleep", or "suspend-then-hibernate" depending on the chosen action. An environment variable called "SYSTEMD_SLEEP_ACTION" will be set and contain the sleep action that is processing. This is primarily helpful for "suspend-then-hibernate" where the value of the variable will be "suspend", "hibernate", or "suspend-after-failed-hibernate" in cases where hibernation has failed. Immediately after leaving system suspend and/or hibernation the same executables are run, but the first argument is now "post". All executables in this directory are executed in parallel, and execution of the action is not continued until all executables have finished.

Note that scripts or binaries dropped in /lib/systemd/system-sleep/ are intended for local use only and should be considered hacks. If applications want to react to system suspend/hibernation and resume, they should rather use the Inhibitor interface[1].

Note that systemd-suspend.service, systemd-hibernate.service, systemd-hybrid-sleep.service, and systemd-suspend-then-hibernate.service should never be executed directly. Instead, trigger system sleep with a command such as systemctl suspend or systemctl hibernate.

Internally, this service will echo a string like "mem" into /sys/power/state, to trigger the actual system suspend. What exactly is written where can be configured in the [Sleep] section of /etc/systemd/sleep.conf or a sleep.conf.d file. See systemd-sleep.conf(5).

## OPTIONS
systemd-sleep understands the following commands:

-h, --help

Print a short help text and exit.

--version

Print a short version string and exit.

suspend, hibernate, suspend-then-hibernate, hybrid-sleep

Suspend, hibernate, suspend then hibernate, or put the system to hybrid sleep.

## SEE ALSO
systemd-sleep.conf(5), systemd(1), systemctl(1), systemd.special(7), systemd-halt.service(8)

## NOTES
1.

Inhibitor interface

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


systemd-sysctl.service

title: systemd-sysctl.service(8)

summary: Configure kernel parameters at boot

text:
# systemd-sysctl.service(8)

## NAME
systemd-sysctl.service, systemd-sysctl - Configure kernel parameters at boot

## SYNOPSIS
/lib/systemd/systemd-sysctl [OPTIONS...] [CONFIGFILE...]

systemd-sysctl.service

## DESCRIPTION
systemd-sysctl.service is an early boot service that configures sysctl(8) kernel parameters by invoking /lib/systemd/systemd-sysctl.

When invoked with no arguments, /lib/systemd/systemd-sysctl applies all directives from configuration files listed in sysctl.d(5). If one or more filenames are passed on the command line, only the directives in these files are applied.

In addition, --prefix= option may be used to limit which sysctl settings are applied.

See sysctl.d(5) for information about the configuration of sysctl settings. After sysctl configuration is changed on disk, it must be written to the files in /proc/sys/ before it takes effect. It is possible to update specific settings, or simply to reload all configuration, see Examples below.

## OPTIONS
--prefix=

Only apply rules with the specified prefix.

--cat-config

Copy the contents of config files to standard output. Before each file, the filename is printed as a comment.

--no-pager

Do not pipe output into a pager.

-h, --help

Print a short help text and exit.

--version

Print a short version string and exit.

## EXAMPLES
Example 1. Reset all sysctl settings

```
systemctl restart systemd-sysctl
```

Example 2. View coredump handler configuration

```
# sysctl kernel.core_pattern
kernel.core_pattern = |/usr/libexec/abrt-hook-ccpp %s %c %p %u %g %t %P %I
```

Example 3. Update coredump handler configuration

```
# /lib/systemd/systemd-sysctl --prefix kernel.core_pattern
```

This searches all the directories listed in sysctl.d(5) for configuration files and writes /proc/sys/kernel/core_pattern.

Example 4. Update coredump handler configuration according to a specific file

```
# /lib/systemd/systemd-sysctl 50-coredump.conf
```

This applies all the settings found in 50-coredump.conf. Either /etc/sysctl.d/50-coredump.conf, or /run/sysctl.d/50-coredump.conf, or /lib/sysctl.d/50-coredump.conf will be used, in the order of preference.

See sysctl(8) for various ways to directly apply sysctl settings.

## SEE ALSO
systemd(1), sysctl.d(5), sysctl(8),


systemd-sysext

title: systemd-sysext(8)

summary: Activates System Extension Images

text:
# systemd-sysext(8)

## NAME
systemd-sysext, systemd-sysext.service - Activates System Extension Images

## SYNOPSIS
systemd-sysext [OPTIONS...]

```
systemd-sysext.service
```

## DESCRIPTION
systemd-sysext activates/deactivates system extension images. System extension images may – dynamically at runtime — extend the /usr/ and /opt/ directory hierarchies with additional files. This is particularly useful on immutable system images where a /usr/ and/or /opt/ hierarchy residing on a read-only file system shall be extended temporarily at runtime without making any persistent modifications.

System extension images should contain files and directories similar in fashion to regular operating system tree. When one or more system extension images are activated, their /usr/ and /opt/ hierarchies are combined via "overlayfs" with the same hierarchies of the host OS, and the host /usr/ and /opt/ overmounted with it ("merging"). When they are deactivated, the mount point is disassembled — again revealing the unmodified original host version of the hierarchy ("unmerging"). Merging thus makes the extension's resources suddenly appear below the /usr/ and /opt/ hierarchies as if they were included in the base OS image itself. Unmerging makes them disappear again, leaving in place only the files that were shipped with the base OS image itself.

Files and directories contained in the extension images outside of the /usr/ and /opt/ hierarchies are not merged, and hence have no effect when included in a system extension image. In particular, files in the /etc/ and /var/ included in a system extension image will not appear in the respective hierarchies after activation.

System extension images are strictly read-only, and the host /usr/ and /opt/ hierarchies become read-only too while they are activated.

System extensions are supposed to be purely additive, i.e. they are supposed to include only files that do not exist in the underlying basic OS image. However, the underlying mechanism (overlayfs) also allows removing files, but it is recommended not to make use of this.

System extension images may be provided in the following formats:

1.Plain directories or btrfs subvolumes containing the OS tree

2.Disk images with a GPT disk label, following the Discoverable Partitions Specification[1]

3.Disk images lacking a partition table, with a naked Linux file system (e.g. squashfs or ext4)

These image formats are the same ones that systemd-nspawn(1) supports via it's --directory=/--image= switches and those that the service manager supports via RootDirectory=/RootImage=. Similar to them they may optionally carry Verity authentication information.

System extensions are automatically looked for in the directories /etc/extensions/, /run/extensions/, /var/lib/extensions/, /usr/lib/extensions/ and /usr/local/lib/extensions/. The first two listed directories are not suitable for carrying large binary images, however are still useful for carrying symlinks to them. The primary place for installing system extensions is /var/lib/extensions/. Any directories found in these search directories are considered directory based extension images, any files with the .raw suffix are considered disk image based extension images.

During boot OS extension images are activated automatically, if the systemd-sysext.service is enabled. Note that this service runs only after the underlying file systems where system extensions are searched are mounted. This means they are not suitable for shipping resources that are processed by subsystems running in earliest boot. Specifically, OS extension images are not suitable for shipping system services or systemd-sysusers(8) definitions. See Portable Services[2] for a simple mechanism for shipping system services in disk images, in a similar fashion to OS extensions. Note the different isolation on these two mechanisms: while system extension directly extend the underlying OS image with additional files that appear in a way very similar to as if they were shipped in the OS image itself and thus imply no security isolation, portable services imply service level sandboxing in one way or another. The systemd-sysext.service service is guaranteed to finish start-up before basic.target is reached; i.e. at the time regular services initialize (those which do not use DefaultDependencies=no), the files and directories system extensions provide are available in /usr/ and /opt/ and may be accessed.

Note that there is no concept of enabling/disabling installed system extension images: all installed extension images are automatically activated at boot.

A simple mechanism for version compatibility is enforced: a system extension image must carry a /usr/lib/extension-release.d/extension-release.$name file, which must match its image name, that is compared with the host os-release file: the contained ID= fields have to match, as well as the SYSEXT_LEVEL= field (if defined). If the latter is not defined, the VERSION_ID= field has to match instead. System extensions should not ship a /usr/lib/os-release file (as that would be merged into the host /usr/ tree, overriding the host OS version data, which is not desirable). The extension-release file follows the same format and semantics, and carries the same content, as the os-release file of the OS, but it describes the resources carried in the extension image.

## USES
The primary use case for system images are immutable environments where debugging and development tools shall optionally be made available, but not included in the immutable base OS image itself (e.g. strace(1) and gdb(1) shall be an optionally installable addition in order to make debugging/development easier). System extension images should not be misunderstood as a generic software packaging framework, as no dependency scheme is available: system extensions should carry all files they need themselves, except for those already shipped in the underlying host system image. Typically, system extension images are built at the same time as the base OS image — within the same build system.

Another use case for the system extension concept is temporarily overriding OS supplied resources with newer ones, for example to install a locally compiled development version of some low-level component over the immutable OS image without doing a full OS rebuild or modifying the nominally immutable image. (e.g. "install" a locally built package with DESTDIR=/var/lib/extensions/mytest make install && systemd-sysext refresh, making it available in /usr/ as if it was installed in the OS image itself.) This case works regardless if the underlying host /usr/ is managed as immutable disk image or is a traditional package manager controlled (i.e. writable) tree.

## COMMANDS
The following commands are understood:

status

When invoked without any command verb, or when status is specified the current merge status is shown, separately for both /usr/ and /opt/.

merge

Merges all currently installed system extension images into /usr/ and /opt/, by overmounting these hierarchies with an "overlayfs" file system combining the underlying hierarchies with those included in the extension images. This command will fail if the hierarchies are already merged.

unmerge

Unmerges all currently installed system extension images from /usr/ and /opt/, by unmounting the "overlayfs" file systems created by merge prior.

refresh

A combination of unmerge and merge: if already mounted the existing "overlayfs" instance is unmounted temporarily, and then replaced by a new version. This command is useful after installing/removing system extension images, in order to update the "overlayfs" file system accordingly. If no system extensions are installed when this command is executed, the equivalent of unmerge is executed, without establishing any new "overlayfs" instance. Note that currently there's a brief moment where neither the old nor the new "overlayfs" file system is mounted. This implies that all resources supplied by a system extension will briefly disappear — even if it exists continuously during the refresh operation.

list

A brief list of installed extension images is shown.

-h, --help

Print a short help text and exit.

--version

Print a short version string and exit.

## OPTIONS
--root=

Operate relative to the specified root directory, i.e. establish the "overlayfs" mount not on the top-level host /usr/ and /opt/ hierarchies, but below some specified root directory.

--force

When merging system extensions into /usr/ and /opt/, ignore version incompatibilities, i.e. force merging regardless of whether the version information included in the extension images matches the host or not.

--no-pager

Do not pipe output into a pager.

--no-legend

Do not print the legend, i.e. column headers and the footer with hints.

--json=MODE

Shows output formatted as JSON. Expects one of "short" (for the shortest possible output without any redundant whitespace or line breaks), "pretty" (for a pretty version of the same, with indentation and line breaks) or "off" (to turn off JSON output, the default).

## EXIT STATUS
On success, 0 is returned.

## SEE ALSO
systemd(1), systemd-nspawn(1)

## NOTES
1.

Discoverable Partitions Specification

https://systemd.io/DISCOVERABLE_PARTITIONS

2.

Portable Services

https://systemd.io/PORTABLE_SERVICES


systemd-system-update-generator

title: systemd-system-update-generator(8)

text:
# systemd-system-update-generator(8)

## NAME
systemd-system-update-generator - Generator for redirecting boot to offline update mode

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

## DESCRIPTION
systemd-system-update-generator is a generator that automatically redirects the boot process to system-update.target, if /system-update exists. This is required to implement the logic explained in the systemd.offline-updates(7).

systemd-system-update-generator implements systemd.generator(7).

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


systemd-sysv-generator

title: systemd-sysv-generator(8)

summary: Unit generator for SysV init scripts

text:
# systemd-sysv-generator(8)

## NAME
systemd-sysv-generator - Unit generator for SysV init scripts

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

## DESCRIPTION
systemd-sysv-generator is a generator that creates wrapper .service units for SysV init[1] scripts in /etc/init.d/* at boot and when configuration of the system manager is reloaded. This will allow systemd(1) to support them similarly to native units.

LSB headers[2] in SysV init scripts are interpreted, and the ordering specified in the header is turned into dependencies between the generated unit and other units. The LSB facilities "$remote_fs", "$network", "$named", "$portmap", "$time" are supported and will be turned into dependencies on specific native systemd targets. See systemd.special(7) for more details.

SysV runlevels have corresponding systemd targets (runlevelX.target). The wrapper unit that is generated will be wanted by those targets which correspond to runlevels for which the script is enabled.

systemd does not support SysV scripts as part of early boot, so all wrapper units are ordered after basic.target.

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

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

## NOTES
1.

SysV init

https://savannah.nongnu.org/projects/sysvinit

2.

LSB headers

http://refspecs.linuxbase.org/LSB_3.1.1/LSB-Core-generic/LSB-Core-generic/iniscrptact.html


systemd-timedated.service

title: systemd-timedated.service(8)

summary: Time and date bus mechanism

text:
# systemd-timedated.service(8)

## NAME
systemd-timedated.service, systemd-timedated - Time and date bus mechanism

## SYNOPSIS
systemd-timedated.service

/lib/systemd/systemd-timedated

## DESCRIPTION
systemd-timedated.service is a system service that may be used as a mechanism to change the system clock and timezone, as well as to enable/disable network time synchronization. systemd-timedated is automatically activated on request and terminates itself when it is unused.

The tool timedatectl(1) is a command line client to this service.

systemd-timedated currently offers access to the following four settings:

•The system time

•The system timezone

•A boolean controlling whether the system RTC is in local or UTC timezone

•Whether the time synchronization service is enabled/started or disabled/stopped, see next section.

See org.freedesktop.timedate1(5) and org.freedesktop.LogControl1(5) for information about the D-Bus API.

## LIST OF NETWORK TIME SYNCHRONIZATION SERVICES
systemd-timesyncd will look for files with a ".list" extension in ntp-units.d/ directories. Each file is parsed as a list of unit names, one per line. Empty lines and lines with comments ("#") are ignored. Files are read from /lib/systemd/ntp-units.d/ and the corresponding directories under /etc/, /run/, /usr/local/lib/. Files in /etc/ override files with the same name in /run/, /usr/local/lib/, and /usr/lib/. Files in /run/ override files with the same name under /usr/. Packages should install their configuration files in /usr/lib/ (distribution packages) or /usr/local/lib/ (local installs).

Example 1. ntp-units.d/ entry for systemd-timesyncd

```
# /lib/systemd/ntp-units.d/80-systemd-timesync.list
systemd-timesyncd.service
```

If the environment variable $SYSTEMD_TIMEDATED_NTP_SERVICES is set, systemd-timesyncd will parse the contents of that variable as a colon-separated list of unit names. When set, this variable overrides the file-based list described above.

Example 2. An override that specifies that chronyd should be used if available

```
SYSTEMD_TIMEDATED_NTP_SERVICES=chronyd.service:systemd-timesyncd.service
```

## SEE ALSO
systemd(1), timedatectl(1), localtime(5), hwclock(8), systemd-timesyncd(8)


systemd-tmpfiles

title: systemd-tmpfiles(8)

text:
# systemd-tmpfiles(8)

## NAME
systemd-tmpfiles, systemd-tmpfiles-setup.service, systemd-tmpfiles-setup-dev.service, systemd-tmpfiles-clean.service, systemd-tmpfiles-clean.timer - Creates, deletes and cleans up volatile and temporary files and directories

## SYNOPSIS
systemd-tmpfiles [OPTIONS...] [CONFIGFILE...]

System units:

```
systemd-tmpfiles-setup.service
systemd-tmpfiles-setup-dev.service
systemd-tmpfiles-clean.service
systemd-tmpfiles-clean.timer
```

User units:

```
systemd-tmpfiles-setup.service
systemd-tmpfiles-clean.service
systemd-tmpfiles-clean.timer
```

## DESCRIPTION
systemd-tmpfiles creates, deletes, and cleans up volatile and temporary files and directories, using the configuration file format and location specified in tmpfiles.d(5). It must be invoked with one or more options --create, --remove, and --clean, to select the respective subset of operations.

By default, directives from all configuration files are applied. When invoked with --replace=PATH, arguments specified on the command line are used instead of the configuration file PATH. Otherwise, if one or more absolute filenames are passed on the command line, only the directives in these files are applied. If "-" is specified instead of a filename, directives are read from standard input. If only the basename of a configuration file is specified, all configuration directories as specified in tmpfiles.d(5) are searched for a matching file and the file found that has the highest priority is executed.

System services (systemd-tmpfiles-setup.service, systemd-tmpfiles-setup-dev.service, systemd-tmpfiles-clean.service) invoke systemd-tmpfiles to create system files and to perform system wide cleanup. Those services read administrator-controlled configuration files in tmpfiles.d/ directories. User services (systemd-tmpfiles-setup.service, systemd-tmpfiles-clean.service) also invoke systemd-tmpfiles, but it reads a separate set of files, which includes user-controlled files under ~/.config/user-tmpfiles.d/ and ~/.local/share/user-tmpfiles.d/, and administrator-controlled files under /usr/share/user-tmpfiles.d/. Users may use this to create and clean up files under their control, but the system instance performs global cleanup and is not influenced by user configuration. Note that this means a time-based cleanup configured in the system instance, such as the one typically configured for /tmp/, will thus also affect files created by the user instance if they are placed in /tmp/, even if the user instance's time-based cleanup is turned off.

To re-apply settings after configuration has been modified, simply restart systemd-tmpfiles-clean.service, which will apply any settings which can be safely executed at runtime. To debug systemd-tmpfiles, it may be useful to invoke it directly from the command line with increased log level (see $SYSTEMD_LOG_LEVEL below).

## OPTIONS
The following options are understood:

--create

If this option is passed, all files and directories marked with f, F, w, d, D, v, p, L, c, b, m in the configuration files are created or written to. Files and directories marked with z, Z, t, T, a, and A have their ownership, access mode and security labels set.

--clean

If this option is passed, all files and directories with an age parameter configured will be cleaned up.

--remove

If this option is passed, the contents of directories marked with D or R, and files or directories themselves marked with r or R are removed.

--user

Execute "user" configuration, i.e. tmpfiles.d files in user configuration directories.

--boot

Also execute lines with an exclamation mark.

--prefix=path

Only apply rules with paths that start with the specified prefix. This option can be specified multiple times.

--exclude-prefix=path

Ignore rules with paths that start with the specified prefix. This option can be specified multiple times.

-E

A shortcut for "--exclude-prefix=/dev --exclude-prefix=/proc --exclude-prefix=/run --exclude-prefix=/sys", i.e. exclude the hierarchies typically backed by virtual or memory file systems. This is useful in combination with --root=, if the specified directory tree contains an OS tree without these virtual/memory file systems mounted in, as it is typically not desirable to create any files and directories below these subdirectories if they are supposed to be overmounted during runtime.

--root=root

Takes a directory path as an argument. All paths will be prefixed with the given alternate root path, including config search paths. When this option is used, the libc Name Service Switch (NSS) is bypassed for resolving users and groups. Instead the files /etc/passwd and /etc/group inside the alternate root are read directly. This means that users/groups not listed in these files will not be resolved, i.e. LDAP NIS and other complex databases are not considered.

Consider combining this with -E to ensure the invocation does not create files or directories below mount points in the OS image operated on that are typically overmounted during runtime.

--image=image

Takes a path to a disk image file or block device node. If specified all operations are applied to file system in the indicated disk image. This is similar to --root= but operates on file systems stored in disk images or block devices. The disk image should either contain just a file system or a set of file systems within a GPT partition table, following the Discoverable Partitions Specification[1]. For further information on supported disk images, see systemd-nspawn(1)'s switch of the same name. Implies -E.

--replace=PATH

When this option is given, one ore more positional arguments must be specified. All configuration files found in the directories listed in tmpfiles.d(5) will be read, and the configuration given on the command line will be handled instead of and with the same priority as the configuration file PATH. This option is intended to be used when package installation scripts are running and files belonging to that package are not yet available on disk, so their contents must be given on the command line, but the admin configuration might already exist and should be given higher priority.

--cat-config

Copy the contents of config files to standard output. Before each file, the filename is printed as a comment.

--no-pager

Do not pipe output into a pager.

-h, --help

Print a short help text and exit.

--version

Print a short version string and exit.

It is possible to combine --create, --clean, and --remove in one invocation (in which case removal and cleanup are executed before creation of new files). For example, during boot the following command line is executed to ensure that all temporary and volatile directories are removed and created according to the configuration file:

```
systemd-tmpfiles --remove --create
```

## ENVIRONMENT
$SYSTEMD_LOG_LEVEL

The maximum log level of emitted messages (messages with a higher log level, i.e. less important ones, will be suppressed). Either one of (in order of decreasing importance) emerg, alert, crit, err, warning, notice, info, debug, or an integer in the range 0...7. See syslog(3) for more information.

$SYSTEMD_LOG_COLOR

A boolean. If true, messages written to the tty will be colored according to priority. This setting is only useful when messages are written directly to the terminal, because journalctl(1) and other tools that display logs will color messages based on the log level on their own.

$SYSTEMD_LOG_TIME

A boolean. If true, console log messages will be prefixed with a timestamp. This setting is only useful when messages are written directly to the terminal or a file, because journalctl(1) and other tools that display logs will attach timestamps based on the entry metadata on their own.

$SYSTEMD_LOG_LOCATION

A boolean. If true, messages will be prefixed with a filename and line number in the source code where the message originates. Note that the log location is often attached as metadata to journal entries anyway. Including it directly in the message text can nevertheless be convenient when debugging programs.

$SYSTEMD_LOG_TARGET

The destination for log messages. One of console (log to the attached tty), console-prefixed (log to the attached tty but with prefixes encoding the log level and "facility", see syslog(3), kmsg (log to the kernel circular log buffer), journal (log to the journal), journal-or-kmsg (log to the journal if available, and to kmsg otherwise), auto (determine the appropriate log target automatically, the default), null (disable log output).

$SYSTEMD_PAGER

Pager to use when --no-pager is not given; overrides $PAGER. If neither $SYSTEMD_PAGER nor $PAGER are set, a set of well-known pager implementations are tried in turn, including less(1) and more(1), until one is found. If no pager implementation is discovered no pager is invoked. Setting this environment variable to an empty string or the value "cat" is equivalent to passing --no-pager.

$SYSTEMD_LESS

Override the options passed to less (by default "FRSXMK"). Users might want to change two options in particular:

K

This option instructs the pager to exit immediately when Ctrl+C is pressed. To allow less to handle Ctrl+C itself to switch back to the pager command prompt, unset this option. If the value of $SYSTEMD_LESS does not include "K", and the pager that is invoked is less, Ctrl+C will be ignored by the executable, and needs to be handled by the pager.

X

This option instructs the pager to not send termcap initialization and deinitialization strings to the terminal. It is set by default to allow command output to remain visible in the terminal even after the pager exits. Nevertheless, this prevents some pager functionality from working, in particular paged output cannot be scrolled with the mouse.

See less(1) for more discussion.

$SYSTEMD_LESSCHARSET

Override the charset passed to less (by default "utf-8", if the invoking terminal is determined to be UTF-8 compatible).

$SYSTEMD_PAGERSECURE

Takes a boolean argument. When true, the "secure" mode of the pager is enabled; if false, disabled. If $SYSTEMD_PAGERSECURE is not set at all, secure mode is enabled if the effective UID is not the same as the owner of the login session, see geteuid(2) and sd_pid_get_owner_uid(3). In secure mode, LESSSECURE=1 will be set when invoking the pager, and the pager shall disable commands that open or create new files or start new subprocesses. When $SYSTEMD_PAGERSECURE is not set at all, pagers which are not known to implement secure mode will not be used. (Currently only less(1) implements secure mode.) Note: when commands are invoked with elevated privileges, for example under sudo(8) or pkexec(1), care must be taken to ensure that unintended interactive features are not enabled. "Secure" mode for the pager may be enabled automatically as describe above. Setting SYSTEMD_PAGERSECURE=0 or not removing it from the inherited environment allows the user to invoke arbitrary commands. Note that if the $SYSTEMD_PAGER or $PAGER variables are to be honoured, $SYSTEMD_PAGERSECURE must be set too. It might be reasonable to completely disable the pager using --no-pager instead.

$SYSTEMD_COLORS

Takes a boolean argument. When true, systemd and related utilities will use colors in their output, otherwise the output will be monochrome. Additionally, the variable can take one of the following special values: "16", "256" to restrict the use of colors to the base 16 or 256 ANSI colors, respectively. This can be specified to override the automatic decision based on $TERM and what the console is connected to.

$SYSTEMD_URLIFY

The value must be a boolean. Controls whether clickable links should be generated in the output for terminal emulators supporting this. This can be specified to override the decision that systemd makes based on $TERM and other conditions.

## UNPRIVILEGED --CLEANUP OPERATION
systemd-tmpfiles tries to avoid changing the access and modification times on the directories it accesses, which requires CAP_FOWNER privileges. When running as non-root, directories which are checked for files to clean up will have their access time bumped, which might prevent their cleanup.

## EXIT STATUS
On success, 0 is returned. If the configuration was syntactically invalid (syntax errors, missing arguments, ...), so some lines had to be ignored, but no other errors occurred, 65 is returned (EX_DATAERR from /usr/include/sysexits.h). If the configuration was syntactically valid, but could not be executed (lack of permissions, creation of files in missing directories, invalid contents when writing to /sys/ values, ...), 73 is returned (EX_CANTCREAT from /usr/include/sysexits.h). Otherwise, 1 is returned (EXIT_FAILURE from /usr/include/stdlib.h).

Note: when creating items, if the target already exists, but is of the wrong type or otherwise does not match the requested state, and forced operation has not been requested with "+", a message is emitted, but the failure is otherwise ignored.

## SEE ALSO
systemd(1), tmpfiles.d(5)

## NOTES
1.

Discoverable Partitions Specification

https://systemd.io/DISCOVERABLE_PARTITIONS


systemd-tty-ask-password-agent

title: systemd-tty-ask-password-agent(8)

text:
# systemd-tty-ask-password-agent(8)

## NAME
systemd-tty-ask-password-agent - List or process pending systemd password requests

## SYNOPSIS
systemd-tty-ask-password-agent [OPTIONS...] [VARIABLE=VALUE...]

## DESCRIPTION
systemd-tty-ask-password-agent is a password agent that handles password requests of the system, for example for hard disk encryption passwords or SSL certificate passwords that need to be queried at boot-time or during runtime.

systemd-tty-ask-password-agent implements the Password Agents Specification[1], and is one of many possible response agents which answer to queries formulated with systemd-ask-password(8).

## OPTIONS
The following options are understood:

--list

Lists all currently pending system password requests.

--query

Process all currently pending system password requests by querying the user on the calling TTY.

--watch

Continuously process password requests.

--wall

Forward password requests to wall(1) instead of querying the user on the calling TTY.

--plymouth

Ask question with plymouth(8) instead of querying the user on the calling TTY.

--console[=DEVICE]

Ask question on TTY DEVICE instead of querying the user on the calling TTY. If DEVICE is not specified, /dev/console will be used.

-h, --help

Print a short help text and exit.

--version

Print a short version string and exit.

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

## SEE ALSO
systemd(1), systemctl(1), systemd-ask-password-console.service(8), wall(1), plymouth(8)

## NOTES
1.

Password Agents Specification

https://systemd.io/PASSWORD_AGENTS/


systemd-update-done.service

title: systemd-update-done.service(8)

summary: Mark /etc/ and /var/ fully updated

text:
# systemd-update-done.service(8)

## NAME
systemd-update-done.service, systemd-update-done - Mark /etc/ and /var/ fully updated

## SYNOPSIS
systemd-update-done.service

/lib/systemd/systemd-update-done

## DESCRIPTION
systemd-update-done.service is a service that is invoked as part of the first boot after the vendor operating system resources in /usr/ have been updated. This is useful to implement offline updates of /usr/ which might require updates to /etc/ or /var/ on the following boot.

systemd-update-done.service updates the file modification time (mtime) of the stamp files /etc/.updated and /var/.updated to the modification time of the /usr/ directory, unless the stamp files are already newer.

Services that shall run after offline upgrades of /usr/ should order themselves before systemd-update-done.service, and use the ConditionNeedsUpdate= (see systemd.unit(5)) condition to make sure to run when /etc/ or /var/ are older than /usr/ according to the modification times of the files described above. This requires that updates to /usr/ are always followed by an update of the modification time of /usr/, for example by invoking touch(1) on it.

Note that if the systemd.condition-needs-update= kernel command line option is used it overrides the ConditionNeedsUpdate= unit condition checks. In that case systemd-update-done.service will not reset the condition state until a follow-up reboot where the kernel switch is not specified anymore.

## SEE ALSO
systemd(1), systemd.unit(5), touch(1)


systemd-update-utmp.service

title: systemd-update-utmp.service(8)

text:
# systemd-update-utmp.service(8)

## NAME
systemd-update-utmp.service, systemd-update-utmp-runlevel.service, systemd-update-utmp - Write audit and utmp updates at bootup, runlevel changes and shutdown

## SYNOPSIS
systemd-update-utmp.service

systemd-update-utmp-runlevel.service

/lib/systemd/systemd-update-utmp

## DESCRIPTION
systemd-update-utmp-runlevel.service is a service that writes SysV runlevel changes to utmp and wtmp, as well as the audit logs, as they occur. systemd-update-utmp.service does the same for system reboots and shutdown requests.

## SEE ALSO
systemd(1), utmp(5), auditd(8)


systemd-user-sessions.service

title: systemd-user-sessions.service(8)

text:
# systemd-user-sessions.service(8)

## NAME
systemd-user-sessions.service, systemd-user-sessions - Permit user logins after boot, prohibit user logins at shutdown

## SYNOPSIS
systemd-user-sessions.service

/lib/systemd/systemd-user-sessions

## DESCRIPTION
systemd-user-sessions.service is a service that controls user logins through pam_nologin(8). After basic system initialization is complete, it removes /run/nologin, thus permitting logins. Before system shutdown, it creates /run/nologin, thus prohibiting further logins.

## SEE ALSO
systemd(1), systemd-logind.service(8), pam_nologin(8)