On Fri, 31 Oct 2014 16:30:31 +0100 Lennart Poettering <mzerqung@xxxxxxxxxxx> wrote: > On Fri, 31.10.14 16:20, Lennart Poettering (mzerqung@xxxxxxxxxxx) > wrote: > > > On Fri, 31.10.14 16:13, Michal Schmidt (mschmidt@xxxxxxxxxx) wrote: > > > > > On 10/31/2014 03:42 PM, Kevin Fenzi wrote: > > > > On Fri, 31 Oct 2014 14:01:12 +0100 > > > > Lennart Poettering <mzerqung@xxxxxxxxxxx> wrote: > > > > > > > >> So the problem appears to be that gssproxy.service been > > > >> ordered before remote-fs-pre.target. That target is ordered > > > >> before basic.target. However gssproxy.service also is ordered > > > >> after basic.target (simply because all services by default are > > > >> ordered before basic.target, unless they explicitly specify > > > >> DefaultDependencies=no), hence there's an ordering cycle. > > > >> > > > >> Most likely some NFS maintainers tried to move > > > >> gss-proxy.service into the early boot, and didn't set > > > >> DefaultDependencies=no. > > > >> > > > >> That said, services running in early boot must be written in a > > > >> specific style (i.e. not assume /var to be around, and > > > >> suchlike), I do wonder if gssproxy is ready for that. > > > >> > > > >> Anyway, long story short: file a bug against the gssproxy > > > >> package. > > > > > > > > I don't think this explains all the problems folks are having > > > > with systemd-217. > > > > > > I wonder if the new ordering dependency between > > > systemd-journal-flush.service and systemd-tmpfiles-setup.service > > > (added in 74055aa76 "journalctl: add new --flush command and make > > > use of it in systemd-journal-flush.service") participates in the > > > ordering cycles. > > > > Ahh, indeed. It moves remote-fs.target into the early-boot where it > > doesn't belong. > > > > My fault. > > > > Will drop the remote-fs.target dep from the flush service. > > > > Thanks for tracking this down. > > Would be good if somebody who ran into this problem could check if > this change fixes it: > > http://cgit.freedesktop.org/systemd/systemd/commit/units/systemd-journal-flush.service.in?id=919699ec301ea507edce4a619141ed22e789ac0d > > (the actual commit unfortunately contains an unrelated change to > nspawn, I fucked that up, sorry. Ignore everything but the change to > systemd-journal-flush.service) Yep. Seems to fix up the looping here. ;) I still see: Oct 31 09:42:29 voldemort.scrye.com systemd[1]: Cannot add dependency job for unit nfs.target, ignoring: Unit nfs.target failed to load: No such file or directory. Oct 31 09:42:29 voldemort.scrye.com systemd[1]: Cannot add dependency job for unit systemd-readahead-replay.service, ignoring: Unit systemd-readahead-replay.service failed to load: No such file or directory. Oct 31 09:42:29 voldemort.scrye.com systemd[1]: Cannot add dependency job for unit systemd-readahead-collect.service, ignoring: Unit systemd-readahead-collect.service failed to load: No such file or directory. But those seem cosmetic/unrelated. Thanks much for the quick fix! kevin
Attachment:
signature.asc
Description: PGP signature
-- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
