possibly problem with rawhide (systemd-217?): "Found ordering cycle on basic.target/start"

[Kevin Fenzi]

On Fri, 31 Oct 2014 16:30:31 +0100
Lennart Poettering <mzerqung at 0pointer.de> wrote:

> On Fri, 31.10.14 16:20, Lennart Poettering (mzerqung at 0pointer.de)
> wrote:
> 
> > On Fri, 31.10.14 16:13, Michal Schmidt (mschmidt at redhat.com) wrote:
> > 
> > > On 10/31/2014 03:42 PM, Kevin Fenzi wrote:
> > > > On Fri, 31 Oct 2014 14:01:12 +0100
> > > > Lennart Poettering <mzerqung at 0pointer.de> 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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://lists.fedoraproject.org/pipermail/devel/attachments/20141031/58f48ef7/attachment.sig>