sd-event: change ordering of pending/ratelimited events
Instead of ordering non-pending before pending we should order
"non-pending OR ratelimited" before "pending AND not-ratelimited".
This fixes a bug where ratelimited events were ordered at the end of the
priority queue and could be stuck there for an indeterminate amount of
time.
Anita Zhang [Tue, 8 Jun 2021 07:04:35 +0000 (00:04 -0700)]
test: add extended test for triggering mount rate limit
It's hard to trigger the failure to exit the rate limit state in
isolation as it needs multiple event sources in order to show that it
gets stuck in the queue. Hence why this is an extended test.
Yu Watanabe [Mon, 24 May 2021 05:59:09 +0000 (14:59 +0900)]
network: merge link_configure() and link_configure_continue() again
It is not necessary to stop whole configuration process until MTU and
IPv6LL address generation mode are set. But it is enough just setting
IPv6 MTU again after MTU is set, and dropping IPv6LL address after
setting the address generation mode.
Yu Watanabe [Tue, 18 May 2021 05:59:10 +0000 (14:59 +0900)]
network: make link enter failed state on failure in link_update() and link_reset_carrier()
Previously, several failures in link_carrier_gained() make link enter
failed state, and other errors are ignored. Now, all failures in
link_carrier_gained(), moreover, link_update() are critical.
install: allow adding plain templates to .wants/ or .requires/
Fixes #19437.
As reported in the bug:
> # drkonqi-coredump-processor@.service
> ...
> [Install]
> WantedBy=systemd-coredump@.service
>
> The plan here is to have a systemd-coredump@ instance start the same %i for
> drkonqi-coredump-processor@. Works perfectly when creating the symlink manually
> ln -sv /usr/lib/systemd/system/drkonqi-coredump-processor@.service
> /etc/systemd/system/systemd-coredump@.service.wants/.
When DefaultInstance is set, we replace template references with
template@default-inst. But in this case we want to create a symlink for the
template name, so that systemd will fill in the instance from the
wanting/requiring unit. This is only possible for those units that actually
have an instance set, so we create the symlink only from .requires/ or .wants
of an instantiated unit (then this specific instance will be used), or a
template (than some instance will be inherited later).
→ enable foo@.service creates other@.service.wants/foo@inst.service, and
other@a.service will want foo@inst.service, and other@b.service will want foo@inst.service,
and fixed.service will want foo@inst.service.
Without DefaultInstance,
→ enable foo@.service creates other@.service.wants/foo@.service, and
other@a.service would want foo@a.service, and other@b.service would want foo@b.service,
but enablement fails because no dependency can be created for fixed.service:
Failed to enable unit, unit fixed.service is a non-template unit.
Yu Watanabe [Mon, 7 Jun 2021 12:53:35 +0000 (21:53 +0900)]
network: address: always read address flag from IFA_FLAGS attribute
Otherwise, update flag become incomplete and the IFA_F_MANAGETEMPADDR flag
will not be stored, thus no temporary addresses will be removed when
networkd requests to remove the main address.
Initially I wanted to add ConditionPathExists=!/etc/initrd-release in various
units (ldconfig.service, systemd-sysusers.service, systemd-hwdb-update.service,
systemd-journal-catalog-update, systemd-update-done.service), but I think it's
better to just disable the mechanism in the initrd altogether. Initrd images
are put together in a very particular way, and there is not need to do
post-update steps on them. If a unit from some other package winds up in the
initrd, we wouldn't want to invoke it either.
Also, any modifications are ephemeral, so any update would happen on every
use. And finally, initrd images are all about speed, and we shouldn't invoke
any unneeded services.
core: downgrade errors about BPF loading when called from socket_bind_supported()
prepare_socket_bind_bpf() is called from two sites: socket_bind_supported() and
socket_bind_install_impl(). For the latter, when errors occur we certainly want
to log, since they'll be fatal for the unit. But for the former, we should be
quiet, at least on the "expected" errors like lack of permissions. I kept error
on map resizing and such, which should not fail, at log_warning(). They are not
fatal when called from socket_bind_suppported(), but still a sign that
something is off.
Currently BPF filters can only be used by privileged users. Thus each systemd
--user will fail in socket_bind_supported(). With the patch, we only log this
at debug level.
https://lwn.net/ml/bpf/cover.1620499942.git.yifeifz2@illinois.edu/ gives some
hope that unprivileged access will be possible, so let's keep the code trying.
We might get lucky and get support for filters in user mode without any changes
on our side.
Yu Watanabe [Fri, 4 Jun 2021 05:56:21 +0000 (14:56 +0900)]
sd-device: make cloned sd_device object can read udev database without uevent file
Some devices sent CHANGE and REMOVE uevent simultaneously.
To support that such device read udev database, let's copy minimal set of
properties which requires to read the database.
Yu Watanabe [Fri, 4 Jun 2021 13:16:02 +0000 (22:16 +0900)]
test: add a testcase that demonstrates a conflict of hashed filename
The commit e64943363a8dd8bd320c2b633478be8befd1af5c introduces hashed
path at the end of the filename. But we can easily generate the path
which conflicts another path. The issue will be fixed in later commit.
tmpfiles: do not check if unresolved globs are autofs paths
With the previous commit, we would not complain about the not-found path, but
the check is still not useful. We use a libc function to resolve the glob, and
it has no notion of treating autofs specially. So we can't avoid touching
autofs when resolving globs. But usually the glob is found in the last
component of the path, so if we strip the glob part, we can still do a useful
check in many cases. (E.g. if /var/tmp is on autofs, something like
"/var/tmp/<glob>" is much more likely than "/var/<glob-that-matches-tmp>/<something>".)
With the system config in F34, we check the following prefixes:
tools/analyze-dump-sort: a helper to compare two 'systemd-analyze dump' outputs
Lines in the dumps are ordered by some pseudo-random hashmap entry order, which
makes it hard to diff two outputs. This sort the entries alphabetically, and
also sorts items within the entries, and supresses timestamps and other fields
which always vary.
We could sort the output inside of systemd itself, but it'd make things more
complex, and we probably don't need output to be sorted in most cases. It also
wouldn't be enough, because timestamps and such would still need to be ignored
to do a nice diff. So I think doing the sorting and suppression in a python
helper is a better approach.
projects / thirdparty / systemd.git / log
