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!
Только зарегистрированные пользователи имеют доступ к сервису!
Для получения аккаунта, обратитесь к администратору.
It's not entirely impossible to screw something up playing with
kernel modules on a Saturday evening :-) This PR fixes a scenario
where a module has been loaded into the kernel but the module itself
has been removed from the disk.
```
$ lsmod | grep wireg
wireguard 225280 0
ip6_udp_tunnel 16384 1 wireguard
udp_tunnel 16384 1 wireguard
$ modprobe wireguard
modprobe: FATAL: Module wireguard not found in directory /lib/modules/4.18.16-200.fc28.x86_64
$ sudo ./systemd-networkd-tests.py NetworkdNetDevTests.test_wireguard
...
modprobe: FATAL: Module wireguard not found in directory /lib/modules/4.18.16-200.fc28.x86_64
test_wireguard (__main__.NetworkdNetDevTests) ... unexpected success
----------------------------------------------------------------------
Ran 1 test in 5.152s
FAILED (unexpected successes=1)
```
This is a follow-up to https://github.com/systemd/systemd/pull/10625.
A simple copy+paste mistake, since the reference to
systemd-localed.service was added to both locale.conf(5) and
vconsole.conf(5) in the same commit (8968e36f21).
After ec6a47044a, networkd starts
soon after removing links used by previous test. That causes
some racy situation of removing links and detecting links by networkd.
A race condition happens when calling ask_password_auto() multiple times
to unlock several disks on boot and effectively no password caching is
utilized. This patch fixes it by polling the cache when waiting for
the password.
This splits the "environment" field of Manager into two:
transient_environment and client_environment. The former is generated
from configuration file, kernel cmdline, environment generators. The
latter is the one the user can control with "systemctl set-environment"
and similar.
Both sets are merged transparently whenever needed. Separating the two
sets has the benefit that we can safely flush out the former while
keeping the latter during daemon reload cycles, so that env var settings
from env generators or configuration files do not accumulate, but
dynamic API changes are kept around.
Note that this change is not entirely transparent to users: if the user
first uses "set-environment" to override a transient variable, and then
uses "unset-environment" to unset it again things will revert to the
original transient variable now, while previously the variable was fully
removed. This change in behaviour should not matter too much though I
figure.
Fixes: #9972
