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!
Только зарегистрированные пользователи имеют доступ к сервису!
Для получения аккаунта, обратитесь к администратору.
Currently, to run the integration tests, it's still necessary to
install various other build tools besides meson: A compiler, gperf,
libcap, ... which we want to avoid in CI systems where we receive
prebuilt systemd packages and only want to test them. Examples are
Debian's autopkgtest CI and Fedora CI. Let's make it possible for
these systems to run the integration tests without having to install
any other build dependency besides meson by extracting the logic
required to run the integration tests with meson into a separate
subdirectory and adding a standalone top-level meson.build file which
can be used to configure a meson tree with as its only purpose running
the integration tests.
Practically, we do the following:
- all the integration test directories and integration-test-wrapper.py
are moved from test/ to test/integration-tests/.
- All the installation logic is kept out of test/integration-tests/ or
any of its subdirectories and moved into test/meson.build instead.
- We add test/integration-tests/standalone/meson.build to run the
integration tests standalone. This meson file includes
test/integration-tests via a cute symlink hack to trick meson into
including a parent directory with subdir().
- Documentation is included on how to use the new standalone mode.
Currently, to run the integration tests, it's still necessary to
install various other build tools besides meson: A compiler, gperf,
libcap, ... which we want to avoid in CI systems where we receive
prebuilt systemd packages and only want to test them. Examples are
Debian's autopkgtest CI and Fedora CI. Let's make it possible for
these systems to run the integration tests without having to install
any other build dependency besides meson by extracting the logic
required to run the integration tests with meson into a separate
subdirectory and adding a standalone top-level meson.build file which
can be used to configure a meson tree with as its only purpose running
the integration tests.
Practically, we do the following:
- all the integration test directories and integration-test-wrapper.py
are moved from test/ to test/integration-test/.
- All the installation logic is kept out of test/integration-test/ or
any of its subdirectories and moved into test/meson.build instead.
- We add test/integration-test/standalone/meson.build to run the
integration tests standalone. This meson file includes
test/integration-test via a cute symlink hack to trick meson into
including a parent directory with subdir().
- Documentation is included on how to use the new standalone mode.
- TEST-64-UDEV-STORAGE and TEST-85-NETWORK are changed to generate separate
units for each testcase to make them behave more like the other integration
tests.
Except for one place, they are only used by test-watch-pid. Let's also
use manager_get_unit_by_pidref() and friends in the test, and drop the
_pid() variants.
It confused the hell of me, that if pid1 crashes in an mkosi system run
from the build tree there's no coredump kept. Because mkosi configures
journal storage for coredumps, but that's not going to work for pid1 or
journald. Hence use external storage for these two even if everything
else is stored in the journal.
We always redirect PID1/journal coredumps directly onto disk instead of
the journal even if that's configured because that might cause a
deadlock because we are still pinning the old journal process while
processing the coredump. However, so far we then immediately deleted the
coredumps because of Storage=journal, which is very annoying, since
there's hence no copy kept whatsoever.
Let's hence exclude PID1+journal from the removal.
This in particulary brings the code in line with the log messages which
claim we kept the file around but we actually did not.
We want to decouple the integration tests in meson from the
rest of the source files so the integration tests can be run
without the source files available. Let's revert the change to
dynamically figure out the test cases from the networkd tests for
now so that the tests can be generated without the test source file
being available.
This reverts commit 514458604b29663bc02c9d0e310f06e0ed682ae9.
Now that mkosi uses -blockdev instead -drive, the device_id property
of scsi-hd devices is not populated automatically anymore so we have to
make sure to always specify serial= to make sure /dev/disk/by-id is populated
as expected in the test.
Commit 536c18e5c3 ("bus-polkit: shortcut auth. after first denial")
added logic to async_polkit_query_check_action() that returns
-EALREADY when a failure or denial decision was made for a previous
action.
Tweak this to return -EBUSY instead of -EALREADY. This hopefully makes
the intent of the error more clear. EALREADY suggests that the request
is OK, but polkit is processing something else, and we should come back
later. EBUSY suggests that polkit is busy or unusable, hence the
request cannot be processed, and we should go away.
The semantics of strong inhibitors require that POLKIT_ALWAYS_QUERY
always be set when checking if we can allow blocking inhibitors to be
ignored on shutdown, reboot, etc. With the default polkit rules and
policy, users may experience a situation where users in the sudo group
are authorized to run:
systemctl reboot --check-inhibitors=no
but the root user is not authorized. Instead, the following error is
given:
Call to Reboot failed: Interactive authentication required.
While this is correct according to the semantics of strong inhibitors,
it is confusing. To help the situation, provide example polkit rules
that allow root to perform these actions.
Finally, when root receives SD_BUS_ERROR_INTERACTIVE_AUTHORIZATION_REQUIRED
when calling e.g. systemctl reboot, print a message explaining that this
is due to the current polkit policy, and point to the new example rule.
Related: https://github.com/systemd/systemd/issues/36786
Commit 536c18e5c3 ("bus-polkit: shortcut auth. after first denial")
added logic to async_polkit_query_check_action() that returns
-EALREADY when a failure or denial decision was made for a previous
action.
This has the consequence that root is able to ignore inhibitors and
shutdown etc. even when polkit explicitly denies it. This is because
when systemctl's verb_start_special() calls logind_reboot(), unless
the call succeeds or returns one of -EACCES, -EOPNOTSUPP, or
-EINPROGRESS, a fallback path is taken to attempt the action without
going through logind. Hence, since logind_reboot() started returning
-EALREADY in some cases, the fallback path was taken, and the shutdown
was performed anyways.
For example:
root@ubuntu:/# cat /etc/polkit-1/rules.d/10-systemd-logind-no-skip-inhibitors.rules
// Never allow strong inhibitors to be ignored.
polkit.addRule(function(action, subject) {
if ((action.id == "org.freedesktop.login1.power-off-ignore-inhibit" ||
action.id == "org.freedesktop.login1.reboot-ignore-inhibit" ||
action.id == "org.freedesktop.login1.halt-ignore-inhibit" ||
action.id == "org.freedesktop.login1.suspend-ignore-inhibit" ||
action.id == "org.freedesktop.login1.hibernate-ignore-inhibit")) {
return polkit.Result.NO;
}
});
root@ubuntu:/# systemctl reboot -i
Call to Reboot failed: Operation already in progress
..but the reboot continues anyways due to the fallback.
To fix this, add logic in systemd-logind's verify_shutdown_creds() to
handle -EALREADY from bus_verify_polkit_async_full(): if we receive
-EALREADY when checking authorization for <action>-multiple-sessions,
and we are blocked on inhibitors, continue on to get the decision for
<action>-ignore-inhibit directly.
While here, add similar logic to method_inhibit(), which may need to
verify multiple polkit actions in a single call.
Fixes 536c18e5c33fd682fcd38d228b46a339adbe150b
We get the same warning thousands of times:
/work/src/tools/check-version-history.py:28: FutureWarning: This search
incorrectly ignores the root element, and will be fixed in a future
version. If you rely on the current behaviour, change it to
"./refsynopsisdiv/funcsynopsis/funcprototype/funcdef/function[.='udev_device_get_properties_list_entry']"
We also need to update the ignorelist to the new form.
We get the same warning thousands of times:
/work/src/tools/check-version-history.py:28: FutureWarning: This search incorrectly
ignores the root element, and will be fixed in a future version. If you rely on the
current behaviour, change it to
"./refsynopsisdiv/funcsynopsis/funcprototype/funcdef/function[.='udev_device_get_properties_list_entry']"
We also need to update the ignorelist to the new form.
* 13d523f84d Relax dependencies from noarch packages on archful packages for OBS builds
* 59378485be Remove purge-nobody-user script
* d1380dc114 Add more services to %post for udev and networkd
* 6f0d03443d Fix paths for /usr/sbin/nologin and related progs
* df9a74d530 Make the source tarball glob in the test script more generic
Integration test units are now connected to the tty when running
interactively, so let's make sure we disable the pager to avoid tests
hanging in the pager.
This introduce `LOG_ITEM()` macro that checks format strings in
log_struct() and friends.
Hopefully, this silences false-positive warnings by Coverity.
If we're using these helpers, we want to split a user record into two,
one with the privileged section, and one without. This should work even
when the user record has a "status" section, so adapt the helpers to
account for that.
As reported in https://github.com/systemd/systemd/issues/35405, if the watchdog
ping failed, we effectively started a busy loop here. The previous commits
should fix this, but in general, the protection here is intended as a safety
net in case the logic is broken somewhere else. We shouldn't exclude the
watchdog stuff from this.
Closes https://github.com/systemd/systemd/issues/35405. Apparently some
watchdog devices can be opened, but then the pings start failing after some
time. Since the timestamp of the last successful ping is not updated, we try to
ping again immediately, causing a busy loop and excessive logging.
After trying a few different approaches to fit this into the existing framework
without changing the logic too much, I settled on an approach with a second
timestamp. In particular, the timestamp of the last successful ping is public,
exposed as WatchdogLastPingTimestamp over dbus. It'd be wrong to redefine this
to mean the last ping *attempt*. So we need a second timestamp in some form.
Also, if we give up on pinging, we probably should attempt to disarm the
watchdog. It's possible that the pinging fails, but the watchdog would still
fire. I don't think we want that, since it seems that our internal loop is
working, it's just the watchdog that is broken.
Structured message with SD_MESSAGE_WATCHDOG_PING_FAILED is logged if we fail
to ping.
I tested this by attaching gdb to pid 1 and calling close(watchdog_fd).
We get a bunch of warning messages and then an attempt to close the watchdog:
Mar 21 15:46:17 fedora systemd[1]: Failed to ping hardware watchdog /dev/watchdog0: Bad file descriptor
Mar 21 15:46:20 fedora systemd[1]: Failed to ping hardware watchdog /dev/watchdog0: Bad file descriptor
Mar 21 15:46:23 fedora systemd[1]: Failed to ping hardware watchdog /dev/watchdog0: Bad file descriptor
Mar 21 15:46:26 fedora systemd[1]: Failed to ping hardware watchdog /dev/watchdog0: Bad file descriptor
Mar 21 15:46:29 fedora systemd[1]: Failed to ping hardware watchdog /dev/watchdog0: Bad file descriptor
Mar 21 15:46:32 fedora systemd[1]: Failed to ping hardware watchdog /dev/watchdog0: Bad file descriptor
Mar 21 15:46:35 fedora systemd[1]: Failed to ping hardware watchdog /dev/watchdog0: Bad file descriptor
Mar 21 15:46:37 fedora systemd[1]: Failed to ping hardware watchdog /dev/watchdog0: Bad file descriptor
Mar 21 15:46:40 fedora systemd[1]: Failed to ping hardware watchdog /dev/watchdog0: Bad file descriptor
Mar 21 15:46:43 fedora systemd[1]: Failed to ping hardware watchdog /dev/watchdog0: Bad file descriptor
Mar 21 15:46:46 fedora systemd[1]: Failed to ping hardware watchdog /dev/watchdog0: Bad file descriptor
Mar 21 15:46:49 fedora systemd[1]: Failed to ping hardware watchdog /dev/watchdog0: Bad file descriptor
Mar 21 15:46:52 fedora systemd[1]: Failed to ping hardware watchdog /dev/watchdog0: Bad file descriptor
Mar 21 15:46:55 fedora systemd[1]: Failed to ping hardware watchdog /dev/watchdog0: Bad file descriptor
Mar 21 15:46:58 fedora systemd[1]: Failed to ping hardware watchdog /dev/watchdog0, closing watchdog after 15 attempts: Bad file descriptor
Mar 21 15:46:58 fedora systemd[1]: Failed to disable hardware watchdog, ignoring: Bad file descriptor
Mar 21 15:46:58 fedora systemd[1]: Failed to disarm watchdog timer, ignoring: Bad file descriptor
