On Tue, May 26, 2015 at 9:04 PM, Christian Hesse <l...@eworm.de> wrote: > Martin Pitt <martin.p...@ubuntu.com> on Tue, 2015/05/26 17:11: >> Hello Tom, all, >> >> with 220 I get a severe boot time regression: >> >> $ systemd-analyze >> Startup finished in 30.751s (kernel) + 11.706s (userspace) = 42.458s >> >> which used to be >> >> $ systemd-analyze >> Startup finished in 703ms (kernel) + 890ms (userspace) = 1.593s >> >> (this is a VM) >> >> It seems udevd --daemon spends 30 seconds timing out in the initramfs: >> >> [ 0.384519] systemd-udevd: starting version 220 >> [ 30.736381] systemd-udevd: timeout, giving up waiting for workers >> to finish >> >> and then some more in the real root: >> >> $ systemd-analyze blame >> 10.826s dev-vda1.device >> 10.067s systemd-tmpfiles-setup-dev.service >> 10.031s systemd-sysctl.service >> 10.019s systemd-journald.service >> 10.005s sys-fs-fuse-connections.mount >> 10.001s tmp.mount >> >> (full journal at http://paste.ubuntu.com/11372265/, but it's not very >> useful) >> >> I bisected this to >> >> http://cgit.freedesktop.org/systemd/systemd/commit/?id=e237d8c >> udevd: move file descriptors to Manager >> >> this is hard to revert individually as there are lots of other recent >> changes in udev around this commit, but any version before that commit is >> fast and doesn't give that timeout error. >> >> Current trunk as of commit 185abfc3 still has that problem, so it >> wasn't fixed by one of the recent udev commits. >> >> Does anyone else see this too? Any idea what causes this? > > I do see this as well. And probably we have an upstream bug  already. > > Wondering whether or not my report about "inotify_add_watch() failed: Bad > file descriptor"  is related. Do you see that as well? > BTW, is it expected to have fd_inotify in udevd.c and inotify_fd in > udev_watch.c?
This is unrelated. Cheers, Tom _______________________________________________ systemd-devel mailing list firstname.lastname@example.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel