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!
Только зарегистрированные пользователи имеют доступ к сервису!
Для получения аккаунта, обратитесь к администратору.
As systemd-journal-upload deals mostly with remote servers, add
some failsafes to its unit to restart on failures.
```
[Service]
Restart=on-failure
RestartSteps=10
RestartMaxDelaySec=60
```
No functional changes, only moving code that is only needed in
exec_invoke, and adding new dependencies for seccomp/selinux/apparmor/pam
in meson for the sd-executor binary.
Currently we spawn services by forking a child process, doing a bunch
of work, and then exec'ing the service executable.
There are some advantages to this approach:
- quick: we immediately have access to all the enourmous amount of
state simply by virtue of sharing the memory with the parent
- easy to refactor and add features
- part of the same binary, will never be out of sync
There are however significant drawbacks:
- doing work after fork and before exec is against glibc's supported
case for several APIs we call
- copy-on-write trap: anytime any memory is touched in either parent
or child, a copy of that page will be triggered
- memory footprint of the child process will be memory footprint of
PID1, but using the cgroup memory limits of the unit
The last issue is especially problematic on resource constrained
systems where hard memory caps are enforced and swap is not allowed.
As soon as PID1 is under load, with no page out due to no swap, and a
service with a low MemoryMax= tries to start, hilarity ensues.
Add a new systemd-executor binary, that is able to receive all the
required state via memfd, deserialize it, prepare the appropriate
data structures and call exec_child.
Use posix_spawn which uses CLONE_VM + CLONE_VFORK, to ensure there is
no copy-on-write (same address space will be used, and parent process
will be frozen, until exec).
The sd-executor binary is pinned by FD on startup, so that we can
guarantee there will be no incompatibilities during upgrades.
If we encounter an empty struct in the varlink IDL it could also be an
empty enum. Refuse this to avoid the ambiguity.
The spec doesn't cover this case clearly, hence let's better be on the
safe side and refuse it rather than making a decision what it means.
The parsing is done after the image has been opened, not before, as it
cannot be done on an block device. Also fix returning on any error for
ExtensionDirectories, not just ENOENT.
Follow-up for 55ea4ef096
We already had a similar check that was removed, see
8340b762e4 (*). The kernel supports loading of a
resume image from a different kernel version. This makes sense, because the
goal of "resume" is to replace the running system by a saved memory image, so
it doesn't really matter that the short-lived kernel is different.
By removing the check, we make the process more reliable: for example, the user
may select a different kernel from a list, or not have the previously running
kernel in /boot at all, etc. Requiring the exact same kernel version makes the
process more fragile for no benefit.
Similar reasoning holds for the image version: the image may be updated, and
for example an older kernel+initrd might be used, with an embedded VERSION_ID
that is not the latest. This is fine, and the check is not useful.
I left the check for ID/IMAGE_ID: we probably don't want to use the resume
image if the hibernation was done from a different installation.
(Note: why not check VERSION_ID/IMAGE_VERSION? Because of the following
scenario: a user has an installation of Fedora 35, and they upgrade to Fedora
36, which means that the os-release file on disk gets replaced and now
specifies VERSION_ID=36. But the running kernel is not replaced, and its
package is not removed because the running kernel version is never removed, so
we still have a boot entry that in initrd-release says VERSION_ID=35. Without
rebooting, the user does hibernation. When resuming, we want to resume, no
matter if one of the new entries with VERSION_ID=36 or one of the old entries
with VERSION_ID=35 is picked in the boot loader menu.
If the installation is image-based, i.e. it has IMAGE_ID+IMAGE_VERSION, the
situation is similar: after an upgrade, we may still have an boot entry from
before the upgrade. Using an older kernel+initrd to boot and switch-root into a
newer installation is supported and is rather common.
In fact, it is a rather common situation that the version reported by the boot
entry (or stored internally in the initrd-release in the initrd) does not match
the actual system on disk. Generally, this metadata is saved when the boot menu
entry is written and does not reflect subsequent upgrades. Various
distributions generally keep at least 3 kernels after a upgrade, and during an
upgrade only install one new, which means that after a major upgrade, generally
there will be at least two kernels which have mismatched version information.)
OTOH, I think it is useful to *write* all the details to the EFI var. As
discussed in https://github.com/systemd/systemd/issues/29037, we may want to
show this information in the boot loader. It is also useful for debugging.
(*) Also again discussed and verified in
https://github.com/systemd/systemd/pull/27330#discussion_r1234332080.
", ignored" is dropped, since this failure is likely to cause the following
check to fail. Better not to say anything then to say the misleading thing.
This reverts commit 0e3cc902fa.
Fixes#10288.
I have confirmed that this does now fix cross-compilation.
It appears that changes upstream in Meson, probably mesonbuild/meson#5263, have made the original MR, #10289, work now.
This needs to be tested to ensure that it doesn't break Travis CI like when it was reverted in #10361.
Some of the entries are really configured, but we also have a bunch
of automatic entries. Calling them "config entries" is misleading, let's
use the more natural "boot entry".
While at it, rename:
config_load_entries() → config_load_type1_entries()
config_entry_add_unified() → config_load_type2_entries()
config_title_generate() → generate_boot_entry_titles()
config_entry_add_<type>() → config_add_entry_<type>()
No functional change.
When the user pressed + or -, we would set the efivar override, starting
from the default of 0. Instead, set an override that starts at the current
value. This means that when user has e.g. a configured override of 5 s, and
they press +, they get an override of 6 s. I think this is leads to a much
smoother experience for a user, who does not necessarilly need to know that
we have three levels of overrides, they just want to easily configure the
timeout with keys. If they press +, the timeout should increase, and not
jump to some low value.
Also, once an override has been set via the boot menu, i.e. the efivar is set,
do not allow unsetting the efivar from the boot menu. This way we also avoid
an unexpected "jump" to whatever the other sources of configuration specify.
The user can configure any value with the keys that they want, so we don't
need to allow unsetting.
The menu_run() function allows the user to set/unset default entry, or to
increase/decrease menu timeout. After a keypress, status like
"Menu timeout set to 5 s"
is printed, but there actually isn't any immediate effect. The value is only
written right right before booting a menu entry to avoid unnecessary wear&tear
on the nvram storage. This delayed write is supposed to be invisible to the
user.
Nevertheless, operations like reboot into firmware, reboot, or shutdown were
done immediately. We need to exit the loop first, save the state, and only do
the op afterwards.
Fixup for f6531b11d2 and
e6cab77eca.
Also reverts 498d0cc426.
