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.
581fef8d56 core: stop removing non-existent and duplicate lookup paths
src/core/manager.c | 8 ++----
src/shared/path-lookup.c | 67 ++-------------------------------------------
src/shared/path-lookup.h | 2 +-
src/test/test-path-lookup.c | 6 ++--
4 files changed, 9 insertions(+), 74 deletions(-)