IF YOU WOULD LIKE TO GET AN ACCOUNT, please write an
email to Administrator. User accounts are meant only to access repo
and report issues and/or generate pull requests.
This is a purpose-specific Git hosting for
BaseALT
projects. Thank you for your understanding!
Только зарегистрированные пользователи имеют доступ к сервису!
Для получения аккаунта, обратитесь к администратору.
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.
When the spec was initially written, we didn't add good documentation of how to
display the notes, also because there was no good way to display the data
except manually extracting the section to a file and running 'jq' on that. But
the tools have improved, so let's show the users how easy it is to use this
data.
https://fedoraproject.org/wiki/Changes/RenameNobodyUser, 2018:
> Use "nobody:nobody" as the names for the kernel overflow UID:GID pair, and
> retire the old "nfsnobody" name and the old "nobody:nobody" pair with 99:99
> numbers.
When running unprivileged, checking /proc/1/root doesn't work because
it requires privileges. Instead, let's add an environment variable so
the process that chroot's can tell (systemd) subprocesses whether
they're running in a chroot or not.
- Add the required options to make the package managers non interactive
- Use apt-get instead of apt
- Remove --reinstall from apt-get command so we only install newer packages
- Add --needed to pacman command so we only install newer packages
Currently inhibitors are bypassed unless an explicit request is made to
check for them, or even in that case when the requestor is root or the
same uid as the holder of the lock.
But in many cases this makes it impractical to rely on inhibitor locks.
For example, in Debian there are several convoluted and archaic
workarounds that divert systemctl/reboot to some hacky custom scripts
to try and enforce blocking accidental reboots, when it's not expected
that the requestor will remember to specify the command line option
to enable checking for active inhibitor locks.
Also in many cases one wants to ensure that locks taken by a user are
respected by actions initiated by that same user.
Change logind so that inhibitors checks are not skipped in these
cases, and systemctl so that locks are checked in order to show a
friendly error message rather than "permission denied".
Add new block-weak and delay-weak modes that keep the previous
behaviour unchanged.
Let's document in detail how to build the integration test image and run
the integration tests without building systemd. To streamline the process,
we stop automatically using binaries from build/ when invoking mkosi directly
and don't automatically use a tools tree anymore if systemd on the host is too
old. Instead, we document these options in HACKING.md and change the mkosi meson
target to automatically use the current build directory as an extra binary search
path for mkosi.
Makes it possible to specify URLs to a changelog and an appstream
catalog XML in the sysupdate.d/*.conf files. This will be passed along
to the clients of systemd-sysupdated, which can then present this data.
In https://github.com/systemd/mkosi/pull/2847, the '@' specifier is
removed, CLI arguments take priority over configuration files again
and the "main" image is defined at the top level instead of in
mkosi.images/. Additionally, not every setting from the top level
configuration is inherited by the images in mkosi.images/ anymore,
only settings which make sense to be inherited are inherited.
This commit gets rid of all the usages of '@', moves the "main" image
configuration from mkosi.images/system to the top level and gets rid
of various hacks we had in place to deal with quirks of the old
configuration parsing logic.
We also remove usages of Images= and --append as these options are
removed by the mentioned PR.
Otherwise fixfiles will try to relabel it which could potentially
lead to disaster. We also change the recommendation in HACKING.md
to set the default so that TEST-06-SELINUX can override it.
Let's mention the new way to install the latest changes without
rebuilding the image. Let's also remove the duplicate info about
distribution packages that is already mentioned in its own section.
In some recent PRs (e.g. #32628) I started to systematically name return
parameters that shall only be initialized on failure (because they carry
additional error meta information, such as the line/column number of
parse failures or so). Let's make this official in the coding style.
