I think it makes sense to keep the "The" in place for the actual page's
title, but let's drop it from the categorization header, to make it
easier to find stuff, as the "The" isn't helpful to that.
In particular as we sometimes do it this and sometimes the other way so
far, hence let's stick to one common rule.
In the wiki, this was a separate page. I don't think this split is useful,
since the information about what is stable and what not seems randomly split
between the two pages.
Links are adjusted for our own pages. Some external links to gentoo and other
projects seem to be broken, but it's a chore to fix them.
Instead of saying that patches for portability are not accepted, say that this
is decided case-by-case. This is what happens in practice, and we tend to
discuss each patch on its own merits.
Some sentences are reworded a bit where they sound awkward.
The only non-stylistic change is to replace descriptions of how we are
encouraging people to use PrivateTmp= and such, because now they are widely
used.
@bertob wants us to be strict here, and only have one "#" header per
markdown file, and use "##" (or "###", …) for all others. Interestingly,
we mostly got this right already, but this fixes a few cases where this
wasn't correct.
Let's use the rough categorization of the markdown pages to add basic
sections, via Jeykll templating. Also, add in a couple of additional
links via a JSON array that lists them.
So much web development, so much wow!
Doing this manually seem to work only so well, but it is indeed hard to generate
automatically. Let's add the stuff that is missing for now.
AddRef= is not a unit file setting, remove it from the list.
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.
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).
Device tree overlays are a convenient way to patch device trees, e.g.,
add new devices to a device tree or enable/disable devices. This is
useful for non-discoverable but configurable hardware. Device tree
overlays are commonly used for displays on the Raspberry Pi or for
describing the content of FPGA bitstreams.
Add the devicetree-overlay key to boot loader specification entries to
allow boot loaders to apply overlays.
See #13537
Just as `RuntimeMaxSec=` is supported for service units, add support for
it to scope units. This will gracefully kill a scope after the timeout
expires from the moment the scope enters the running state.
This could be used for time-limited login sessions, for example.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
Fixes: #12035
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.
Introduce support for configuring cpus and mems for processes using
cgroup v2 CPUSET controller. This allows users to limit which cpus
and memory NUMA nodes can be used by processes to better utilize
system resources.
The cgroup v2 interfaces to control it are cpuset.cpus and cpuset.mems
where the requested configuration is written. However, it doesn't mean
that the requested configuration will be actually used as parent cgroup
may limit the cpus or mems as well. In order to reflect the real
configuration cgroup v2 provides read-only files cpuset.cpus.effective
and cpuset.mems.effective which are exported to users as well.
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.
In the past, we asked people to open a security bug on one of the "big"
distros. This worked OK as far as getting bugs reported and notifying some
upstream developers went. But we always had trouble getting information to
all the appropriate parties, because each time a bug was reported, a big
thread was created, with a growing CC list. People who were not CCed early
enough were missing some information, etc.
To clean this up, we decided to create a private mailing list. The natural
place would be freedesktop.org, but unfortunately the request to create a
mailing list wasn't handled
(https://gitlab.freedesktop.org/freedesktop/freedesktop/issues/134). And even
if it was, at this point, if there was ever another administrative issue, it
seems likely it could take months to resolve. So instead, we asked for a list
to be created on the redhat mailservers.
Please consider the previous security issue reporting mechanisms rescinded, and
send any senstive bugs to systemd-security@redhat.com.
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.
It was only used for exactly one thing: to substitute in the text in
/var/log/README. But it's use there was completely wrong, because the text
talks about "missing" log files from syslog, so even if we configured systemd
to log to a different directory, the "missing" log files would still be
"missing" from the old location.
Not everybody has those dirs in the filesystem (and they don't need to).
When creating an installation package using $DESTDIR, it is easy enough to
remove or ignore those directories, but if installing into a real root, it
is ugly to create and remove them. Let's add an option so people can skip
it if they want.
Inspired by #12930.
includes two travis ci steps:
1) Every pull-request/push all fuzzing targets will do a quick
sanity run on the generated corpus and crashes (via Fuzzit)
2) On a daily basis the fuzzing targets will be compiled (from
master) and will and their respectible fuzzing job on Fuzzit
will be updated to the new binary.
When shooting down a service with SIGABRT the user might want to have a
much longer stop timeout than on regular stops/shutdowns. Especially in
the face of short stop timeouts the time might not be sufficient to
write huge core dumps before the service is killed.
This commit adds a dedicated (Default)TimeoutAbortSec= timer that is
used when stopping a service via SIGABRT. In all other cases the
existing TimeoutStopSec= is used. The timer value is unset by default
to skip the special handling and use TimeoutStopSec= for state
'stop-watchdog' to keep the old behaviour.
If the service is in state 'stop-watchdog' and the service should be
stopped explicitly we still go to 'stop-sigterm' and re-apply the usual
TimeoutStopSec= timeout.
In cgroup v2 we have protection tunables -- currently MemoryLow and
MemoryMin (there will be more in future for other resources, too). The
design of these protection tunables requires not only intermediate
cgroups to propagate protections, but also the units at the leaf of that
resource's operation to accept it (by setting MemoryLow or MemoryMin).
This makes sense from an low-level API design perspective, but it's a
good idea to also have a higher-level abstraction that can, by default,
propagate these resources to children recursively. In this patch, this
happens by having descendants set memory.low to N if their ancestor has
DefaultMemoryLow=N -- assuming they don't set a separate MemoryLow
value.
Any affected unit can opt out of this propagation by manually setting
`MemoryLow` to some value in its unit configuration. A unit can also
stop further propagation by setting `DefaultMemoryLow=` with no
argument. This removes further propagation in the subtree, but has no
effect on the unit itself (for that, use `MemoryLow=0`).
Our use case in production is simplifying the configuration of machines
which heavily rely on memory protection tunables, but currently require
tweaking a huge number of unit files to make that a reality. This
directive makes that significantly less fragile, and decreases the risk
of misconfiguration.
After this patch is merged, I will implement DefaultMemoryMin= using the
same principles.
Cloudflare public DNS service is currently the fastest one according to
https://www.dnsperf.com/#!dns-resolvers. Why not improve the experience for
systemd users using this as a default fallback nameserver?
This new setting allows configuration of CFS period on the CPU cgroup, instead
of using a hardcoded default of 100ms.
Tested:
- Legacy cgroup + Unified cgroup
- systemctl set-property
- systemctl show
- Confirmed that the cgroup settings (such as cpu.cfs_period_ns) were set
appropriately, including updating the CPU quota (cpu.cfs_quota_ns) when
CPUQuotaPeriodSec= is updated.
- Checked that clamping works properly when either period or (quota * period)
are below the resolution of 1ms, or if period is above the max of 1s.
… requirement for portable service images.
systemd will mount the host machine-id and resolv.conf at these
locations, so for read-only images these must exist in the image,
because they can't be created.
Nitpicky, but we've used a lot of random spacings and names in the past,
but we're trying to be completely consistent on "cgroup vN" now.
Generated by `fd -0 | xargs -0 -n1 sed -ri --follow-symlinks 's/cgroups? ?v?([0-9])/cgroup v\1/gI'`.
I manually ignored places where it's not appropriate to replace (eg.
"cgroup2" fstype and in src/shared/linux).
This uses a {% for %} loop in Jekyll to render the page, from the "title"
information in the Front Matter of the actual page files.
This also makes `make-index-md` build rule unnecessary, since generation is
done by the template engine itself.
Tested this by running Jekyll locally.
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.
From WordNet (r) 3.0 (2006) [wn]:
time-out
n 1: a brief suspension of play; "each team has two time-outs left"
From The Free On-line Dictionary of Computing (18 March 2015) [foldoc]:
timeout
A period of time after which an error condition is raised if
some event has not occured. A common example is sending a
message. If the receiver does not acknowledge the message
within some preset timeout period, a transmission error is
assumed to have occured.
This is useful for distributions, where the stability of interface names should
be preseved after an upgrade of systemd. So when some specific release of the
distro is made available, systemd defaults to the latest & greatest naming
scheme, and subsequent updates set the same default. This default may still
be overriden through the kernel and env var options.
A special value "latest" is also allowed. Without a specific name, it is harder
to verride from meson. In case of 'combo' options, meson reads the default
during the initial configuration, and "remembers" this choice. When systemd is
updated, old build/ directories could keep the old default, which would be
annoying. Hence, "latest" is introduced to make it explicit, yet follow the
upstream. This is actually useful for the user too, because it may be used
as an override, without having to actually specify a version.
With this we can stabilize how naming works for network interfaces. A
user can request through a kernel cmdline option or an env var which
scheme to follow. The idea is that installers use this to set into stone
(a very soft stone though) the scheme used during installation so that
interface naming doesn't change afterwards anymore.
Why use env vars and kernel cmdline options, and not a config file of
its own?
Well, first of all there's no obvious existing one to use. But more
importantly: I have the feeling that this logic is kind of an incomplete
hack, and I simply don't want to do advertise this as a perfectly
working solution. So far we used env vars for the non-so-official
options and proper config files for the official stuff. Given how
incomplete this logic is (i.e. the big variable for naming remains the
kernel, which might expose sysfs attributes in newer versions that we
check for and didn't exist in older versions — and other problems like
this), I am simply not confident in giving this first-class exposure in
a primary configuration file.
Fixes: #10448
This imports the wiki page for predictable interface names. I think it's
useful to preserve history here because it's a contentious subject, and
it's useful to know when what happened.
Patches are shown on github with a fixed width (no matter how wide the window
is). When line numbers are high (we have some files with 5 digit line numbers),
the diff does not fit, and horizontal scrolling must be used when viewing the
patch. This is super annoying. Let's reduce the width a bit. I think 109 is
still very wide, but at least the github issue should be alleviated.
add new "systemd-run-generator" for running arbitrary commands from the kernel command line as system services using the "systemd.run=" kernel command line switch
This adds SuccessActionExitStatus= and FailureActionExitStatus= that may
be used to configure the exit status to propagate in when
SuccessAction=exit or FailureAction=exit is used.
When not specified let's also propagate the exit status of the main
process we fork off for the unit.
The rule is changed from "put in basic unless there's a reason not to" to "put
in shared unless there's a reason not to", to match the change done in previous
commit. This minimizes libbasic. See previous commit for the reasons why this
is useful.
Previously, the guideline was based on whether the files in question use
"publicly exported APIs". This distinction is not particularly relevant. Let's
consider all other programs we compile: most of them use "publicly exported
APIs", usually linking to libsystemd-shared.so for the actual code. But those
programs are not forced to be in src/basic, and the distinction whether they
happen to use 'sd-*.h' or not is of no importance. The same is true for files
in src/shared/. If we didn't have publicly exported shared objects, we'd put
everything in libsystemd-shared.so. So let's only move things out of it that we
need to. Previous guideline was not "wrong", in the sense that it created *a*
split that was functional (no code in src/shared was required in the publicly
exported shared objects), but it put more files in basic/ then necessary.
Not much changes in practice, because (as previous commit shows), moving files
between libbasic.a and libsystemd-shared.so mostly just changes compilation
order.
The list of components which cannot use libsystemd-shared.so is adjusted.
The existing text already said "See below regarding a recommended
vocabulary for boot loader entry identifiers.", but the section for it
was still missing. Let's fill in the missing bits, and describe basic
suggested rules for the boot menu entry identifier vocabulary, in
particular how to identify Windows and MacOS X installations, and how to
name automatic entries vs. explicitly configured ones.
This basically follows the logic implemented in sd-boot these days.
A couple of changes:
1. Clearly name the drop-in entry files "Type #1", and the unified
kernel images "Type #2", and be clearer that the latter is specific
to UEFI.
2. Suffix all directory paths with a trailing "/" to clarify that these
are directories. Also, enclose them all in ``.
3. Add introductory paragraph that explains that there is Type #1 and
Type #2 and what they are about.
4. Explain that Type #2 is about signed UEFI SecureBoot.
5. Don't claim that $BOOT/loader/ contains really all files defined by
the spec, because that's not true, Type #2 images are not located there
after all.
Fixes: #10399
Add LogRateLimitIntervalSec= and LogRateLimitBurst= options for
services. If provided, these values get passed to the journald
client context, and those values are used in the rate limiting
function in the journal over the the journald.conf values.
Part of #10230
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
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
Zbigniew Jędrzejewski-Szmek