Bug 68102 - Please consider 'fixing' unit symlinks in /etc (on startup?)
Summary: Please consider 'fixing' unit symlinks in /etc (on startup?)
Status: RESOLVED WONTFIX
Alias: None
Product: systemd
Classification: Unclassified
Component: general (show other bugs)
Version: unspecified
Hardware: Other All
: medium normal
Assignee: systemd-bugs
QA Contact: systemd-bugs
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2013-08-14 11:36 UTC by Michał Górny
Modified: 2018-01-01 17:57 UTC (History)
1 user (show)

See Also:
i915 platform:
i915 features:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Michał Górny 2013-08-14 11:36:03 UTC
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?
Comment 1 Lennart Poettering 2013-09-12 17:22:11 UTC
(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?
Comment 2 Michał Górny 2013-09-12 17:38:57 UTC
(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.
Comment 3 Lennart Poettering 2013-09-12 17:48:10 UTC
(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?
Comment 4 Lennart Poettering 2013-09-12 18:01:58 UTC
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...
Comment 5 Michał Górny 2013-09-12 19:33:27 UTC
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.
Comment 6 Lennart Poettering 2013-09-12 20:06:33 UTC
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..
Comment 7 Michał Górny 2013-09-12 20:10:20 UTC
(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.