forked from systemd/systemd
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
core/device: always accept syspath change
When multiple devices have the same devlink, then adding/updating/removing one of the device may cause syspath change. Fixes the following issue in systemd#23208 (comment) > the above shows an inconsistency between udev's and systemd's handling > of the two different devices having the same alias. While udev replaces > the by-uuid symlink which now points to sdh1 rather than sdd1, systemd > keeps the previous mapping to sdd1 and emits a warning. This is not the > problem cause but worth mentioning.
- Loading branch information
Showing
2 changed files
with
97 additions
and
37 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
c7fd2d5
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for looking into this! Note that my comment in systemd#23208 was a bit misleading perhaps. In the case I quoted, udev had indeed taken over the symlink. But that's not necessarily the case if you look at the udev code. A worker may or may not take over the symlink. In particular, systemd has no concept of udev's link priority.
IMO the only safe way for systemd to derive the current state of symlinks is to read the symlink from the filesystem, at least after each ADD/CHANGE/REMOVE uevent.