systemd-pcrphase.service

title: systemd-pcrphase.service(8)

text:
# systemd-pcrphase.service(8)

## NAME
systemd-pcrphase.service, systemd-pcrphase-sysinit.service, systemd-pcrphase-initrd.service, systemd-pcrmachine.service, systemd-pcrfs-root.service, systemd-pcrfs@.service, systemd-pcrextend - Measure boot phase into TPM2 PCR 11, machine ID and file system identity into PCR 15

## SYNOPSIS
systemd-pcrphase.service

systemd-pcrphase-sysinit.service

systemd-pcrphase-initrd.service

systemd-pcrmachine.service

systemd-pcrfs-root.service

systemd-pcrfs@.service

/usr/lib/systemd/systemd-pcrextend [STRING]

## DESCRIPTION
systemd-pcrphase.service, systemd-pcrphase-sysinit.service, and systemd-pcrphase-initrd.service are system services that measure specific strings into TPM2 PCR 11 during boot at various milestones of the boot process.

systemd-pcrmachine.service is a system service that measures the machine ID (see machine-id(5)) into PCR 15.

systemd-pcrfs-root.service and systemd-pcrfs@.service are services that measure file system identity information (i.e. mount point, file system type, label and UUID, partition label and UUID) into PCR 15. systemd-pcrfs-root.service does so for the root file system, systemd-pcrfs@.service is a template unit that measures the file system indicated by its instance identifier instead.

These services require systemd-stub(7) to be used in a unified kernel image (UKI). They execute no operation when the stub has not been used to invoke the kernel. The stub will measure the invoked kernel and associated vendor resources into PCR 11 before handing control to it; once userspace is invoked these services then will extend TPM2 PCR 11 with certain literal strings indicating phases of the boot process. During a regular boot process PCR 11 is extended with the following strings:

1."enter-initrd" — early when the initrd initializes, before activating system extension images for the initrd. It acts as a barrier between the time where the kernel initializes and where the initrd starts operating and enables system extension images, i.e. code shipped outside of the UKI. (This extension happens when the systemd-pcrphase-initrd.service(8) service is started.)

2."leave-initrd" — when the initrd is about to transition into the host file system. It acts as barrier between initrd code and host OS code. (This extension happens when the systemd-pcrphase-sysinit.service(8) service is stopped.)

3."sysinit" — when basic system initialization is complete (which includes local file systems having been mounted), and the system begins starting regular system services. (This extension happens when the systemd-pcrphase-sysinit.service(8) service is started.)

4."ready" — during later boot-up, after remote file systems have been activated (i.e. after remote-fs.target), but before users are permitted to log in (i.e. before systemd-user-sessions.service). It acts as barrier between the time where unprivileged regular users are still prohibited to log in and where they are allowed to log in. (This extension happens when the systemd-pcrphase-sysinit.service(8) service is started.)

5."shutdown" — when the system shutdown begins. It acts as barrier between the time the system is fully up and running and where it is about to shut down. (This extension happens when the systemd-pcrphase.service service is stopped.)

6."final" — at the end of system shutdown. It acts as barrier between the time the service manager still runs and when it transitions into the final shutdown phase where service management is not available anymore. (This extension happens when the systemd-pcrphase-sysinit.service(8) service is stopped.)

During a regular system lifecycle, PCR 11 is extended with the strings "enter-initrd", "leave-initrd", "sysinit", "ready", "shutdown", and "final".

Specific phases of the boot process may be referenced via the series of strings measured, separated by colons (the "phase path"). For example, the phase path for the regular system runtime is "enter-initrd:leave-initrd:sysinit:ready", while the one for the initrd is just "enter-initrd". The phase path for the boot phase before the initrd is an empty string; because that's hard to pass around a single colon (":") may be used instead. Note that the aforementioned six strings are just the default strings and individual systems might measure other strings at other times, and thus implement different and more fine-grained boot phases to bind policy to.

By binding policy of TPM2 objects to a specific phase path it is possible to restrict access to them to specific phases of the boot process, for example making it impossible to access the root file system's encryption key after the system transitioned from the initrd into the host root file system.

Use systemd-measure(1) to pre-calculate expected PCR 11 values for specific boot phases (via the --phase= switch).

systemd-pcrfs-root.service and systemd-pcrfs@.service are automatically pulled into the initial transaction by systemd-gpt-auto-generator(8) for the root and /var/ file systems. systemd-fstab-generator(8) will do this for all mounts with the x-systemd.pcrfs mount option in /etc/fstab.

## OPTIONS
The /usr/lib/systemd/systemd-pcrextend executable may also be invoked from the command line, where it expects the word to extend into PCR 11, as well as the following switches:

--bank=

Takes the PCR banks to extend the specified word into. If not specified, the tool automatically determines all enabled PCR banks and measures the word into all of them. Added in version 252.

--pcr=

Takes the index of the PCR to extend. If --machine-id or --file-system= are specified defaults to 15, otherwise defaults to 11. Added in version 255.

--tpm2-device=PATH

Controls which TPM2 device to use. Expects a device node path referring to the TPM2 chip (e.g. /dev/tpmrm0). Alternatively the special value "auto" may be specified, in order to automatically determine the device node of a suitable TPM2 device (of which there must be exactly one). The special value "list" may be used to enumerate all suitable TPM2 devices currently discovered. Added in version 252.

--graceful

If no TPM2 firmware, kernel subsystem, kernel driver or device support is found, exit with exit status 0 (i.e. indicate success). If this is not specified, any attempt to measure without a TPM2 device will cause the invocation to fail. Added in version 253.

--machine-id

Instead of measuring a word specified on the command line into PCR 11, measure the host's machine ID into PCR 15. Added in version 253.

--file-system=

Instead of measuring a word specified on the command line into PCR 11, measure identity information of the specified file system into PCR 15. The parameter must be the path to the established mount point of the file system to measure. Added in version 253.

-h, --help

Print a short help text and exit.

--version

Print a short version string and exit.

## FILES
/run/log/systemd/tpm2-measure.log

Measurements are logged into an event log file maintained in /run/log/systemd/tpm2-measure.log, which contains a JSON-SEQ[1] series of objects that follow the general structure of the TCG Canonical Event Log Format (CEL-JSON)[2] event objects (but lack the "recnum" field). A LOCK_EX BSD file lock (flock(2)) on the log file is acquired while the measurement is made and the file is updated. Thus, applications that intend to acquire a consistent quote from the TPM with the associated snapshot of the event log should acquire a LOCK_SH lock while doing so.

Added in version 252.

## SEE ALSO
systemd(1), systemd-stub(7), systemd-measure(1), systemd-gpt-auto-generator(8), systemd-fstab-generator(8), TPM2 PCR Measurements Made by systemd[3]

## NOTES
1.

JSON-SEQ

https://www.rfc-editor.org/rfc/rfc7464.html

2.

TCG Canonical Event Log Format (CEL-JSON)

https://trustedcomputinggroup.org/resource/canonical-event-log-format/

3.

TPM2 PCR Measurements Made by systemd

https://systemd.io/TPM2_PCR_MEASUREMENTS


systemd-poweroff.service

package: systemd

title: systemd-poweroff.service(8)

summary: System shutdown logic

text:
# systemd-poweroff.service(8)

## NAME
systemd-poweroff.service, systemd-halt.service, systemd-reboot.service, systemd-kexec.service, systemd-shutdown - System shutdown logic

## SYNOPSIS
systemd-poweroff.service

systemd-halt.service

systemd-reboot.service

systemd-kexec.service

/usr/lib/systemd/systemd-shutdown

/usr/lib/systemd/system-shutdown/

## DESCRIPTION
systemd-poweroff.service is a system service that is pulled in by poweroff.target and is responsible for the actual system power-off operation. Similarly, systemd-halt.service is pulled in by halt.target, systemd-reboot.service by reboot.target and systemd-kexec.service by kexec.target to execute the respective actions.

When these services are run, they ensure that PID 1 is replaced by the /usr/lib/systemd/systemd-shutdown binary which is then responsible for the actual shutdown. Before shutting down, this binary will try to unmount all remaining file systems (or at least remount them read-only), disable all remaining swap devices, detach all remaining storage devices and kill all remaining processes.

It is necessary to have this code in a separate binary because otherwise rebooting after an upgrade might be broken — the running PID 1 could still depend on libraries which are not available any more, thus keeping the file system busy, which then cannot be re-mounted read-only.

Shortly before executing the actual system power-off/halt/reboot/kexec, systemd-shutdown will run all executables in /usr/lib/systemd/system-shutdown/. Those executables are called with one argument: either "poweroff", "halt", "reboot", or "kexec", depending on the chosen action. All executables in this directory are executed in parallel, and execution of the action is not continued before all executables finished. (A safety timeout of 90s is applied however.) Note that these executables are run after all services have been shut down, and after most mounts have been unmounted (the root file system as well as /run/ and various API file systems are still around though). This means any programs dropped into this directory must be prepared to run in such a limited execution environment and not rely on external services or hierarchies such as /var/ to be around (or writable).

Note that systemd-poweroff.service (and the related units) should never be executed directly. Instead, trigger system shutdown with a command such as "systemctl poweroff".

Another form of shutdown is provided by the systemd-soft-reboot.service(8) functionality. It reboots only the OS userspace, leaving the kernel, firmware, and hardware as it is.

## SEE ALSO
systemd(1), systemctl(1), systemd.special(7), reboot(2), systemd-suspend.service(8), systemd-soft-reboot.service(8), bootup(7)

branch: sisyphus


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
/usr/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-root.service, systemd-quotacheck - File system quota checker logic

## SYNOPSIS
systemd-quotacheck@.service

systemd-quotacheck-root.service

/usr/lib/systemd/systemd-quotacheck

## DESCRIPTION
systemd-quotacheck@.service and systemd-quotacheck-root.service are services responsible for file system quota checks. They run once at boot after all necessary file systems are mounted. They are 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. Added in version 186.

## CREDENTIALS
systemd-quotacheck supports the service credentials logic as implemented by ImportCredential=/LoadCredential=/SetCredential= (see systemd.exec(5) for details). The following credentials are used when passed in:

quotacheck.mode

The contents of the credential is parsed as same as the kernel command line option with the same name. See above for more details. Added in version 258.

Note that by default the systemd-quotacheck@.service and systemd-quotacheck-root.service unit files are set up to inherit quotacheck.mode credential from the service manager.

## 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 OS system random seed at boot and shutdown

## SYNOPSIS
systemd-random-seed.service

/usr/lib/systemd/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 initrd phase has finished and the /var/ file system has been mounted. 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. Also see Safely Building Images[1].

See Random Seeds[2] 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. Added in version 243.

## SEE ALSO
systemd(1), random(4), systemd-boot(7), systemd-stub(7), bootctl(1), systemd-boot-random-seed.service(8)

## NOTES
1.

Safely Building Images

https://systemd.io/BUILDING_IMAGES

2.

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
/usr/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 using 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).

## NOTES
On systems with SELinux, when creating the file, make sure to set the appropriate context, e.g. with "sudo restorecon -v /etc/rc.d/rc.local".

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

/usr/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 initrd, 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 be 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://systemd.io/API_FILE_SYSTEMS


systemd-repart

title: systemd-repart(8)

text:
# systemd-repart(8)

## NAME
systemd-repart, systemd-repart.service - Automatically grow and add partitions, and generate disk images (DDIs)

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

systemd-repart.service

## DESCRIPTION
systemd-repart creates partition tables, and adds or grows partitions, based on the configuration files described in repart.d(5).

systemd-repart is used when building OS images, and also when deploying images to automatically adjust them, during boot, to the system they are running on. This way the image can be minimal in size and may be augmented automatically at boot, taking possession of the disk space available.

If invoked with no arguments, systemd-repart operates on the block device backing the root file system partition of the running OS, thus adding and growing partitions of the booted OS itself. 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. If --image= is used, it will operate on the specified device or image file. The systemd-repart.service service is generally run at boot in the initrd, in order to augment the partition table of the OS before its partitions are mounted.

systemd-repart operations are mostly incremental: it grows existing partitions or adds new ones, but 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.

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). For each configuration file, drop-in files are loaded from directories with same name as the configuration file with the suffix ".d" added.

2.The partition table on the block device is loaded and parsed, if present.

3.The existing partitions in the partition table are matched 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 existing partitions that have no matching configuration file are considered "foreign" and left as they are. And any configuration files for which no partition was matched are treated as requests to create a partition.

4.Partitions that shall be created are now allocated on the disk, taking the size constraints and weights declared in the configuration files into account. Free space is used within the limits set by size and padding requests. In addition, existing partitions that should be grown are grown. New partitions are always appended to the end of the partition table, taking the first partition table slot whose index is greater than the indexes of all existing partitions. Partitions are never reordered and thus partition numbers remain stable. When partitions are created, they are placed in the smallest area of free space that is large enough to satisfy the size and padding limits. This means that partitions might have different order on disk than in the partition table. Note that this allocation happens in memory 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 memory 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 memory 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. This is done in memory only too.

8.The disk space assigned to new partitions (i.e. what was previously free space) 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 now empty. 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 an exception to the normal incremental operation, when called in a special "factory reset" mode, systemd-repart may 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 is specified on the kernel command line, or the FactoryResetRequest 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 by default only changes partition tables, it does not create or resize any file systems within these partitions, unless the Format= configuration option is specified. Also note that there are also separate mechanisms available for this purpose, 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 or a regular file to operate on. 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. Added in version 245.

--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.

Added in version 245.

--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 is 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. Added in version 245.

--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.

Added in version 246.

--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. Added in version 245.

--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. Added in version 245.

--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 initrd 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. See --copy-source= for a more restricted option that only affects CopyFiles=.

Added in version 245.

--image=

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

--image-policy=policy

Takes an image policy string as argument, as per systemd.image-policy(7). The policy is enforced when operating on the disk image specified via --image=, see above. If not specified, defaults to the "*" policy, i.e. all recognized file systems in the image are used.

--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. Added in version 245.

--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. Added in version 245.

--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. This parameter can be specified multiple times.

Added in version 245.

--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. Added in version 247.

--private-key=

Takes a file system path or an engine or provider specific designation. Configures the signing key to use when creating verity signature partitions with the Verity=signature setting in partition files. Added in version 252.

--private-key-source=

Takes one of "file", "engine" or "provider". In the latter two cases, it is followed by the name of a provider or engine, separated by colon, that will be passed to OpenSSL's "engine" or "provider" logic. Configures how to load the private key to use when creating verity signature partitions with the Verity=signature setting in partition files. Added in version 256.

--certificate=

Takes a file system path or a provider specific designation. Configures the PEM encoded X.509 certificate to use when creating verity signature partitions with the Verity=signature setting in partition files. Added in version 252.

--certificate-source=

Takes one of "file", or "provider". In the latter case, it is followed by the name of a provider, separated by colon, that will be passed to OpenSSL's "provider" logic. Configures how to load the X.509 certificate to use when creating verity signature partitions with the Verity=signature setting in partition files. Added in version 257.

--join-signature=

Specifies a colon-separated tuple with a hex-encoded top-level Verity hash of a Verity=hash partition as first element, and a PKCS7 signature of the roothash as a path to a DER-encoded signature file, or as an ASCII base64 string encoding of a DER-encoded signature prefixed by "base64:". To be used on a pre-existing image that was created with a parameter such as --defer-partitions=root-verity-sig, in order to allow implementing offline signing of the verity signature partition. This is an alternative to online signing using parameters such as --private-key=, for build systems where the private key for production signing is not available in the same context where content is created.

Added in version 258.

--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. Added in version 248.

--tpm2-device-key=PATH, --tpm2-seal-key-handle=HANDLE

Configures a TPM2 SRK key to bind encryption to. See systemd-cryptenroll(1) for details on this option. Added in version 255.

--tpm2-public-key=PATH, --tpm2-public-key-pcrs=PCR[+PCR...]

Configures a TPM2 signed PCR policy to bind encryption to. See systemd-cryptenroll(1) for details on these two options. Added in version 252.

--tpm2-pcrlock=PATH

Configures a TPM2 pcrlock policy to bind encryption to. See systemd-cryptenroll(1) for details on this option. Added in version 255.

--split=BOOL

Enables generation of split artifacts from partitions configured with SplitName=. If enabled, for each partition with SplitName= set, a separate output file containing just the contents of that partition is generated. The output filename consists of the loopback filename suffixed with the name configured with SplitName=. If the loopback filename ends with ".raw", the suffix is inserted before the ".raw" extension instead. Note that --split is independent from --dry-run. Even if --dry-run is enabled, split artifacts will still be generated from an existing image if --split is enabled.

Added in version 252.

--include-partitions=PARTITIONS, --exclude-partitions=PARTITIONS

These options specify which partition types systemd-repart should operate on. If --include-partitions= is used, all partitions that are not specified are excluded. If --exclude-partitions= is used, all partitions that are specified are excluded. Both options take a comma separated list of GPT partition type UUIDs or identifiers (see Type= in repart.d(5)). Added in version 253.

--defer-partitions=PARTITIONS

This option specifies for which partition types systemd-repart should defer. All partitions that are deferred using this option are still taken into account when calculating the sizes and offsets of other partitions, but are not actually written to the disk image. The net effect of this option is that if you run systemd-repart again without this option, the missing partitions will be added as if they had not been deferred the first time systemd-repart was executed. Added in version 253.

--sector-size=BYTES

This option allows configuring the sector size of the image produced by systemd-repart. It takes a value that is a power of "2" between "512" and "4096". This option is useful when building images for disks that use a different sector size as the disk on which the image is produced. Added in version 253.

--architecture=ARCH

This option allows overriding the architecture used for architecture specific partition types. For example, if set to "arm64" a partition type of "root-x86-64" referenced in repart.d/ drop-ins will be patched dynamically to refer to "root-arm64" instead. Takes one of "alpha", "arc", "arm", "arm64", "ia64", "loongarch64", "mips-le", "mips64-le", "parisc", "ppc", "ppc64", "ppc64-le", "riscv32", "riscv64", "s390", "s390x", "tilegx", "x86" or "x86-64". Added in version 254.

--offline=BOOL

Instructs systemd-repart to build the image offline. Takes a boolean or "auto". Defaults to "auto". If enabled, the image is built without using loop devices. This is useful to build images unprivileged or when loop devices are not available. If disabled, the image is always built using loop devices. If "auto", systemd-repart will build the image online if possible and fall back to building the image offline if loop devices are not available or cannot be accessed due to missing permissions. Added in version 254.

--copy-from=PATH

Instructs systemd-repart to synthesize partition definitions from the partition table in the given image or device. This option can be specified multiple times to synthesize definitions from each of the given images or devices. The generated definitions will copy the partitions into the destination partition table. The copied partitions will have the same size, metadata and contents but might have a different partition number and might be located at a different offset in the destination partition table. These definitions can be combined with partition definitions read from regular partition definition files. The synthesized definitions take precedence over the definitions read from partition definition files. Added in version 255.

--copy-source=PATH, -s PATH

Specifies a source directory all CopyFiles= source paths shall be considered relative to. This is similar to --root=, but exclusively applies to the CopyFiles= setting. If --root= and --copy-source= are used in combination the former applies as usual, except for CopyFiles= where the latter takes precedence. Added in version 255.

--make-ddi=TYPE

Takes one of "sysext", "confext" or "portable". Generates a Discoverable Disk Image (DDI) for a system extension (sysext, see systemd-sysext(8) for details), configuration extension (confext) or Portable Services[1]. The generated image will consist of a signed Verity "erofs" file system as root partition. In this mode of operation the partition definitions in /usr/lib/repart.d/*.conf and related directories are not read, and --definitions= is not supported, as appropriate definitions for the selected DDI class will be chosen automatically. Must be used in conjunction with --copy-source= to specify the file hierarchy to populate the DDI with. The specified directory should contain an etc/ subdirectory if "confext" is selected. If "sysext" is selected it should contain either a usr/ or opt/ directory, or both. If "portable" is used a full OS file hierarchy can be provided.

This option implies --empty=create, --size=auto and --seed=random (the latter two can be overridden).

The private key and certificate for signing the DDI must be specified via the --private-key= and --certificate= switches.

Added in version 255.

-S, -C, -P

Shortcuts for --make-ddi=sysext, --make-ddi=confext, --make-ddi=portable, respectively. Added in version 255.

--append-fstab=

Takes one of "no", "auto" or "replace". Controls how the generated fstab(5) file by --generate-fstab= will behave in case that there is a previously existing file. If "no" systemd-repart will complain and abort in case that there is a file. This is the default behaviour. If "replace" the file will be silently replaced with the new generated one.

If "auto" systemd-repart will search in the pre-existing file the section that belong to the automatically generated content and will replace it with the newer generated content, and keep the user provided section if there is one. The generated section is identified looking for the automatic content surrounded by "# Start section ↓ of automatically generated fstab by systemd-repart" and "# End section ↑ of automatically generated fstab by systemd-repart". The content that is before and after those comments are considered user provided, and kept in the new file.

Added in version 258.

--generate-fstab=PATH

Specifies a path where to write fstab(5) entries for the mountpoints configured with MountPoint= in the root directory specified with --copy-source= or --root= or in the host's root directory if neither is specified. Disabled by default. Added in version 256.

--generate-crypttab=PATH

Specifies a path where to write crypttab entries for the encrypted volumes configured with EncryptedVolume= in the root directory specified with --copy-source= or --root= or in the host's root directory if neither is specified. Disabled by default. Added in version 256.

--list-devices

Show a list of candidate block devices this command may operate on. Specifically, this enumerates block devices currently present that support partition tables, and shows their device node paths along with any of their symlinks. Added in version 257.

-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, and a non-zero failure code otherwise.

## EXAMPLE
Example 1. Generate a configuration extension image

The following creates a configuration extension DDI (confext) for an /etc/motd update:

```
mkdir -p tree/etc/extension-release.d
echo "Hello World" >tree/etc/motd
cat >tree/etc/extension-release.d/extension-release.my-motd <<EOF
ID=fedora
VERSION_ID=38
IMAGE_ID=my-motd
IMAGE_VERSION=7
EOF
systemd-repart -C \

  --private-key=verity-private-key.pem \

  --certificate=verity-certificate.pem \

  -s tree/ \

  /var/lib/confexts/my-motd.confext.raw
systemd-confext refresh
```

The DDI generated that way may be applied to the system with systemd-confext(1).

Example 2. Generate a system extension image and sign it via PKCS11

The following creates a system extension DDI (sysext) for an /usr/foo update and signs it with a hardware token via PKCS11:

```
mkdir -p tree/usr/lib/extension-release.d
echo "Hello World" >tree/usr/foo
cat >tree/usr/lib/extension-release.d/extension-release.my-foo <<EOF
ID=fedora
VERSION_ID=38
IMAGE_ID=my-foo
IMAGE_VERSION=7
EOF
systemd-repart --make-ddi=sysext \

  --private-key-source=engine:pkcs11 \

  --private-key="pkcs11:model=PKCS%2315%20emulated;manufacturer=piv_II;serial=0123456789abcdef;token=Some%20Cert" \

  --certificate=verity-certificate.pem \

  -s tree/ \

  /var/lib/extensions/my-foo.sysext.raw
systemd-sysext refresh
```

The DDI generated that way may be applied to the system with systemd-sysext(8).

Example 3. Generate a dm-verity signature offline and append it to a pre-built image

The following creates an image with dm-verity metadata, signs it separately to simulate an offline signing system, and then appends the signature to the image:

```
mkdir -p repart.d/ /tmp/tree/usr/lib/
cat >/tmp/tree/usr/lib/os-release <<EOF
ID=debian
VERSION_ID=13
EOF
cat >repart.d/10-root.conf <<EOF
[Partition]
Type=root
Format=erofs
SizeMinBytes=100M
SizeMaxBytes=100M
Verity=data
VerityMatchKey=root
EOF
cat >repart.d/11-root-verity.conf <<EOF
[Partition]
Type=root-verity
Label=%o_%w_verity
Verity=hash
VerityMatchKey=root
SizeMinBytes=400M
SizeMaxBytes=400M
EOF
cat >repart.d/12-root-verity-sig.conf <<EOF
[Partition]
Type=root-verity-sig
Label=%o_%w_verity_sig
Verity=signature
VerityMatchKey=root
EOF
systemd-repart --definitions repart.d \

  --defer-partitions=root-verity-sig \

  --copy-source=/tmp/tree/ \

  --empty=create --size=600M \

  --json=short \

  /tmp/img.raw | jq --raw-output0 ".[-1].roothash" > /tmp/img.roothash
openssl smime -sign -in /tmp/img.roothash \

  -inkey verity-private-key.pem \

  -signer verity-certificate.pem \

  -noattr -binary -outform der \

  -out /tmp/img.roothash.p7s
systemd-repart --definitions repart.d \

  --dry-run=no --root=/tmp/tree/ \

  --join-signature="$(cat /tmp/img.roothash):/tmp/img.roothash.p7s" \

  --certificate=verity-certificate.pem \

  /tmp/img.raw
```

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

## NOTES
1.

Portable Services

https://systemd.io/PORTABLE_SERVICES


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

/usr/lib/systemd/systemd-rfkill

## DESCRIPTION
systemd-rfkill.service is a service that restores the RF kill switch state at early boot and saves it 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. See also kernel-command-line(7).

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. Added in version 227.

## 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
/usr/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(1) 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(1):

```
# 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(1), 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.

Note that systemd-socket-proxyd will not forward socket side channel information, i.e. will not forward SCM_RIGHTS, SCM_CREDENTIALS, SCM_SECURITY, SO_PEERCRED, SO_PEERPIDFD, SO_PEERSEC, SO_PEERGROUPS and similar.

## 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. Added in version 233.

--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". Added in version 246.

## 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]
Type=notify
ExecStart=/usr/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]
Type=notify
ExecStart=/usr/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-soft-reboot.service

title: systemd-soft-reboot.service(8)

summary: Userspace reboot operation

text:
# systemd-soft-reboot.service(8)

## NAME
systemd-soft-reboot.service - Userspace reboot operation

## SYNOPSIS
systemd-soft-reboot.service

## DESCRIPTION
systemd-soft-reboot.service is a system service that is pulled in by soft-reboot.target and is responsible for performing a userspace-only reboot operation. When invoked, it will send the SIGTERM signal to any processes left running (but does not wait for the processes to exit), and follow up with SIGKILL. If the /run/nextroot/ directory exists (which may be a regular directory, a directory mount point or a symlink to either) then it will switch the file system root to it. It then reexecutes the service manager off the (possibly now new) root file system, which will enqueue a new boot transaction as in a normal reboot.

Such a userspace-only reboot operation permits updating or resetting the entirety of userspace with minimal downtime, as the reboot operation does not transition through:

•The second phase of regular shutdown, as implemented by systemd-shutdown(8).

•The third phase of regular shutdown, i.e. the return to the initrd context.

•The hardware reboot operation.

•The firmware initialization.

•The boot loader initialization.

•The kernel initialization.

•The initrd initialization.

However, this form of reboot comes with drawbacks as well:

•The OS update remains incomplete, as the kernel is not reset and continues running.

•Kernel settings (such as /proc/sys/ settings, a.k.a. "sysctl", or /sys/ settings) are not reset.

These limitations may be addressed by various means, which are outside of the scope of this documentation, such as kernel live-patching and sufficiently comprehensive /etc/sysctl.d/ files.

## RESOURCE PASS-THROUGH
Various runtime OS resources can passed from a system runtime to the next, through the userspace reboot operation. Specifically:

•File descriptors placed in the file descriptor store of services that remain active until the very end are passed to the next boot, where they are placed in the file descriptor store of the same unit. For this to work, units must declare DefaultDependencies=no (and avoid a manual Conflicts=shutdown.target or similar) to ensure they are not terminated as usual during the system shutdown operation. Alternatively, use FileDescriptorStorePreserve= to allow the file descriptor store to remain pinned even when the unit is down. See systemd.service(5) for details about the file descriptor store.

•Similar to this, file descriptors associated with .socket units remain open (and connectible) if the units are not stopped during the transition. (Achieved by DefaultDependencies=no.)

•The /run/ file system remains mounted and populated and may be used to pass state information between such userspace reboot cycles.

•Service processes may continue to run over the transition, past soft-reboot and into the next session, if they are placed in services that remain active until the very end of shutdown (which again is achieved via DefaultDependencies=no). They must also be set up to avoid being killed by the aforementioned SIGTERM and SIGKILL via SurviveFinalKillSignal=yes, and also be configured to avoid being stopped on isolate via IgnoreOnIsolate=yes. They also have to be configured to be stopped on normal shutdown, reboot and maintenance mode. Finally, they have to be ordered after basic.target to ensure correct ordering on boot. Note that in case any new or custom units are used to isolate to, or that implement an equivalent shutdown functionality, they will also have to be configured manually for correct ordering and conflicting. For example:

```
[Unit]
Description=My Surviving Service
SurviveFinalKillSignal=yes
IgnoreOnIsolate=yes
DefaultDependencies=no
After=basic.target
Conflicts=reboot.target kexec.target poweroff.target halt.target rescue.target emergency.target
Before=shutdown.target rescue.target emergency.target
[Service]
Type=oneshot
ExecStart=sleep infinity
```

•On top of the above, templated units also need a configuration file for their slice, as they by default use a slice named after the non-templated part of the unit. For example, for a foo@test.service instance, a system-foo.slice unit may be added with the following content:

```
[Unit]
SurviveFinalKillSignal=yes
IgnoreOnIsolate=yes
DefaultDependencies=no
```

•File system mounts may remain mounted during the transition, and complex storage attached, if configured to remain until the very end of the shutdown process. (Also achieved via DefaultDependencies=no, and by avoiding Conflicts=umount.target)

•If the unit publishes a service over D-Bus, the connection needs to be re-established after soft-reboot as the D-Bus broker will be stopped and then started again. When using the sd-bus(3) library this can be achieved by adapting the following example.

```
/* SPDX-License-Identifier: MIT-0 */
/* A D-Bus service that automatically reconnects when the system bus is

 * restarted.

 *

 * Compile with 'cc sd_bus_service_reconnect.c $(pkg-config --libs --cflags libsystemd)'

 *

 * To allow the program to take ownership of the name 'org.freedesktop.ReconnectExample',

 * add the following as /etc/dbus-1/system.d/org.freedesktop.ReconnectExample.conf

 * and then reload the broker with 'systemctl reload dbus':
<?xml version="1.0"?> <!--*-nxml-*-->
<!DOCTYPE busconfig PUBLIC "-//freedesktop//DTD D-BUS Bus Configuration 1.0//EN"

  "http://www.freedesktop.org/standards/dbus/1.0/busconfig.dtd">
<busconfig>

  <policy user="root">

    <allow own="org.freedesktop.ReconnectExample"/>

    <allow send_destination="org.freedesktop.ReconnectExample"/>

    <allow receive_sender="org.freedesktop.ReconnectExample"/>

  </policy>

  <policy context="default">

    <allow send_destination="org.freedesktop.ReconnectExample"/>

    <allow receive_sender="org.freedesktop.ReconnectExample"/>

  </policy>
</busconfig>

 *

 * To get the property via busctl:

 *

 * $ busctl --user get-property org.freedesktop.ReconnectExample \

 *                              /org/freedesktop/ReconnectExample \

 *                              org.freedesktop.ReconnectExample \

 *                              Example

 * s "example"

 */
#include <errno.h>
#include <stdio.h>
#include <stdlib.h>
#include <systemd/sd-bus.h>
#define _cleanup_(f) __attribute__((cleanup(f)))
static int log_error(int r, const char *str) {

  fprintf(stderr, "%s failed: %s\n", str, strerror(-r));

  return r;
}
typedef struct object {

  const char *example;

  sd_bus **bus;

  sd_event **event;
} object;
static int property_get(

                sd_bus *bus,

                const char *path,

                const char *interface,

                const char *property,

                sd_bus_message *reply,

                void *userdata,

                sd_bus_error *error) {

  object *o = userdata;

  if (strcmp(property, "Example") == 0)

    return sd_bus_message_append(reply, "s", o->example);

  return sd_bus_error_setf(error,

                           SD_BUS_ERROR_UNKNOWN_PROPERTY,

                           "Unknown property '%s'",

                           property);
}
/* https://www.freedesktop.org/software/systemd/man/sd_bus_add_object.html */
static const sd_bus_vtable vtable[] = {

  SD_BUS_VTABLE_START(0),

  SD_BUS_PROPERTY(

    "Example", "s",

    property_get,

    0,

    SD_BUS_VTABLE_PROPERTY_CONST),

  SD_BUS_VTABLE_END
};
static int setup(object *o);
static int on_disconnect(sd_bus_message *message, void *userdata, sd_bus_error *ret_error) {

  int r;

  r = setup((object *)userdata);

  if (r < 0) {

    object *o = userdata;

    r = sd_event_exit(*o->event, r);

    if (r < 0)

      return log_error(r, "sd_event_exit()");

  }

  return 1;
}
/* Ensure the event loop exits with a clear error if acquiring the well-known

 * service name fails */
static int request_name_callback(sd_bus_message *m, void *userdata, sd_bus_error *ret_error) {

  int r;

  if (!sd_bus_message_is_method_error(m, NULL))

    return 1;

  const sd_bus_error *error = sd_bus_message_get_error(m);

  if (sd_bus_error_has_names(error, SD_BUS_ERROR_TIMEOUT, SD_BUS_ERROR_NO_REPLY))

    return 1; /* The bus is not available, try again later */

  fprintf(stderr, "Failed to request name: %s\n", error->message);

  object *o = userdata;

  r = sd_event_exit(*o->event, -sd_bus_error_get_errno(error));

  if (r < 0)

    return log_error(r, "sd_event_exit()");

  return 1;
}
static int setup(object *o) {

  int r;

  /* If we are reconnecting, then the bus object needs to be closed, detached

   * from the event loop and recreated.

   * https://www.freedesktop.org/software/systemd/man/sd_bus_detach_event.html

   * https://www.freedesktop.org/software/systemd/man/sd_bus_close_unref.html

   */

  if (*o->bus) {

    r = sd_bus_detach_event(*o->bus);

    if (r < 0)

      return log_error(r, "sd_bus_detach_event()");

    *o->bus = sd_bus_close_unref(*o->bus);

  }

  /* Set up a new bus object for the system bus, configure it to wait for D-Bus

   * to be available instead of failing if it is not, and start it. All the

   * following operations are asynchronous and will not block waiting for D-Bus

   * to be available.

   * https://www.freedesktop.org/software/systemd/man/sd_bus_new.html

   * https://www.freedesktop.org/software/systemd/man/sd_bus_set_address.html

   * https://www.freedesktop.org/software/systemd/man/sd_bus_set_bus_client.html

   * https://www.freedesktop.org/software/systemd/man/sd_bus_negotiate_creds.html

   * https://www.freedesktop.org/software/systemd/man/sd_bus_set_watch_bind.html

   * https://www.freedesktop.org/software/systemd/man/sd_bus_set_connected_signal.html

   * https://www.freedesktop.org/software/systemd/man/sd_bus_start.html

   */

  r = sd_bus_new(o->bus);

  if (r < 0)

    return log_error(r, "sd_bus_new()");

  r = sd_bus_set_address(*o->bus, "unix:path=/run/dbus/system_bus_socket");

  if (r < 0)

    return log_error(r, "sd_bus_set_address()");

  r = sd_bus_set_bus_client(*o->bus, 1);

  if (r < 0)

    return log_error(r, "sd_bus_set_bus_client()");

  r = sd_bus_negotiate_creds(*o->bus, 1, SD_BUS_CREDS_UID|SD_BUS_CREDS_EUID|SD_BUS_CREDS_EFFECTIVE_CAPS);

  if (r < 0)

    return log_error(r, "sd_bus_negotiate_creds()");

  r = sd_bus_set_watch_bind(*o->bus, 1);

  if (r < 0)

    return log_error(r, "sd_bus_set_watch_bind()");

  r = sd_bus_start(*o->bus);

  if (r < 0)

    return log_error(r, "sd_bus_start()");

  /* Publish an interface on the bus, specifying our well-known object access

   * path and public interface name.

   * https://www.freedesktop.org/software/systemd/man/sd_bus_add_object.html

   * https://dbus.freedesktop.org/doc/dbus-tutorial.html

   */

  r = sd_bus_add_object_vtable(*o->bus,

                               NULL,

                               "/org/freedesktop/ReconnectExample",

                               "org.freedesktop.ReconnectExample",

                               vtable,

                               o);

  if (r < 0)

    return log_error(r, "sd_bus_add_object_vtable()");

  /* By default, the service is only assigned an ephemeral name. Also add a

   * well-known one, so that clients know whom to call. This needs to be

   * asynchronous, as D-Bus might not be yet available. The callback will check

   * whether the error is expected or not, in case it fails.

   * https://www.freedesktop.org/software/systemd/man/sd_bus_request_name.html

   */

  r = sd_bus_request_name_async(*o->bus,

                                NULL,

                                "org.freedesktop.ReconnectExample",

                                0,

                                request_name_callback,

                                o);

  if (r < 0)

    return log_error(r, "sd_bus_request_name_async()");

  /* When D-Bus is disconnected this callback will be invoked, which will set up

   * the connection again. This needs to be asynchronous, as D-Bus might not yet

   * be available.

   * https://www.freedesktop.org/software/systemd/man/sd_bus_match_signal_async.html

   */

  r = sd_bus_match_signal_async(*o->bus,

                                NULL,

                                "org.freedesktop.DBus.Local",

                                NULL,

                                "org.freedesktop.DBus.Local",

                                "Disconnected",

                                on_disconnect,

                                NULL,

                                o);

  if (r < 0)

    return log_error(r, "sd_bus_match_signal_async()");

  /* Attach the bus object to the event loop so that calls and signals are

   * processed.

   * https://www.freedesktop.org/software/systemd/man/sd_bus_attach_event.html

   */

  r = sd_bus_attach_event(*o->bus, *o->event, 0);

  if (r < 0)

    return log_error(r, "sd_bus_attach_event()");

  return 0;
}
int main(int argc, char **argv) {

  /* The bus should be relinquished before the program terminates. The cleanup

   * attribute allows us to do it nicely and cleanly whenever we exit the block.

   */

  _cleanup_(sd_bus_flush_close_unrefp) sd_bus *bus = NULL;

  _cleanup_(sd_event_unrefp) sd_event *event = NULL;

  object o = {

    .example = "example",

    .bus = &bus,

    .event = &event,

  };

  int r;

  /* Create an event loop data structure, with default parameters.

   * https://www.freedesktop.org/software/systemd/man/sd_event_default.html

   */

  r = sd_event_default(&event);

  if (r < 0)

    return log_error(r, "sd_event_default()");

  /* By default, the event loop will terminate when all sources have disappeared,

   * so we have to keep it 'occupied'. Register signal handling to do so.

   * https://www.freedesktop.org/software/systemd/man/sd_event_add_signal.html

   */

  r = sd_event_add_signal(event, NULL, SIGINT|SD_EVENT_SIGNAL_PROCMASK, NULL, NULL);

  if (r < 0)

    return log_error(r, "sd_event_add_signal(SIGINT)");

  r = sd_event_add_signal(event, NULL, SIGTERM|SD_EVENT_SIGNAL_PROCMASK, NULL, NULL);

  if (r < 0)

    return log_error(r, "sd_event_add_signal(SIGTERM)");

  r = setup(&o);

  if (r < 0)

    return EXIT_FAILURE;

  /* Enter the main loop, it will exit only on sigint/sigterm.

   * https://www.freedesktop.org/software/systemd/man/sd_event_loop.html

   */

  r = sd_event_loop(event);

  if (r < 0)

    return log_error(r, "sd_event_loop()");

  /* https://www.freedesktop.org/software/systemd/man/sd_bus_release_name.html */

  r = sd_bus_release_name(bus, "org.freedesktop.ReconnectExample");

  if (r < 0)

    return log_error(r, "sd_bus_release_name()");

  return 0;
}
```

Even though passing resources from one soft reboot cycle to the next is possible this way, we strongly suggest to use this functionality sparingly only, as it creates a more fragile system as resources from different versions of the OS and applications might be mixed with unforeseen consequences. In particular it is recommended to avoid allowing processes to survive the soft reboot operation, as this means code updates will necessarily be incomplete, and processes typically pin various other resources (such as the file system they are backed by), thus increasing memory usage (as two versions of the OS/application/file system might be kept in memory). Leaving processes running during a soft-reboot operation requires disconnecting the service comprehensively from the rest of the OS, i.e. minimizing IPC and reducing sharing of resources with the rest of the OS. A possible mechanism to achieve this is the concept of Portable Services[1], but make sure no resource from the host's OS filesystems is pinned via BindPaths= or similar unit settings, otherwise the old, originating filesystem will remain mounted as long as the unit is running.

## NOTES
Note that because systemd-shutdown(8) is not executed, the executables in /usr/lib/systemd/system-shutdown/ are not executed either.

Note that systemd-soft-reboot.service (and related units) should never be executed directly. Instead, trigger system shutdown with a command such as systemctl soft-reboot.

Note that if a new root file system has been set up on "/run/nextroot/", a soft-reboot will be performed when the reboot command is invoked.

## SEE ALSO
systemd(1), systemctl(1), systemd.special(7), systemd-poweroff.service(8), systemd-suspend.service(8), bootup(7)

## NOTES
1.

Portable Services

https://systemd.io/PORTABLE_SERVICES


systemd-ssh-generator

title: systemd-ssh-generator(8)

summary: Generator for binding a socket\-activated SSH server to local AF_VSOCK and AF_UNIX sockets

text:
# systemd-ssh-generator(8)

## NAME
systemd-ssh-generator - Generator for binding a socket-activated SSH server to local AF_VSOCK and AF_UNIX sockets

## SYNOPSIS
/usr/lib/systemd/system-generators/systemd-ssh-generator

## DESCRIPTION
systemd-ssh-generator binds a socket-activated SSH server to local AF_VSOCK and AF_UNIX sockets under certain conditions. It only has an effect if the sshd(8) binary is installed. Specifically, it does the following:

•If invoked in a VM with AF_VSOCK support, a socket-activated SSH per-connection service is bound to AF_VSOCK port 22.

•If invoked in a container environment with a writable directory /run/host/unix-export/ pre-mounted it binds SSH to an AF_UNIX socket /run/host/unix-export/ssh. The assumption is that this directory is bind mounted to the host side as well, and can be used to connect to the container from there. See Container Interface[1] for more information about this interface.

•A local AF_UNIX socket /run/ssh-unix-local/socket is also bound, unconditionally. This may be used for SSH communication from the host to itself, without involving networking, for example to traverse security boundaries safely and with secure authentication.

•Additional AF_UNIX and AF_VSOCK sockets are optionally bound, based on the systemd.ssh_listen= kernel command line option or the ssh.listen system credential (see below).

See systemd-ssh-proxy(1) for details on how to connect to these sockets via the ssh client.

The ssh.authorized_keys.root credential can be used to allow specific public keys to log in over SSH. See systemd.system-credentials(7) for more information.

The generator will use a packaged sshd@.service service template file if one exists, and otherwise generate a suitable service template file.

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

## KERNEL COMMAND LINE
systemd-ssh-generator understands the following kernel-command-line(7) parameters:

systemd.ssh_auto=

This option takes an optional boolean argument, and defaults to yes. If enabled, the automatic binding to the AF_VSOCK and AF_UNIX sockets listed above is done. If disable, this is not done, except for those explicitly requested via systemd.ssh_listen= on the kernel command line or via the ssh.listen system credential. Added in version 256.

systemd.ssh_listen=

This option configures an additional socket to bind SSH to. It may be used multiple times to bind multiple sockets. The syntax should follow the one of ListenStream=, see systemd.socket(5) for details. This functionality supports all socket families systemd(1) supports, including AF_INET and AF_INET6. Added in version 256.

## CREDENTIALS
systemd-ssh-generator supports the system credentials logic. The following credentials are used when passed in:

ssh.listen

This credential should be a text file, with each line referencing one additional socket to bind SSH to. The syntax should follow the one of ListenStream=, see systemd.socket(5) for details. This functionality supports all socket families systemd supports, including AF_INET and AF_INET6. Added in version 256.

ssh.ephemeral-authorized_keys-all

Provides additional public keys, given in the customary authorized_keys format, for all users, for incoming connections via the generated AF_VSOCK and AF_UNIX socket units. The intended use of this is for a host system (in either VM or container configurations) to generate a keypair and inject the public key into the guest, using the private key to connect to any user account on the guest via ssh, without further authentication.

Added in version 256.

## SEE ALSO
systemd(1), kernel-command-line(7), systemd.system-credentials(7), vsock(7), unix(7), ssh(1), sshd(8)

## NOTES
1.

Container Interface

https://systemd.io/CONTAINER_INTERFACE


systemd-storagetm.service

title: systemd-storagetm.service(8)

summary: Exposes all local block devices as NVMe\-TCP mass storage devices

text:
# systemd-storagetm.service(8)

## NAME
systemd-storagetm.service, systemd-storagetm - Exposes all local block devices as NVMe-TCP mass storage devices

## SYNOPSIS
systemd-storagetm.service

/usr/lib/systemd/systemd-storagetm [OPTIONS...] [DEVICE]

## DESCRIPTION
systemd-storagetm.service is a service that exposes all local block devices as NVMe-TCP mass storage devices. Its primary use-case is to be invoked by the storage-target-mode.target unit that can be booted into.

Warning

The NVMe disks are currently exposed without authentication or encryption, in read/write mode. This means network peers may read from and write to the device without any restrictions. This functionality should hence only be used in a local setup.

Note that to function properly networking must be configured too. The recommended mechanism to boot into a storage target mode is by adding "rd.systemd.unit=storage-target-mode.target ip=link-local" on the kernel command line. Note that "ip=link-local" only configures link-local IP, i.e. IPv4LL and IPv6LL, which means non-routable addresses. This is done for security reasons, so that only systems on the local link can access the devices. Use "ip=dhcp" to assign routable addresses too. For further details see systemd-network-generator.service(8).

Unless the --all switch is used expects one or more block devices or regular files to expose via NVMe-TCP as argument.

## OPTIONS
The following options are understood:

--nqn=

Takes a string. If specified configures the NVMe Qualified Name to use for the exposed NVMe-TCP mass storage devices. The NQN should follow the syntax described in NVM Express Base Specification 2.0c[1], section 4.5 "NVMe Qualified Names". Note that the NQN specified here will be suffixed with a dot and the block device name before it is exposed on the NVMe target. If not specified, defaults to "nqn.2023-10.io.systemd:storagetm.ID", where ID is replaced by a 128bit ID derived from machine-id(5). Added in version 255.

--all, -a

If specified exposes all local block devices via NVMe-TCP, current and future (i.e. it watches block devices come and go and updates the NVMe-TCP list as needed). Note that by default any block devices that originate on the same block device as the block device backing the current root file system are excluded. If the switch is specified twice this safety mechanism is disabled. Added in version 255.

--list-devices

Show a list of candidate block devices this command may operate on. Specifically, this enumerates block devices currently present, and shows their device node paths along with any of their symlinks. Added in version 257.

-h, --help

Print a short help text and exit.

--version

Print a short version string and exit.

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

## NOTES
1.

NVM Express Base Specification 2.0c

https://nvmexpress.org/wp-content/uploads/NVM-Express-Base-Specification-2.0c-2022.10.04-Ratified.pdf


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

/usr/lib/systemd/system-sleep

## DESCRIPTION
systemd-suspend.service is a system service that is pulled in by suspend.target and is responsible for the actual system suspend. Similarly, systemd-hibernate.service is pulled in by hibernate.target to execute the actual hibernation. Finally, systemd-hybrid-sleep.service is pulled in by hybrid-sleep.target to execute hybrid hibernation with system suspend 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 /usr/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 user.slice will be frozen while the executables are running, so they should not attempt to communicate with any user services expecting a reply.

Note that scripts or binaries dropped in /usr/lib/systemd/system-sleep/ are intended for local use only and should be considered hacks. If applications want to react to system suspend/hibernation and resume, they should rather use the Inhibitor Locks[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).

Note that by default these services freeze user.slice while they run. This prevents the execution of any process in any of the user sessions while the system is entering into and resuming from sleep. Thus, this prevents the hooks in /usr/lib/systemd/system-sleep/, or any other process for that matter, from communicating with any user session process during sleep.

## 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. Added in version 203.

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

## NOTES
1.

Inhibitor Locks

https://systemd.io/INHIBITOR_LOCKS


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
/usr/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 /usr/lib/systemd/systemd-sysctl.

When invoked with no arguments, /usr/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. Added in version 230.

--strict=

Always return non-zero exit code on failure (including invalid sysctl variable name and insufficient permissions), unless the sysctl variable name is prefixed with a "-" character. Added in version 252.

--cat-config

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

--tldr

Copy the contents of config files to standard output. Only the "interesting" parts of the configuration files are printed, comments and empty lines are skipped. 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.

## CREDENTIALS
systemd-sysctl supports the service credentials logic as implemented by ImportCredential=/LoadCredential=/SetCredential= (see systemd.exec(5) for details). The following credentials are used when passed in:

sysctl.extra

The contents of this credential may contain additional lines to operate on. The credential contents should follow the same format as any other sysctl.d/ drop-in configuration file. If this credential is passed it is processed after all of the drop-in files read from the file system. The settings configured in the credential hence take precedence over those in the file system. Added in version 252.

Note that by default the systemd-sysctl.service unit file is set up to inherit the "sysctl.extra" credential from the service manager.

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

```
# /usr/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

```
# /usr/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 /usr/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)