The nvme by-id symlink changes to the latest namespace when a new namespace gets
added, for example by connecting multiple NVMe/TCP host controllers via nvme
connect-all.
That is incorrect for persistent device links.
The persistent symbolic device link should continue to point to the same NVMe
namespace throughout the lifetime of the current boot.
Therefore the namespace id needs to be added to the link name.
Fix check for conflicting and duplicate expressions of types that
support alternative patterns.
Fixes: 3ec58d0cd8 ("udev-rules: check for conflicting and duplicate expressions")
For those token types that support matching of alternative patterns,
their token values are interpreted as nulstr, so make sure the parser
does the right thing and makes these token values terminated by two
subsequent NULs so they could be safely interpreted as nulstr.
Before this fix, the following rules would result to "echo foo" invocation:
ENV{foo}=", RUN"
ENV{foo}=="bar", RUN+="echo foo"
because the value of `ENV{foo}` is treated as nulstr, and it used to match
against alternative patterns, in this case `bar`, `, RUN`, and `="echo foo`.
Fixes: 25de7aa7b9 ("udev: modernize udev-rules.c")
For some unknown reasons, the temporary directory created by the test
below is not removed:
```
# Test the case that a valid symlink is in the path.
label = 'valid_symlink-deep'
test_content('f= {} - - - - ' + label, label, user=user, subpath='/deep/1/2', path_cb=valid_symlink)
```
To keep /tmp clean, let's create the global temprary directory.
The user manager connects to oomd over varlink. Currently, during
shutdown, if oomd is stopped before any user manager, the user
manager will try to reconnect to the socket, leading to a warning
from pid 1 about a conflicting transaction.
Let's fix this by ordering user@.service after systemd-oomd.service,
so that user sessions are stopped before systemd-oomd is stopped,
which makes sure that the user sessions won't try to start oomd via
its socket after systemd-oomd is stopped.
Follow-up for 924775e8ce.
The loop run with `STRV_FOREACH_PAIR()`, hence `if (*(unit_id+1))` is
not a good way to detect if there exist a next entry.
Fixes#26872.
If we have multiple entries in $ENTRY_TOKEN_SEARCH, and $pref/loader/entries
exists, then previously we would always exit after the first candidate and
ignore the second and later candidates.
Follow-up for 1b43f86893.
This reverts commit 41f39e2144.
From the post merge comment in #26648:
> Hmm, this is highly problematic, no? if I boot from my ssd and then
> plug in a fedora live usb stick, then there will be two ESPs around,
> the one from my ssd and the one from the live usb one, and this code
> might find the wrong one and bad things will happen