My /etc/systemd/system/multi-user.target.wants/ has a number of symlinks like: dhcpcd.service -> /usr/lib64/systemd/system/dhcpcd.service How I got these is another story that needs investigating. But now I have a symlinks that are invalid per filesystem rules and completely valid per systemd rules. If I run some kind of stale symlink search, it would catch those and likely want to remove them. Could you consider doing some kind of 'symlink update' run within systemd? That is, while doing the usual readlink() magic and unit search, compare whether the canonical unit path matches the symlink target and rewrite the symlink if it doesn't?
(In reply to comment #0) > My /etc/systemd/system/multi-user.target.wants/ has a number of symlinks > like: > > dhcpcd.service -> /usr/lib64/systemd/system/dhcpcd.service This is not arch dependent, it shouldn't be in lib64/, but in lib/. > How I got these is another story that needs investigating. But now I have a > symlinks that are invalid per filesystem rules and completely valid per > systemd rules. If I run some kind of stale symlink search, it would catch > those and likely want to remove them. > > Could you consider doing some kind of 'symlink update' run within systemd? > That is, while doing the usual readlink() magic and unit search, compare > whether the canonical unit path matches the symlink target and rewrite the > symlink if it doesn't? I don't follow? Come again? It should rewrite lib/ to lib64/? That sounds very specialist to me and sounds like something that is better fixed with a manual script. Or what are you asking for? I don't get it?
(In reply to comment #1) > (In reply to comment #0) > > My /etc/systemd/system/multi-user.target.wants/ has a number of symlinks > > like: > > > > dhcpcd.service -> /usr/lib64/systemd/system/dhcpcd.service > > This is not arch dependent, it shouldn't be in lib64/, but in lib/. And it is in lib/. The symlink is wrong but let's not get into how I got that. > > Could you consider doing some kind of 'symlink update' run within systemd? > > That is, while doing the usual readlink() magic and unit search, compare > > whether the canonical unit path matches the symlink target and rewrite the > > symlink if it doesn't? > > I don't follow? Come again? It should rewrite lib/ to lib64/? That sounds > very specialist to me and sounds like something that is better fixed with a > manual script. > > Or what are you asking for? I don't get it? I mean that systemd currently does readlink() and uses basename of symlink to find the unit. I would like it to additionally compare the result of this search with current symlink target, and reset symlink to point to the found unit. In other words, I have this: dhcpcd.service -> /usr/lib64/systemd/system/dhcpcd.service but after systemd interprets it, it is rewritten as: dhcpcd.service -> /usr/lib/systemd/system/dhcpcd.service or: dhcpcd.service -> /lib/systemd/system/dhcpcd.service or even: dhcpcd.service -> /etc/systemd/system/dhcpcd.service depending on where systemd actually found the unit.
(In reply to comment #2) > > I don't follow? Come again? It should rewrite lib/ to lib64/? That sounds > > very specialist to me and sounds like something that is better fixed with a > > manual script. > > > > Or what are you asking for? I don't get it? > > I mean that systemd currently does readlink() and uses basename of symlink > to find the unit. I would like it to additionally compare the result of this > search with current symlink target, and reset symlink to point to the found > unit. > > In other words, I have this: > > dhcpcd.service -> /usr/lib64/systemd/system/dhcpcd.service > > but after systemd interprets it, it is rewritten as: > > dhcpcd.service -> /usr/lib/systemd/system/dhcpcd.service > > or: > > dhcpcd.service -> /lib/systemd/system/dhcpcd.service > > or even: > > dhcpcd.service -> /etc/systemd/system/dhcpcd.service > > depending on where systemd actually found the unit. I still don't get it? What should it do and why?
OK, so I think I get it now. You want a tool that iterates through /etc/systemd/system, find all symlinks in there, and if they point to other symlinks then they ayre updated to point to the ultimate destination of that symlink chain? I am not convinced that really belongs into systemd, as none of systemd's tools would create these symlink chains. I can see however, that it would be a good idea to have such a tool somewhere, but I am tempted to say that a generic tool like symlinks(8) (as included in many distributions, and installed on Fedora at least by default) might be a better place for this...
Let's try again. Let's say i do something like: ln -s /foo/bar/foo.service /etc/systemd/system/multi-user.target.wants/ Assuming thar /foo/bar never existed, foo.service will still be used since systemd uses the basename only. However, if we run some kind of dead symlink removal script, it would consider the symlink broken. The idea is that systemd would automatically 'fix' the symlink to point to the unit file, so that dead symlink tools wouldn't consider it broken.
Quit frankly, we should probably not read over dangling symlinks if that's what happens right now, but generate an error. (added to the TODO list) Note that systemd actually does care about the destination of the symlink, but it puts it at the end of the search logic, so that the normal search paths always override the symlink destination but the symlink destination is used when the unit is not found in the search path..
(In reply to comment #6) > Quit frankly, we should probably not read over dangling symlinks if that's > what happens right now, but generate an error. (added to the TODO list) That's fine for me as well, since it solves the main issue.
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.