В Thu, 24 Apr 2014 12:07:37 +0200 David Gstir <da...@sigma-star.at> пишет:
> [Resend to mailing list, because my client somehow swallowed half the Cc > fields - sorry about that.] > > Hi! > > I encountered the same issue, running version 195-13.45.1 from opensuse in a > container: > > On 23.04.2014, at 19:26, Andrey Borzenkov (by way of Andrey Borzenkov > <arvidj...@gmail.com>) <arvidj...@gmail.com> wrote: > > > В Wed, 23 Apr 2014 06:43:04 +0200 > > Lennart Poettering <lenn...@poettering.net> пишет: > > > >> 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? > >> > > > > Not really. Just plain disk in QEMU VM. > > > > 17 21 0:5 / /dev rw,relatime shared:2 - devtmpfs devtmpfs > > rw,size=380164k,nr_inodes=95041,mode=755 > > 18 17 0:15 / /dev/shm rw,relatime shared:3 - tmpfs tmpfs rw > > 19 21 0:16 / /run rw,nosuid,nodev,relatime shared:6 - tmpfs tmpfs > > rw,mode=755 > > 20 17 0:11 / /dev/pts rw,relatime shared:4 - devpts devpts > > rw,gid=5,mode=620,ptmxmode=000 > > 21 1 8:2 / / rw,relatime shared:1 - ext4 /dev/sda2 rw,data=ordered > > ... etc > > > > Similar situation here. > > > >> 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? > >> > > > > Actually, it does not :) > > > > 1 open("/usr/lib/systemd/system/systemd-udevd.service", > > O_RDONLY|O_NOCTTY|O_LARGEFILE|O_NOFOLLOW|O_CLOEXEC) = 17 > > 1 open("/usr/lib/systemd/system/systemd-udevd-kernel.socket", > > O_RDONLY|O_NOCTTY|O_LARGEFILE|O_NOFOLLOW|O_CLOEXEC) = 17 > > 1 open("/usr/lib/systemd/system/systemd-udevd-control.socket", > > O_RDONLY|O_NOCTTY|O_LARGEFILE|O_NOFOLLOW|O_CLOEXEC) = 17 > > 1 open("/etc/systemd/system/systemd-udevd.service", > > O_RDONLY|O_NOCTTY|O_LARGEFILE|O_CLOEXEC) = 18 > > 1 openat(AT_FDCWD, "/etc/systemd/system/systemd-udevd.service.d", > > O_RDONLY|O_NONBLOCK|O_LARGEFILE|O_DIRECTORY|O_CLOEXEC) = -1 ENOENT (No such > > file or directory) > > 1 openat(AT_FDCWD, "/run/systemd/system/systemd-udevd.service.d", > > O_RDONLY|O_NONBLOCK|O_LARGEFILE|O_DIRECTORY|O_CLOEXEC) = -1 ENOENT (No such > > file or directory) > > 1 openat(AT_FDCWD, "/run/systemd/generator/systemd-udevd.service.d", > > O_RDONLY|O_NONBLOCK|O_LARGEFILE|O_DIRECTORY|O_CLOEXEC) = -1 ENOENT (No such > > file or directory) > > 1 openat(AT_FDCWD, > > "/usr/local/lib/systemd/system/systemd-udevd.service.d", > > O_RDONLY|O_NONBLOCK|O_LARGEFILE|O_DIRECTORY|O_CLOEXEC) = -1 ENOENT (No such > > file or directory) > > 1 openat(AT_FDCWD, "/usr/lib/systemd/system/systemd-udevd.service.d", > > O_RDONLY|O_NONBLOCK|O_LARGEFILE|O_DIRECTORY|O_CLOEXEC) = -1 ENOENT (No such > > file or directory) > > 1 openat(AT_FDCWD, "/lib/systemd/system/systemd-udevd.service.d", > > O_RDONLY|O_NONBLOCK|O_LARGEFILE|O_DIRECTORY|O_CLOEXEC) = -1 ENOENT (No such > > file or directory) > > > > Systemd does not even try to open the override in /etc here either. However, > I noticed an error with /usr/lib/systemd/system/udev.service: > <snip> > open("/usr/lib/systemd/system/udev.service", > O_RDONLY|O_NOCTTY|O_NOFOLLOW|O_CLOEXEC) = -1 ELOOP (Too many levels of > symbolic links) > open("/usr/lib/systemd/system/systemd-udevd.service", > O_RDONLY|O_NOCTTY|O_NOFOLLOW|O_CLOEXEC) = 15 > <snip> > > Interestingly, removing /usr/lib/systemd/system/udev.service (which is just a > symlink to systemd-udevd.service) makes the override work: > <snip> > open("/etc/systemd/system/systemd-udevd.service", > O_RDONLY|O_NOCTTY|O_NOFOLLOW|O_CLOEXEC) = 15 > <snip> > > Could it be that this symlink somehow causes systemd to ignore the override? > Andrey, do you have similar behavior with > /usr/lib/systemd/system/udev.service? > Yes, I have the same link and the same ELOOP behavior ... and yes, removing link makes it work. Looks like systemd bug at the end ... _______________________________________________ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel