Skip to content
Commit 581fef8d authored by Zbigniew Jędrzejewski-Szmek's avatar Zbigniew Jędrzejewski-Szmek
Browse files

core: stop removing non-existent and duplicate lookup paths

When we would iterate over the lookup paths for each unit, making the list as
short as possible was important for performance. With the current cache, it
doesn't matter much. Two classes of paths were being removed:
- paths which don't exist in the filesystem
- paths which symlink to a path earlier in the search list
Both of those points cause problems with the caching code:
- if a user creates a directory that didn't exist before and puts units there,
  now we will notice the new mtime an properly load the unit. When the path
  was removed from list, we wouldn't.
- we now properly detect whether a unit path is on the path or not.
  Before, if e.g. /lib/systemd/system, /usr/lib/systemd/systemd were both on
  the path, and /lib was a symlink to /usr/lib, the second directory would be
  pruned from the path. Then, the code would think that a symlink
  /etc/systemd/system/foo.service→/lib/systemd/system/foo.service is an alias,
  but /etc/systemd/system/foo.service→/usr/lib/systemd/system/foo.service would
  be considered a link (in the systemctl link sense).

Removing the pruning has a slight negative performance impact in case of
usr-merge systems which have systemd compiled with non-usr-merge paths.
Non-usr-merge systems are deprecated, and this impact should be very small, so
I think it's OK. If it turns out to be an issue, the loop in function that
builds the cache could be improved to skip over "duplicate" directories with
same logic that the cache pruning did before. I didn't want to add this,
becuase it complicates the code to improve a corner case.

Fixes #13272.
parent 6c431a16
Loading
Loading
Loading
Loading
0% Loading or .
You are about to add 0 people to the discussion. Proceed with caution.
Please register or to comment