shaba/systemd
1
0
Fork 0
mirror of https://github.com/systemd/systemd.git synced 2024-11-01 09:21:26 +03:00
Code
b522c4b92a
systemd/docs/ENVIRONMENT.md

288 lines
14 KiB
Markdown
Raw Normal View History

docs: add a "front matter" snippet to our markdown pages It turns out Jekyll (the engine behind GitHub Pages) requires that pages include a "Front Matter" snippet of YAML at the top for proper rendering. Omitting it will still render the pages, but including it opens up new possibilities, such as using a {% for %} loop to generate index.md instead of requiring a separate script. I'm hoping this will also fix the issue with some of the pages (notably CODE_OF_CONDUCT.html) not being available under systemd.io Tested locally by rendering the website with Jekyll. Before this change, the *.md files were kept unchanged (so not sure how that even works?!), after this commit, proper *.html files were generated from it.
2019-01-03 01:16:34 +03:00
---
title: Known Environment Variables
docs: place all our markdown docs in rough categories
2019-12-11 12:49:28 +03:00
category: Interfaces
docs: make it pretty Add custom Jekyll theme, logo, webfont and .gitignore FIXME: the markdown files have some H1 headers which need to be replaced with H2
2019-12-11 19:01:46 +03:00
layout: default
docs: add a "front matter" snippet to our markdown pages It turns out Jekyll (the engine behind GitHub Pages) requires that pages include a "Front Matter" snippet of YAML at the top for proper rendering. Omitting it will still render the pages, but including it opens up new possibilities, such as using a {% for %} loop to generate index.md instead of requiring a separate script. I'm hoping this will also fix the issue with some of the pages (notably CODE_OF_CONDUCT.html) not being available under systemd.io Tested locally by rendering the website with Jekyll. Before this change, the *.md files were kept unchanged (so not sure how that even works?!), after this commit, proper *.html files were generated from it.
2019-01-03 01:16:34 +03:00
---
Add a bit of documentation for the various undocumented environment variables we honour
2016-11-24 19:47:39 +03:00
# Known Environment Variables
A number of systemd components take additional runtime parameters via
environment variables. Many of these environment variables are not supported at
the same level as command line switches and other interfaces are: we don't
document them in the man pages and we make no stability guarantees for
them. While they generally are unlikely to be dropped any time soon again, we
do not want to guarantee that they stay around for good either.
Below is an (incomprehensive) list of the environment variables understood by
the various tools. Note that this list only covers environment variables not
documented in the proper man pages.
All tools:
systemctl,verbs: Introduce SYSTEMD_OFFLINE environment variable A lot of code references the `running_in_chroot()` function; while I didn't dig I'm pretty certain this arose to deal with situations like RPM package builds in `mock` - there we don't want the `%post`s to `systemctl start` for example. And actually this exact same use case arises for [rpm-ostree](https://github.com/projectatomic/rpm-ostree/) where we implement offline upgrades by default; the `%post`s are always run in a new chroot using [bwrap](https://github.com/projectatomic/bubblewrap). And here's the problem: bwrap creates proper mount roots, so it passes `running_in_chroot()`, and then if a script tries to do `systemctl start` we get: `System has not been booted with systemd as init system (PID 1)` but that's an *error*, unlike the `running_in_chroot()` case where we ignore. Further complicating things is there are real world RPM packages like `glusterfs` which end up invoking `systemctl start`. A while ago, the `SYSTEMD_IGNORE_CHROOT` environment variable was added for the inverse case of running in a chroot, but still wanting to use systemd as PID 1 (presumably some broken initramfs setups?). Let's introduce a `SYSTEMD_OFFLINE` environment variable for cases like mock/rpm-ostree so we can force on the "ignore everything except preset" logic. This way we'll still not start services even if mock switches to use nspawn or bwrap or something else that isn't a chroot. We also cleanly supercede the `SYSTEMD_IGNORE_CHROOT=1` which is now spelled `SYSTEMD_OFFLINE=0`. (Suggested by @poettering) Also I made things slightly nicer here and we now print the ignored operation.
2017-12-14 00:04:41 +03:00
* `$SYSTEMD_OFFLINE=[0|1]` — if set to `1`, then `systemctl` will
refrain from talking to PID 1; this has the same effect as the historical
detection of `chroot()`. Setting this variable to `0` instead has a similar
effect as `SYSTEMD_IGNORE_CHROOT=1`; i.e. tools will try to
communicate with PID 1 even if a `chroot()` environment is detected.
You almost certainly want to set this to `1` if you maintain a package build system
or similar and are trying to use a modern container system and not plain
`chroot()`.
Add a bit of documentation for the various undocumented environment variables we honour
2016-11-24 19:47:39 +03:00
* `$SYSTEMD_IGNORE_CHROOT=1` — if set, don't check whether being invoked in a
systemctl,verbs: Introduce SYSTEMD_OFFLINE environment variable A lot of code references the `running_in_chroot()` function; while I didn't dig I'm pretty certain this arose to deal with situations like RPM package builds in `mock` - there we don't want the `%post`s to `systemctl start` for example. And actually this exact same use case arises for [rpm-ostree](https://github.com/projectatomic/rpm-ostree/) where we implement offline upgrades by default; the `%post`s are always run in a new chroot using [bwrap](https://github.com/projectatomic/bubblewrap). And here's the problem: bwrap creates proper mount roots, so it passes `running_in_chroot()`, and then if a script tries to do `systemctl start` we get: `System has not been booted with systemd as init system (PID 1)` but that's an *error*, unlike the `running_in_chroot()` case where we ignore. Further complicating things is there are real world RPM packages like `glusterfs` which end up invoking `systemctl start`. A while ago, the `SYSTEMD_IGNORE_CHROOT` environment variable was added for the inverse case of running in a chroot, but still wanting to use systemd as PID 1 (presumably some broken initramfs setups?). Let's introduce a `SYSTEMD_OFFLINE` environment variable for cases like mock/rpm-ostree so we can force on the "ignore everything except preset" logic. This way we'll still not start services even if mock switches to use nspawn or bwrap or something else that isn't a chroot. We also cleanly supercede the `SYSTEMD_IGNORE_CHROOT=1` which is now spelled `SYSTEMD_OFFLINE=0`. (Suggested by @poettering) Also I made things slightly nicer here and we now print the ignored operation.
2017-12-14 00:04:41 +03:00
`chroot()` environment. This is particularly relevant for systemctl, as it
will not alter its behaviour for `chroot()` environments if set. Normally it
refrains from talking to PID 1 in such a case; turning most operations such
as `start` into no-ops. If that's what's explicitly desired, you might
consider setting `SYSTEMD_OFFLINE=1`.
Add a bit of documentation for the various undocumented environment variables we honour
2016-11-24 19:47:39 +03:00
* `$SD_EVENT_PROFILE_DELAYS=1` — if set, the sd-event event loop implementation
will print latency information at runtime.
Add support for SystemdOptions EFI var to augment /proc/cmdline In various circumstances, overriding the kernel commandline can be inconvenient. People have different bootloaders, and e.g. the grub config can be pretty scary. grubby helps, but it isn't always available. This option adds an alternative mechanism that can quite convenient on EFI systems. cmdline settings have higher priority, because they can be (usually) changed on the bootloader prompt. $SYSTEMD_EFI_OPTIONS can be used to override, same as $SYSTEMD_PROC_CMDLINE.
2019-08-01 16:33:35 +03:00
* `$SYSTEMD_PROC_CMDLINE` — if set, the contents are used as the kernel command
line instead of the actual one in /proc/cmdline. This is useful for
debugging, in order to test generators and other code against specific kernel
command lines.
Allow overriding /etc/fstab with $SYSTEMD_FSTAB
2019-11-13 19:36:46 +03:00
* `$SYSTEMD_FSTAB` — if set, use this path instead of /etc/fstab. Only useful
for debugging.
cryptsetup-generator: allow overriding crypttab path with $SYSTEMD_CRYPTAB
2019-11-13 12:31:44 +03:00
* `$SYSTEMD_CRYPTTAB` — if set, use this path instead of /etc/crypttab. Only
useful for debugging. Currently only supported by systemd-cryptsetup-generator.
veritysetup-generator: add support for veritytab This adds the support for veritytab. The veritytab file contains at most five fields, the first four are mandatory, the last one is optional: - The first field contains the name of the resulting verity volume; its block device is set up /dev/mapper/</filename>. - The second field contains a path to the underlying block data device, or a specification of a block device via UUID= followed by the UUID. - The third field contains a path to the underlying block hash device, or a specification of a block device via UUID= followed by the UUID. - The fourth field is the roothash in hexadecimal. - The fifth field, if present, is a comma-delimited list of options. The following options are recognized only: ignore-corruption, restart-on-corruption, panic-on-corruption, ignore-zero-blocks, check-at-most-once and root-hash-signature. The others options will be implemented later. Also, this adds support for the new kernel verity command line boolean option "veritytab" which enables the read for veritytab, and the new environment variable SYSTEMD_VERITYTAB which sets the path to the file veritytab to read.
2020-11-14 17:21:39 +03:00
* `$SYSTEMD_VERITYTAB` — if set, use this path instead of /etc/veritytab. Only
useful for debugging. Currently only supported by systemd-veritysetup-generator.
Rename "system-options" to "systemd-efi-options" This makes the naming more consistent: we now have bootctl systemd-efi-options, $SYSTEMD_EFI_OPTIONS and the SystemdOptions EFI variable. (SystemdEFIOptions would be redundant, because it is only used in the context of efivars, and users don't interact with that name directly.) bootctl is adjusted to use 2sp indentation, similarly to systemctl and other programs. Remove the prefix with the old name from 'bootctl systemd-efi-options' output, since it's redundant and we don't want the old name anyway.
2019-11-18 21:47:50 +03:00
* `$SYSTEMD_EFI_OPTIONS` — if set, used instead of the string in the
SystemdOptions EFI variable. Analogous to `$SYSTEMD_PROC_CMDLINE`.
util-lib: read $SYSTEMD_PROC_CMDLINE if set when looking for the kernel cmdline if we want to parse the kernel command line, let's check the $SYSTEMD_PROC_CMDLINE environment variable first. This is useful for debugging purposes.
2016-12-12 15:42:06 +03:00
initrd: extend SYSTEMD_IN_INITRD to accept non-ramfs rootfs Sometimes, non-ramfs initrd root are useful. Eg, for kdump, because initramfs is memory consuming, so mount a compressed image in earlier initrd, chroot into it then let systemd do the rest of job is a good solution. But systemd doesn't recognize the initrd environment if rootfs is not a temporary fs. This is a reasonable check, because switch-root in initrd will wipe the whole rootfs, will be a disaster if there are any misdetect. So extend SYSTEMD_IN_INITRD environment variable, now it accepts boolean value and two extra keyword, "auto" and "lenient". "auto" is same as before, and it's the default value. "lenient" will let systemd bypass the rootfs check.
2021-01-12 19:04:53 +03:00
* `$SYSTEMD_IN_INITRD=[auto|lenient|0|1]` — if set, specifies initrd detection
method. Defaults to `auto`. Behavior is defined as follows:
`auto`: Checks if `/etc/initrd-release` exists, and a temporary fs is mounted
on `/`. If both conditions meet, then it's in initrd.
tree-wide: fix typo
2021-01-17 09:43:14 +03:00
`lenient`: Similar to `auto`, but the rootfs check is skipped.
initrd: extend SYSTEMD_IN_INITRD to accept non-ramfs rootfs Sometimes, non-ramfs initrd root are useful. Eg, for kdump, because initramfs is memory consuming, so mount a compressed image in earlier initrd, chroot into it then let systemd do the rest of job is a good solution. But systemd doesn't recognize the initrd environment if rootfs is not a temporary fs. This is a reasonable check, because switch-root in initrd will wipe the whole rootfs, will be a disaster if there are any misdetect. So extend SYSTEMD_IN_INITRD environment variable, now it accepts boolean value and two extra keyword, "auto" and "lenient". "auto" is same as before, and it's the default value. "lenient" will let systemd bypass the rootfs check.
2021-01-12 19:04:53 +03:00
`0|1`: Simply overrides initrd detection. This is useful for debugging and
testing initrd-only programs in the main system.
Add $SYSTEMD_IN_INITRD=yes|no override for debugging
2018-09-26 08:15:55 +03:00
sd-bus: make BUS_DEFAULT_TIMEOUT configurable This adds sd_bus_{get,set}_method_call_timeout(). If the timeout is not set or set to 0, then the timeout value is parsed from $SYSTEMD_BUS_TIMEOUT= environment variable. If the environment variable is not set, then built-in timeout is used.
2018-07-13 11:38:47 +03:00
* `$SYSTEMD_BUS_TIMEOUT=SECS` — specifies the maximum time to wait for method call
completion. If no time unit is specified, assumes seconds. The usual other units
are understood, too (us, ms, s, min, h, d, w, month, y). If it is not set or set
to 0, then the built-in default is used.
locale-util: add logic to output smiley emojis at various happiness levels
2018-11-06 19:59:58 +03:00
* `$SYSTEMD_MEMPOOL=0` — if set, the internal memory caching logic employed by
hashmap: add an environment variable to turn off the memory pool used by hashmaps Triggered by https://bugzilla.redhat.com/show_bug.cgi?id=1609349
2018-08-03 17:45:21 +03:00
hash tables is turned off, and libc malloc() is used for all allocations.
locale-util: add logic to output smiley emojis at various happiness levels
2018-11-06 19:59:58 +03:00
* `$SYSTEMD_EMOJI=0` — if set, tools such as "systemd-analyze security" will
not output graphical smiley emojis, but ASCII alternatives instead. Note that
this only controls use of Unicode emoji glyphs, and has no effect on other
Unicode glyphs.
cryptsetup-generator: allow overriding /run/systemd/cryptsetup with $RUNTIME_DIRECTORY I added a fairly vague entry to docs/ENVIRONMENT because I think it is worth mentioning there (in case someone is looking for any environment variable that might be relevant).
2019-11-13 14:06:58 +03:00
* `$RUNTIME_DIRECTORY` — various tools use this variable to locate the
appropriate path under /run. This variable is also set by the manager when
RuntimeDirectory= is used, see systemd.exec(5).
shared: split out crypt() specific helpers into its own .c/.h in src/shared/ This way we can use libxcrypt specific functionality such as crypt_gensalt() and thus take benefit of the newer algorithms libxcrypt implements. (Also adds support for a new env var $SYSTEMD_CRYPT_PREFIX which may be used to select the hash algorithm to use for libxcrypt.) Also, let's move the weird crypt.h inclusion into libcrypt.h so that there's a single place for it.
2019-11-14 01:13:42 +03:00
* `$SYSTEMD_CRYPT_PREFIX` — if set configures the hash method prefix to use for
UNIX crypt() when generating passwords. By default the system's "preferred
method" is used, but this can be overridden with this environment
variable. Takes a prefix such as `$6$` or `$y$`. (Note that this is only
honoured on systems built with libxcrypt and is ignored on systems using
glibc's original, internal crypt() implementation.)
random-util: Add an environment variable to disable RDRAND. SYSTEMD_RDRAND=0 will prevent using RDRAND even on systems whose CPUID claims to support it. All other values have no effect. Fixes: #17112
2020-09-24 00:19:09 +03:00
* `$SYSTEMD_RDRAND=0` — if set, the RDRAND instruction will never be used,
even if the CPU supports it.
seccomp: allow turning off of seccomp filtering via env var Fixes: #17504 (While we are it, also move $SYSTEMD_SECCOMP_LOG= env var description into the right document section) Also suggested in: https://github.com/systemd/systemd/issues/17245#issuecomment-704773603
2020-11-02 16:51:10 +03:00
* `$SYSTEMD_SECCOMP=0` – if set, seccomp filters will not be enforced, even if
support for it is compiled in and available in the kernel.
* `$SYSTEMD_LOG_SECCOMP=1` — if set, system calls blocked by seccomp filtering,
for example in systemd-nspawn, will be logged to the audit log, if the current
kernel version supports this.
Add a bit of documentation for the various undocumented environment variables we honour
2016-11-24 19:47:39 +03:00
systemctl:
* `$SYSTEMCTL_FORCE_BUS=1` — if set, do not connect to PID1's private D-Bus
listener, and instead always connect through the dbus-daemon D-bus broker.
* `$SYSTEMCTL_INSTALL_CLIENT_SIDE=1` — if set, enable or disable unit files on
the client side, instead of asking PID 1 to do this.
* `$SYSTEMCTL_SKIP_SYSV=1` — if set, do not call out to SysV compatibility hooks.
systemd-nspawn:
nspawn: rename UNIFIED_CGROUP_HIERARCHY to SYSTEMD_NSPAWN_UNIFIED_HIERARCHY We should never have used an unprefixed environment variable name. All other systemd-nspawn variables have the "SYSTEMD_NSPAWN_" prefix, and all other systemd variables have the "SYSTEMD_" prefix. The new variable name takes precedence, but we fall back to checking the old one. If only the old one is found, a warning is emitted. In addition, SYSTEMD_NSPAWN_UNIFIED_HIERARCHY="" is accepted as an override to avoid looking for the old variable name. We have a variable with the same name ($UNIFIED_CGROUP_HIERARCHY) in tests, which governs both systemd-nspawn and qemu behaviour. It is not renamed.
2019-09-27 15:17:41 +03:00
* `$SYSTEMD_NSPAWN_UNIFIED_HIERARCHY=1` — if set, force nspawn into unified
cgroup hierarchy mode.
Add a bit of documentation for the various undocumented environment variables we honour
2016-11-24 19:47:39 +03:00
* `$SYSTEMD_NSPAWN_API_VFS_WRITABLE=1` — if set, make /sys and /proc/sys and
friends writable in the container. If set to "network", leave only
/proc/sys/net writable.
* `$SYSTEMD_NSPAWN_CONTAINER_SERVICE=…` — override the "service" name nspawn
uses to register with machined. If unset defaults to "nspawn", but with this
variable may be set to any other value.
* `$SYSTEMD_NSPAWN_USE_CGNS=0` — if set, do not use cgroup namespacing, even if
it is available.
* `$SYSTEMD_NSPAWN_LOCK=0` — if set, do not lock container images when running.
nspawn: optionally don't mount a tmpfs over /tmp (#10294) nspawn: optionally, don't mount a tmpfs on /tmp Fixes: #10260
2018-10-08 19:32:03 +03:00
* `$SYSTEMD_NSPAWN_TMPFS_TMP=0` — if set, do not overmount /tmp in the
container with a tmpfs, but leave the directory from the image in place.
Add a bit of documentation for the various undocumented environment variables we honour
2016-11-24 19:47:39 +03:00
systemd-logind:
* `$SYSTEMD_BYPASS_HIBERNATION_MEMORY_CHECK=1` — if set, report that
hibernation is available even if the swap devices do not provide enough room
for it.
Rename $TEST_DIR to $SYSTEMD_TEST_DATA, document it TEST_DIR is rather generic, and we prefix all variables used by installed executables with "SYSTEMD_".
2017-02-15 03:17:38 +03:00
docs: document the new environment variables logind groks
2018-10-23 16:53:18 +03:00
* `$SYSTEMD_REBOOT_TO_FIRMWARE_SETUP` — if set overrides systemd-logind's
built-in EFI logic of requesting a reboot into the firmware. Takes a
boolean. If set to false the functionality is turned off entirely. If set to
true instead of requesting a reboot into the firmware setup UI through EFI a
file `/run/systemd/reboot-to-firmware-setup` is created whenever this is
requested. This file may be checked for by services run during system
shutdown in order to request the appropriate operation from the firmware in
an alternative fashion.
* `$SYSTEMD_REBOOT_TO_BOOT_LOADER_MENU` — similar to the above, allows
overriding of systemd-logind's built-in EFI logic of requesting a reboot into
the boot loader menu. Takes a boolean. If set to false the functionality is
turned off entirely. If set to true instead of requesting a reboot into the
boot loader menu through EFI a file `/run/systemd/reboot-to-boot-loader-menu`
is created whenever this is requested. The file contains the requested boot
loader menu timeout in µs, formatted in ASCII decimals, or zero in case no
tree-wide: s/time-out/timeout/g See 3f9a0a522f2029e9295ea5e9984259022be88413 for justification.
2020-05-22 10:39:36 +03:00
timeout is requested. This file may be checked for by services run during
docs: document the new environment variables logind groks
2018-10-23 16:53:18 +03:00
system shutdown in order to request the appropriate operation from the boot
loader in an alternative fashion.
* `$SYSTEMD_REBOOT_TO_BOOT_LOADER_ENTRY` — similar to the above, allows
overriding of systemd-logind's built-in EFI logic of requesting a reboot into
a specific boot loader entry. Takes a boolean. If set to false the
functionality is turned off entirely. If set to true instead of requesting a
reboot into a specific boot loader entry through EFI a file
`/run/systemd/reboot-to-boot-loader-entry` is created whenever this is
requested. The file contains the requested boot loader entry identifier. This
file may be checked for by services run during system shutdown in order to
request the appropriate operation from the boot loader in an alternative
fashion. Note that by default only boot loader entries which follow the [Boot
Loader Specification](https://systemd.io/BOOT_LOADER_SPECIFICATION) and are
placed in the ESP or the Extended Boot Loader partition may be selected this
way. However, if a directory `/run/boot-loader-entries/` exists, the entries
are loaded from there instead. The directory should contain the usual
directory hierarchy mandated by the Boot Loader Specification, i.e. the entry
drop-ins should be placed in
`/run/boot-loader-entries/loader/entries/*.conf`, and the files referenced by
the drop-ins (including the kernels and initrds) somewhere else below
`/run/boot-loader-entries/`. Note that all these files may be (and are
supposed to be) symlinks. systemd-logind will load these files on-demand,
these files can hence be updated (ideally atomically) whenever the boot
loader configuration changes. A foreign boot loader installer script should
hence synthesize drop-in snippets and symlinks for all boot entries at boot
or whenever they change if it wants to integrate with systemd-logind's APIs.
docs/ENVIRONMENT: move entry for systemd-udevd `$SYSTEMD_REBOOT_TO_FIRMWARE_SETUP=` or friends are for logind.
2021-01-26 15:52:12 +03:00
systemd-udevd:
* `$NET_NAMING_SCHEME=` – if set, takes a network naming scheme (i.e. one of
"v238", "v239", "v240"…, or the special value "latest") as parameter. If
specified udev's net_id builtin will follow the specified naming scheme when
determining stable network interface names. This may be used to revert to
naming schemes of older udev versions, in order to provide more stable naming
across updates. This environment variable takes precedence over the kernel
command line option `net.naming-scheme=`, except if the value is prefixed
with `:` in which case the kernel command line option takes precedence, if it
is specified as well.
Rename $TEST_DIR to $SYSTEMD_TEST_DATA, document it TEST_DIR is rather generic, and we prefix all variables used by installed executables with "SYSTEMD_".
2017-02-15 03:17:38 +03:00
installed systemd tests:
* `$SYSTEMD_TEST_DATA` — override the location of test data. This is useful if
a test executable is moved to an arbitrary location.
documentation: document nss-systemd's internal environment variables in ENVIRONMENT.md
2017-09-20 19:28:29 +03:00
nss-systemd:
* `$SYSTEMD_NSS_BYPASS_SYNTHETIC=1` — if set, `nss-systemd` won't synthesize
user/group records for the `root` and `nobody` users if they are missing from
`/etc/passwd`.
* `$SYSTEMD_NSS_DYNAMIC_BYPASS=1` — if set, `nss-systemd` won't return
user/group records for dynamically registered service users (i.e. users
registered through `DynamicUser=1`).
* `$SYSTEMD_NSS_BYPASS_BUS=1` — if set, `nss-systemd` won't use D-Bus to do
dynamic user lookups. This is primarily useful to make `nss-systemd` work
safely from within `dbus-daemon`.
doc: add $SYSTEMD_TIMEDATED_NTP_SERVICES= in ENVIRONMENT.md (#8785)
2018-04-23 11:14:15 +03:00
systemd-timedated:
* `$SYSTEMD_TIMEDATED_NTP_SERVICES=…` — colon-separated list of unit names of
NTP client services. If set, `timedatectl set-ntp on` enables and starts the
first existing unit listed in the environment variable, and
`timedatectl set-ntp off` disables and stops all listed units.
doc: document the two new env vars set by the service manager
2018-07-04 16:36:06 +03:00
sulogin-shell: Use force if SYSTEMD_SULOGIN_FORCE set When the root account is locked sulogin will either inform you of this and not allow you in or if --force is used it will hand you passwordless root (if using a recent enough version of util-linux). Not being allowed a shell is ofcourse inconvenient, but at the same time handing out passwordless root unconditionally is probably not a good idea everywhere. This patch thus allows to control which behaviour you want by setting the SYSTEMD_SULOGIN_FORCE environment variable to true or false to control the behaviour, eg. via adding this to 'systemctl edit rescue.service' (or emergency.service): [Service] Environment=SYSTEMD_SULOGIN_FORCE=1 Distributions who used locked root accounts and want the passwordless behaviour could thus simply drop in the override file in /etc/systemd/system/rescue.service.d/override.conf Fixes: #7115 Addresses: https://bugs.debian.org/802211
2018-10-14 15:53:09 +03:00
systemd-sulogin-shell:
* `$SYSTEMD_SULOGIN_FORCE=1` — This skips asking for the root password if the
root password is not available (such as when the root account is locked).
See `sulogin(8)` for more details.
efi: allow ESP validity checks to be turned off let's add an env var for this, as this really shouldn't be a top-level feature, as it turning off the validity checks certainly isn't advisable. Fixes: #4925
2018-06-25 16:08:24 +03:00
bootctl and other tools that access the EFI System Partition (ESP):
* `$SYSTEMD_RELAX_ESP_CHECKS=1` — if set, the ESP validation checks are
relaxed. Specifically, validation checks that ensure the specified ESP path
is a FAT file system are turned off, as are checks that the path is located
on a GPT partition with the correct type UUID.
bootspec: introduce SYSTEMD_ESP_PATH for overriding where to look for the ESP (#10834)
2018-11-20 06:37:01 +03:00
* `$SYSTEMD_ESP_PATH=…` — override the path to the EFI System Partition. This
may be used to override ESP path auto detection, and redirect any accesses to
the ESP to the specified directory. Not that unlike with bootctl's --path=
switch only very superficial validation of the specified path is done when
this environment variable is used.
doc: document the two new env vars set by the service manager
2018-07-04 16:36:06 +03:00
systemd itself:
* `$SYSTEMD_ACTIVATION_UNIT` — set for all NSS and PAM module invocations that
are done by the service manager on behalf of a specific unit, in child
processes that are later (after execve()) going to become unit
processes. Contains the full unit name (e.g. "foobar.service"). NSS and PAM
modules can use this information to determine in which context and on whose
behalf they are being called, which may be useful to avoid deadlocks, for
example to bypass IPC calls to the very service that is about to be
started. Note that NSS and PAM modules should be careful to only rely on this
data when invoked privileged, or possibly only when getppid() returns 1, as
setting environment variables is of course possible in any even unprivileged
contexts.
* `$SYSTEMD_ACTIVATION_SCOPE` — closely related to `$SYSTEMD_ACTIVATION_UNIT`,
it is either set to `system` or `user` depending on whether the NSS/PAM
module is called by systemd in `--system` or `--user` mode.
remount-fs: optionally remount / writable, if we are told through an env var
2018-11-23 21:47:41 +03:00
systemd-remount-fs:
docs: fix typos and duplicate words s/and and/and/ s/explicity/explicitly/ s/that that/that/ s/the the/the/ s/is is/it is/ s/overriden/overridden/
2019-06-27 10:54:20 +03:00
* `$SYSTEMD_REMOUNT_ROOT_RW=1` — if set and no entry for the root directory
remount-fs: optionally remount / writable, if we are told through an env var
2018-11-23 21:47:41 +03:00
exists in /etc/fstab (this file always takes precedence), then the root
directory is remounted writable. This is primarily used by
systemd-gpt-auto-generator to ensure the root partition is mounted writable
in accordance to the GPT partition flags.
locale-util: suppress non-UTF-8 locales when enumerating them Let's hide non-UTF-8 locales by default. It's 2019 after all. Let's add an undocumented env var to reenable listing them though. This should substantially shorten the list of choices we offer users, and only show realistic choices. note that only firstboot and localectl make use of this information, and both allow configuration of values outside of these lists, hence all this change does is hide legacy options, but they are still available if you know what you do, and that's how it should be.
2019-07-12 14:38:43 +03:00
systemd-firstboot and localectl:
* `SYSTEMD_LIST_NON_UTF8_LOCALES=1` – if set non-UTF-8 locales are listed among
the installed ones. By default non-UTF-8 locales are suppressed from the
selection, since we are living in the 21st century.
man: add man page for systemd-sysext
2021-01-12 16:55:11 +03:00
systemd-sysext:
* `SYSTEMD_SYSEXT_HIERARCHIES` – if set to a colon-separated list of absolute
paths this variable may be used to override which hierarchies to manage with
`systemd-sysext`. By default only `/usr/` and `/opt/` are managed. With this
environment variable this list may be changed, in order to add or remove
directories from this list. This should only reference "real" file systems
and directories that only contain "real" file systems as submounts — do not
specify API file systems such as `/proc/` or `/sys/` here, or hierarchies
that have them as submounts. In particular, do not specify the root directory
`/` here.
tmpfiles: v/q/Q: Add env var to skip check for rootfs in subvolume
2021-02-10 00:20:32 +03:00
systemd-tmpfiles:
* `SYSTEMD_TMPFILES_FORCE_SUBVOL` - if unset, v/q/Q lines will create subvolumes only if the
OS itself is installed into a subvolume. If set to 1 (or another true value), these lines will always create
subvolumes (if the backing filesystem supports them). If set to 0, these lines will always create directories.
Copy Permalink