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 have some missing coverage in the CI, all builds enable these features,
but there are often changes and they cover a lot of code. Do one build
without them to ensure we don't break builds.
(cherry picked from commit b7b48b389c5e68154f72133ec5d12ca2412aa406)
I was testing transient units and user@.service crashed. I restarted it, and
tried to create a transient unit. It failed because
/run/user/1000/systemd/transient/ remained after the previous aborted run:
Failed to start transient service unit: Unit run-u0.service was already loaded or has a fragment file.
Remove the directory during initial startup so we don't get confused by our own
files.
(cherry picked from commit 45f540a2974dc732820d20a0e73cfffc94766a70)
I was changing how some properties are appended to the StartTransientUnit call
and messed up the message contents. When something is wrong with how the
message is structed, we would return a very generic
"Failed to start transient service unit: No such device or address".
Mention that it was property setting that failed, and translate ENXIO to a
different message. bus_unit_set_properties() or any of the children it calls
may also return other errors, in particular EBADMSG or ENOMEM, but the error
message that is generated for those is understandable, so we don't need to
"translate" them explicitly.
bus_unit_set_properties() is called from two places, so it seems nicer to
generate the message internally, rather than ask the caller to do that. Also,
now bus_unit_set_properties() always sets <error>, which is nicer for the
callers.
(cherry picked from commit 44d82df46e38c5bc36ed3722301eeae15df29763)
We use ConditionControlGroupController=v2 in systemd-oomd.service, and also
this condition makes sense in general, so it should be documented.
This reverts a part of 6d48c7cf736ced70c1c2fef1e1f03618911d04bc.
Deprecated commandline options and v1 controller names were removed from
the description.
(cherry picked from commit c32f496b9e7326584e49ae478539c4bc5c51ebe1)
Let's make the dropin, to make the build dir writable for gcov, a bit
more generic, so it can be used by all units starting with prefix test-.
This should help with a bunch of recent reports about missing coverage I
got, as well as with existing test units using DynamicUser=true.
This might feel a bit like a magic trick from behind the curtains, but I
want to touch the actual tests as little as possible, since it makes them
unnecessarily messy (see the various workarounds for sanitizers), and
the coverage reports are generated only in a specific CI job anyway.
(cherry picked from commit e660c590a5222bc72f7aea8912806aa48b0fb126)
Fixes: https://bugzilla.redhat.com/show_bug.cgi?id=2055664
Fixes: https://bugzilla.redhat.com/show_bug.cgi?id=2172146
User report that systemd repeatedly logs about not being able to start oomd
when booted with v1:
Feb 20 16:52:33 systemd[1]: systemd-oomd.service - Userspace Out-Of-Memory (OOM) Killer was skipped because of a failed condition check (ConditionControlGroupController=v2).
Feb 20 16:52:34 systemd[1]: systemd-oomd.service - Userspace Out-Of-Memory (OOM) Killer was skipped because of a failed condition check (ConditionControlGroupController=v2).
Feb 20 16:52:34 systemd[1]: systemd-oomd.service - Userspace Out-Of-Memory (OOM) Killer was skipped because of a failed condition check (ConditionControlGroupController=v2).
Feb 20 16:52:34 systemd[1]: systemd-oomd.service - Userspace Out-Of-Memory (OOM) Killer was skipped because of a failed condition check (ConditionControlGroupController=v2).
Feb 20 16:52:34 systemd[1]: systemd-oomd.service - Userspace Out-Of-Memory (OOM) Killer was skipped because of a failed condition check (ConditionControlGroupController=v2).
Feb 20 16:52:34 systemd[1]: systemd-oomd.service - Userspace Out-Of-Memory (OOM) Killer was skipped because of a failed condition check (ConditionControlGroupController=v2).
Feb 20 16:52:34 systemd[2067491]: Queued start job for default target default.target.
Feb 20 16:52:34 systemd[1]: systemd-oomd.service - Userspace Out-Of-Memory (OOM) Killer was skipped because of a failed condition check (ConditionControlGroupController=v2).
Feb 20 16:52:34 systemd[2067491]: Created slice app.slice - User Application Slice.
Feb 20 16:52:34 systemd[1]: systemd-oomd.service - Userspace Out-Of-Memory (OOM) Killer was skipped because of a failed condition check (ConditionControlGroupController=v2).
systemd-oomd.service that pulls systemd-oomd.socket in (because it requires
it); systemd-oomd.service itself is pulled by user@.service because
systemd-oomd package installs an override config file that sets
ManagedOOMMemoryPressure=kill.
Add a check to the code that adds the implicit dependency to skip the
dep if we cannot start it. The check is done exactly the same as in oomd
itself.
(cherry picked from commit 2a4efebb3ba762468937dd45d0b1cb51a5122fde)
I noticed missing coverage in the reports and turns out this has been
broken since forever (i.e. 2016 - 9f7672b3bc), whoopsie.
(cherry picked from commit 1d6052ba5c9533227bdcc3d3368392726981abaf)
gcov provides wrappers for the exec*() calls but there's none for execveat(),
which means we lose all coverage prior to the call. To mitigate this, let's
add a simple execveat() wrapper in gcov's style[0], which dumps and resets
the coverage data when needed.
This applies only when we're built with -Dfexecve=true.
[0] https://gcc.gnu.org/git/?p=gcc.git;a=blob;f=libgcc/libgcov-interface.c;h=b2ee930864183b78c8826255183ca86e15e21ded;hb=HEAD
(cherry picked from commit 4388541237e3cdab6821c1b626bb6314027277b4)
Otherwise, if getopt() and friends are used before parse_argv(), then
the GNU extensions may be ignored.
This should not change any behavior at least now, as we usually use
getopt_long() only once per invocation. But in the next commit,
getopt_long() will be used for other arrays, hence this change will
become necessary.
(cherry picked from commit ef9c12b157a50d63e8a8eb710c013d16c2cea319)
- allow to run without $PROJECT_BUILD_ROOT,
- drop unnecessary export for bootctl,
- enable -x option to show commands,
- use 'test ! -e' to check the nonexistence of files,
- show more debugging logs.
(cherry picked from commit 0362953e9a5e472b5cd66687e79a957b37e35e09)
It's a bit nicer if we only write the sysctl core_pattern once the
coredump socket is established, since it's the backend for the handler.
Given the systemd-coredump.socket basically has no dependencies that run
before it this should not really make things slower or so, it just
removes the tiny window where core pattern is in effect that wants to
connect to the backend socket but cannot.
The status quo isn't terrible, and not too different in effect: either
way, until the socket unit is up we won't process coredumps. It's mostly
what kind of behaviour you get then: an error due to /bin/false being
invoked, or an error because systemd-coredump can't connect to its
socket. After this patch we'll exclusively see the former.
(cherry picked from commit 62c72c60b5e6c0712a45b1feccc6cc18151efa9c)
The test log is in the state directory, and we want to keep it around
when a test fails.
Follow-up for: 256a835f1c6c646a55039659aa2db186fbeb5c5d
(cherry picked from commit 49e8342965649503a537beacb77dd0fafc71debe)
For future-proof reasons, in case we will add
another option that starts with --deserialize.
Addresses 4f44d2c4f7 (r107285603)
(cherry picked from commit 09567df7db75824f1b8bf0b5cc721febda03cb56)
Follow-up for d2ebd50d7f9740dcf30e84efc75610af173967d2
We now modify our cmdline to use '=' for all arguments,
but didn't change early setup check to work with that.
So every daemon-reexec does a full setup, thus breaking
running user sessions.
Fixes#27106
(cherry picked from commit 4f44d2c4f76922a4f48dd4473e6abaca40d7e555)
make a github release for every tag that starts with `v*`,
and a pre-release if the tag contains "-rc".
on the 'systemd/systemd' repo, the "Release" will be draft, so that the
release manager can fill up the notes manually.
on 'systemd/systemd-stable' the release will be created immediately.
info about the action used:
https://github.com/softprops/action-gh-release
(cherry picked from commit 86c20937c29da637878a1282444b057bc1a519fb)
Let's make sure we only install the python3 and python39 python
packages, instead of all the packages of all versions that are
packaged.
This also fixes the CentOS 8 CI because python3.11-pytest was failing
to install.
We have to ship our own powertools repo definition because we need to
enable module_hotfixes for powertools to coerce dnf into installing
some of the python packages.
(cherry picked from commit 89de1d983ea84d7147011c52b55aa47a7cce862c)
We shouldn't report that the file is empty if the stating fails. Let's do the
same as in other places, and just ignore the error and let the subsequent
operation fail.
(cherry picked from commit 7d0c47dad0d4282c3924a654a8fe18fc5d7766f8)
Unit names can be 255 characters long, not 256.
We first say "name prefix" and then continue with "unit prefix".
Confusing. Couldn't figure out which term is better hence settled on
"unit name prefix".
(cherry picked from commit 75f7e5e54704e643aa9b50ce03ed02a49e75333f)
Currently, active journal files are excluded, which means that vacuuming
may not remove anything even if *MaxUse= has been exceeded.
(cherry picked from commit 9ea46af4f2368b41d57705bac09774778126507f)
It's a sycall group of our own definition, and the output is erroneous
to claim otherwise. Let's hide it.
This adds syscall_set_add() which is nicely symmetric to the existing
syscall_set_remove().
Follow-up for: 6d6a08547c03f96dc798cda1ef4a8d3013d292d5
(cherry picked from commit 950c0ed38935198a67a57c645e499555eaf006eb)
These three new syscalls are mostly just new flavours or extensions of
existing syscalls, hence add them to the same groups.
(cherry picked from commit 76e86b8dd8cca9f9fee120289945b29e1dbbe215)
My user manager says:
systemd-xdg-autostart-generator[2933]: /home/zbyszek/.config/autostart/org.gnome.Terminal.desktop:256: Unknown key name 'Actions' in section 'Desktop Entry', ignoring.
systemd-xdg-autostart-generator[2933]: /home/zbyszek/.config/autostart/org.gnome.Terminal.desktop:258: Unknown section 'Desktop Action new-window'. Ignoring.
systemd-xdg-autostart-generator[2933]: /home/zbyszek/.config/autostart/org.gnome.Terminal.desktop:343: Unknown section 'Desktop Action preferences'. Ignoring.
systemd-xdg-autostart-generator[2933]: /home/zbyszek/.config/autostart/org.telegram.desktop.desktop:12: Unknown key name 'Actions' in section 'Desktop Entry', ignoring.
systemd-xdg-autostart-generator[2933]: /home/zbyszek/.config/autostart/org.telegram.desktop.desktop:13: Unknown key name 'SingleMainWindow' in section 'Desktop Entry', ignoring.
systemd-xdg-autostart-generator[2933]: /home/zbyszek/.config/autostart/org.telegram.desktop.desktop:19: Unknown section 'Desktop Action Quit'. Ignoring.
This is not useful. Those are externally-provided files, and they are likely to
have entries which we know nothing about.
(cherry picked from commit b5a70eeecdb593f8498c0bc163d5a12297cfb55d)
btrfs_get_block_device_fd() returns -ENOTTY if fstatfs().f_type !=
BTRFS_SUPER_MAGIC
btrfs_get_block_device_fd() is run by verify_fsroot_dir() by
verify_xbootldr() by find_xbootldr_and_warn() if
statx($presumed-XBOOTLDR).stx_dev_major == 0 ("maybe a btrfs device")
Every bootctl verb_install() runs find_xbootldr_and_warn(), by default
with /boot
If your /boot .stx_dev_major=0 but /not/ btrfs, bootctl install/update
quietly exits 1 with no note so as to what exactly failed (debug also
empty, and the strace isn't exactly clear since no syscall actually
failed)
This is the case on ZFS and the Debian filesystem layout: /boot/efi is
the ESP, and everything else under / is ZFS:
$ sudo env SYSTEMD_LOG_LEVEL=debug bootctl update
Found cgroup2 on /sys/fs/cgroup/, full unified hierarchy
Found container virtualization none.
File system "/boot" is not a FAT EFI System Partition (ESP) file system.
Using EFI System Partition at /boot/efi.
Checking whether /boot/efi/EFI/systemd/ contains any files…
$ echo $?
1
and funnier still:
$ sudo bootctl update --graceful
$ echo $?
1
Which is great, and also breaks postinst, which runs precisely the
latter, with no feedback at all
By checking for -ENOTTY we accept that the path being investigated
"is not it" if it's on ZFS (and any other filesystem that returns
.stx_dev_major == 0 but isn't btrfs)
(cherry picked from commit ed89819f8fd7bfe99cd652082076e85e1417e4e9)
Uncompressed aarch64 and riscv64 kernels have a different startpoint than x86.
Example output from ukify:
aarch64: NotImplementedError: unknown file format (starts with b'MZ@\xfa')
riscv64: NotImplementedError: unknown file format (starts with b'MZo\x10')
Add check for (b'MZ') to catch both in one call.
Fix:
https://github.com/systemd/systemd/issues/26923
(cherry picked from commit bf9f07a62966043c0f1fd7ac4a249790643d1f9a)
