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!
Только зарегистрированные пользователи имеют доступ к сервису!
Для получения аккаунта, обратитесь к администратору.
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.
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.
