This takes up a lot of storage space and we're almost hitting the
limit so since nobody's actually using these and we just started
doing nightly builds in OBS, let's drop this and point people towards
OBS for nightly packages in the future.
This makes the UID range configurable via build time options, but of
course it really shouldn't be changed. The default range I picked is
outside even of IPAs current (ridiculously large) allocation ranges,
hence hopefully minimizes conflicts.
"ninja -C build mkosi" doesn't actually work and fails because ninja
thinks the mkosi target does not exist. "meson compile -C build mkosi"
dpes work so let's use that instead.
Fixes#35741
Let's use "mkosi sandbox" in the docs so that users can build systemd
without having to install anything except mkosi. Using mkosi sandbox
will use tools and dependencies from the tools tree which is also used
in CI and thus has a higher chance of working from the first try compared
to whatever tools might be installed on the host system of a new contributor.
The package notes are nice standard mechanism to figure out the exact name and
version of a program or a library stored in a file, without running the code.
In the beginning this was designed for the purpose of analyzing core dumps, but
we've since started to use it more generically to identify files. The same need
to identify PE/COFF files occurs, for example for systemd-boot and other files
intended for UEFI. It has also been requested by people working on bootupd
(https://github.com/coreos/bootupd).
The text is changed to say "Executable" or "ELF or PE/COFF" wherever "ELF" was
used previously.
The description for PE/COFF files is very brief. AFAIK, we don't have the same
"note" mechanism there [1], so just a normal section is used. The alignment
rules for PE/UEFI are different and change over time, so no specific alignment
is specified.
Other requirements for the PE/COFF section are based on what ukify currently
does for the .osrel section:
5 .osrel 00000056 000000010132f000 000000010132f000 0002b600 2**2
CONTENTS, ALLOC, LOAD, READONLY, DATA
The name ".pkgnote" is used as suggested by Daan De Meyer. This corresponds to
the ".note.package" name used for ELF. ".package" was also suggested, but I
think that is too generic and carries more risk of a conflict with a different
use.
[1] https://learn.microsoft.com/en-us/windows/win32/debug/pe-format
Also zero/0 is replaced by NUL to clarify that a single 0 byte is meant.
We described the "how", but not the "why". And the text was a bit dated,
still mostly talking about core files. Let's make it more general
and describe why a section is used.
Add a recommendation/explanation for the debugInfoUrl field.
This document is renamed without any changes in a separate commit.
Otherwise, git does not show a diff, which makes it very hard
to review what is actually changed in the text.
We put a timeline of 257 to remove the old bash test runner so since
we're about to release 257, let's remove the old bash test runner in
favor of the meson + mkosi test runner.
Unfortunately our CI fails pretty much constantly, so instead of saying that
"tests don't pass", weasel this into "unit tests don't pass". Also fix grammar.
Labels are adjusted automatically now, so remove that sentence.
That file provides compatiblity (or more precisely the explanation for the lack
of compatibility) with syslog daemons. Those are used quite independently of
sysvinit. For example, RHEL uses rsyslog with systemd. We create
/var/log/journal, so it's no biggie to also provide /var/log/README with the
explanation. Let's keep it, since it might help some confused users, even when
compat with sysvinit is gone.
The section headers used quotes as if the strings were some constants. But
AFAICT, those are just normal plain-text titles. Also lowercase them, because
this is almost like a table and it's easier to read without capitalization.
We used both, in fact "Devicetree" was more common. But we have a general rule
that we capitalize all words in names and also we have a DeviceTree=
configuration setting, which we cannot change. If we use two different
spelllings, this will make it harder for people to use the correct one in
config files. So use the "DeviceTree" spelling everywhere.
Currently ask_password_auto() will always try to store the password into
the user keyring. Let's make this configurable so that we can configure
ask_password_auto() into the session keyring. This is required when working
with user namespaces, as the user keyring is namespaced by user namespaces
which makes it impossible to share cached keys across user namespaces by using
the user namespace while this is possible with the session keyring.
In mkosi, we want an easy way to set the keyring timeout for every
tool we invoke that might use systemd-ask-password to query for a
password which is then stored in the kernel keyring. Let's make this
possible via a new $SYSTEMD_ASK_PASSWORD_KEYRING_TIMEOUT_SEC environment
variable.
Using an environment variable means we don't have to modify every separate
tool to add a CLI option allowing to specify the timeout. In mkosi specifically,
we'll set up a new session keyring for the mkosi process linked to the user keyring
so that any pins in the user keyring are used if available, and otherwise we'll query
for and store password in mkosi's session keyring with a zero timeout so that they stay
in the keyring until the mkosi process exits at which point they're removed from the
keyring.
When building distribution packages without building an image, the
distribution packages will only be located in mkosi.builddir/ now and
not in mkosi.output/, so update the documentation to reflect that.
Also add installation instructions for distributions other than CentOS/Fedora
while we're at it.
Currently we need ukify with support for --profile and --join-profile
which isn't in an official release yet so mention that a local build
from source might be required.
This will allow units (scopes/slices/services) to override the default
systemd-oomd setting DefaultMemoryPressureDurationSec=.
The semantics of ManagedOOMMemoryPressureDurationSec= are:
- If >= 1 second, overrides DefaultMemoryPressureDurationSec= from oomd.conf
- If is empty, uses DefaultMemoryPressureDurationSec= from oomd.conf
- Ignored if ManagedOOMMemoryPressure= is not "kill"
- Disallowed if < 1 second
Note the corresponding dbus property is DefaultMemoryPressureDurationUSec
which is in microseconds. This is consistent with other time-based
dbus properties.
Similar to 24a4542c. 24a4542c can only be set 1 in 1s at most,
sometimes we may need to set to something else(such as 1 in 2s).
So it's best to let the user decide.
This also allows users to solve #34690.
By default, in instances where timers are running on a realtime schedule,
if a service takes longer to run than the interval of a timer, the
service will immediately start again when the previous invocation finishes.
This is caused by the fact that the next elapse is calculated based on
the last trigger time, which, combined with the fact that the interval
is shorter than the runtime of the service, causes that elapse to be in
the past, which in turn means the timer will trigger as soon as the
service finishes running.
This behavior can be changed by enabling the new DeferReactivation setting,
which will cause the next calendar elapse to be calculated based on when
the trigger unit enters inactivity, rather than the last trigger time.
Thus, if a timer is on an realtime interval, the trigger will always
adhere to that specified interval.
E.g. if you have a timer that runs on a minutely interval, the setting
guarantees that triggers will happen at *:*:00 times, whereas by default
this may skew depending on how long the service runs.
Co-authored-by: Matteo Croce <teknoraver@meta.com>
Add a note to the service-file naming scheme that reminds developers
that those names might be aliases. Hence, when parsing such unit names,
the entire name-array of a unit must be parsed, rather than just the
unit ID.
The service-name of existing applications might be already part of their
API. Hence, not all applications can switch the service ID to this new
naming scheme, but can provide suitable aliases. Document this behavior.
The <RANDOM> part is optional in the naming scheme of application units.
However, this is only true for service files. Scope units must include
the <RANDOM> part, otherwise it would be impossible to parse:
The schema would be:
`app[-<launcher>]-<ApplicationID>[-<RANDOM>].scope`
in which case a two-part name would be impossible to parse, since it is
unclear whether the launcher of the random bit where omitted.
The annotation about omittance is meant to be about the `RANDOM` string.
However, the current formatting makes it look like the entire naming
scheme is optional. Fix this.
Teaches systemd-stub how to load additional initrds from addon files.
This is very similar to the support for .ucode sections in addon files,
but with different ordering. Initrds from addons have a chance to
overwrite files from the base initrd in the UKI.
