[systemd-devel] Unable to override systemd-udevd.service

[Lennart Poettering]

On Wed, 23.04.14 10:15, Kirill Elagin (kirelagin at gmail.com) wrote:

Sorry for taking so long to reply to this mail.

This is actually a well-known bug, that I should be working on, but
never do, because it is not trivial. Long story short: the way we look
for unit files is a bit borked. The algorithm needs quite a revamp:
currently the logic only follows one chain of symlinks and that's
it. What we probably have to do, is follow the chain, but for each new
name we find also do the full discovery again, if you follow what i
mean. Only then we can make sure we always collect all redirections (and
all maskings). 

So yupp, I have no good answer for you now, it's a long standig bug. We
should fix it. Not totally trivial though...

> While playing with this I've also noticed that systemd treats symlinks in a
> bit
> weird way: looks like if it sees a symlink it dereferences it, but not all
> the symlinks
> in the path. Here is an example:
> 
> # systemctl show systemd-udevd.service -p FragmentPath
> FragmentPath=/usr/lib64/systemd/system/systemd-udevd.service
> # ln -s /usr/lib/systemd/system/systemd-udevd.service /etc/systemd/system
> # systemctl daemon-reload
> # systemctl show systemd-udevd.service -p FragmentPath
> FragmentPath=/usr/lib/systemd/system/systemd-udevd.service
> # readlink -f /etc/systemd/system/systemd-udevd.service
> /usr/lib64/systemd/system/systemd-udevd.service
> 
> I feel that I'm interested in the _reason_ why this unit is loaded, that
> is, I guess,
> I'd like to see `/etc/systemd/system/system-udevd.service` in this case, as
> it
> _explains why_ systemd loaded this unit.
> But what I see is `/usr/lib/systemd/system/systemd-udevd.service` which is
> totally unhelpful as it is neither the path that systemd used to discover
> the unit,
> nor the actual path to the unit file (which is `/usr/lib64/…`).
> (Here, on Gentoo, `/usr/lib` is a symlink to `/usr/lib64`.)
> 
> Probably, somehow using this and the fact that if `cp`'s target is a
> symlink,
> then the symlink's target will be overwritten with the symlink left where
> it was,
> it is possible to reproduce the issue.
> 
> 


Lennart

-- 
Lennart Poettering, Red Hat