<p dir="ltr">systemd-logind: failed to get session: PID 879 doesnt belong to any known session</p>
<div class="gmail_quote">On Oct 31, 2014 7:31 PM, "Lennart Poettering" <<a href="mailto:mzerqung@0pointer.de">mzerqung@0pointer.de</a>> wrote:<br type="attribution"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On Fri, 31.10.14 16:20, Lennart Poettering (<a href="mailto:mzerqung@0pointer.de">mzerqung@0pointer.de</a>) wrote:<br>
<br>
> On Fri, 31.10.14 16:13, Michal Schmidt (<a href="mailto:mschmidt@redhat.com">mschmidt@redhat.com</a>) wrote:<br>
><br>
> > On 10/31/2014 03:42 PM, Kevin Fenzi wrote:<br>
> > > On Fri, 31 Oct 2014 14:01:12 +0100<br>
> > > Lennart Poettering <<a href="mailto:mzerqung@0pointer.de">mzerqung@0pointer.de</a>> wrote:<br>
> > ><br>
> > >> So the problem appears to be that gssproxy.service been ordered before<br>
> > >> remote-fs-pre.target. That target is ordered before<br>
> > >> basic.target. However gssproxy.service also is ordered after<br>
> > >> basic.target (simply because all services by default are ordered<br>
> > >> before basic.target, unless they explicitly specify<br>
> > >> DefaultDependencies=no), hence there's an ordering cycle.<br>
> > >><br>
> > >> Most likely some NFS maintainers tried to move gss-proxy.service into<br>
> > >> the early boot, and didn't set DefaultDependencies=no.<br>
> > >><br>
> > >> That said, services running in early boot must be written in a<br>
> > >> specific style (i.e. not assume /var to be around, and suchlike), I<br>
> > >> do wonder if gssproxy is ready for that.<br>
> > >><br>
> > >> Anyway, long story short: file a bug against the gssproxy package.<br>
> > ><br>
> > > I don't think this explains all the problems folks are having with<br>
> > > systemd-217.<br>
> ><br>
> > I wonder if the new ordering dependency between<br>
> > systemd-journal-flush.service and systemd-tmpfiles-setup.service<br>
> > (added in 74055aa76 "journalctl: add new --flush command and make use<br>
> > of it in systemd-journal-flush.service") participates in the ordering<br>
> > cycles.<br>
><br>
> Ahh, indeed. It moves remote-fs.target into the early-boot where it<br>
> doesn't belong.<br>
><br>
> My fault.<br>
><br>
> Will drop the remote-fs.target dep from the flush service.<br>
><br>
> Thanks for tracking this down.<br>
<br>
Would be good if somebody who ran into this problem could check if<br>
this change fixes it:<br>
<br>
<a href="http://cgit.freedesktop.org/systemd/systemd/commit/units/systemd-journal-flush.service.in?id=919699ec301ea507edce4a619141ed22e789ac0d" target="_blank">http://cgit.freedesktop.org/systemd/systemd/commit/units/systemd-journal-flush.service.in?id=919699ec301ea507edce4a619141ed22e789ac0d</a><br>
<br>
(the actual commit unfortunately contains an unrelated change to<br>
nspawn, I fucked that up, sorry. Ignore everything but the change to<br>
systemd-journal-flush.service)<br>
<br>
Thanks,<br>
<br>
Lennart<br>
<br>
--<br>
Lennart Poettering, Red Hat<br>
--<br>
devel mailing list<br>
<a href="mailto:devel@lists.fedoraproject.org">devel@lists.fedoraproject.org</a><br>
<a href="https://admin.fedoraproject.org/mailman/listinfo/devel" target="_blank">https://admin.fedoraproject.org/mailman/listinfo/devel</a><br>
Fedora Code of Conduct: <a href="http://fedoraproject.org/code-of-conduct" target="_blank">http://fedoraproject.org/code-of-conduct</a></blockquote></div>