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

[Lennart Poettering]

On Fri, 31.10.14 07:57, Matthew Miller (mattdm at fedoraproject.org) wrote:

> On Fri, Oct 31, 2014 at 07:39:42AM -0400, Matthew Miller wrote:
> > On Fri, Oct 31, 2014 at 12:33:20PM +0100, Michal Schmidt wrote:
> > > > Oct 30 21:39:47 ubik.home.mkmiller.org systemd[1]: Found ordering cycle on basic.target/start
> > > > Oct 30 21:39:47 ubik.home.mkmiller.org systemd[1]: Breaking ordering cycle by deleting job sysinit.target/start
> > > are you showing only messages at loglevel "warning" and higher?
> > > Because in between these two lines I'd expect to see some
> > > "Found dependency on <service>/<job_type>" at loglevel "info".
> > That's everything with _COMM=systemd since boot. Possibly loglevel
> > itself is set low? I'll enable more debugging and post that.
> 
> Oct 31 07:42:29 ubik systemd[1]: Found ordering cycle on basic.target/start
> Oct 31 07:42:29 ubik systemd[1]: Found dependency on sysinit.target/start
> Oct 31 07:42:29 ubik systemd[1]: Found dependency on systemd-update-utmp.service/verify-active
> Oct 31 07:42:29 ubik systemd[1]: Found dependency on systemd-tmpfiles-setup.service/start
> Oct 31 07:42:29 ubik systemd[1]: Found dependency on systemd-journal-flush.service/start
> Oct 31 07:42:29 ubik systemd[1]: Found dependency on remote-fs.target/start
> Oct 31 07:42:29 ubik systemd[1]: Found dependency on remote-fs-pre.target/start
> Oct 31 07:42:29 ubik systemd[1]: Found dependency on nfs-client.target/start
> Oct 31 07:42:29 ubik systemd[1]: Found dependency on gssproxy.service/start
> Oct 31 07:42:29 ubik systemd[1]: Found dependency on basic.target/start

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.

Lennart

-- 
Lennart Poettering, Red Hat