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. -- Кирилл Елагин On Wed, Apr 23, 2014 at 8:43 AM, Lennart Poettering <lenn...@poettering.net>wrote: > On Sun, 30.03.14 19:23, Andrey Borzenkov (arvidj...@gmail.com) wrote: > > > linux-qbc6:~ # systemctl show systemd-udevd.service -p FragmentPath > > FragmentPath=/usr/lib/systemd/system/systemd-udevd.service > > linux-qbc6:~ # cp /usr/lib/systemd/system/systemd-udevd.service > /etc/systemd/system > > linux-qbc6:~ # systemctl daemon-reload > > linux-qbc6:~ # cp /usr/lib/systemd/system/systemd-udevd.service > /etc/systemd/system > > linux-qbc6:~ # systemctl show systemd-udevd.service -p FragmentPath > > FragmentPath=/usr/lib/systemd/system/systemd-udevd.service > > linux-qbc6:~ # exit > > > > >From non-exhaustive testing it appears to be the only unit showing this > > property. Enabling systemd debug does not add any useful information > > (no output about unit discovery). Any way to debug it? > > > > The version is systemd-208-19.1.x86_64 from openSUSE. > > Hmm, that's weird. Is /etc on some weird mount point or so? > > It might be interesting to run "strace -o log -e open -p 1" and then > trigger a > reload, and then look at the generate log file "log". It should show you > where systemd is looking for the udev service file, and might contain a > hint, why it skips the file in /etc? > > Lennart > > -- > Lennart Poettering, Red Hat > _______________________________________________ > systemd-devel mailing list > systemd-devel@lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/systemd-devel >
_______________________________________________ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel