Re: possibly problem with rawhide (systemd-217?): Found ordering cycle on basic.target/start
On 10/31/2014 02:47 AM, Matthew Miller 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 Matthew, 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. Regards, Michal -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: possibly problem with rawhide (systemd-217?): Found ordering cycle on basic.target/start
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. -- Matthew Miller mat...@fedoraproject.org Fedora Project Leader -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: possibly problem with rawhide (systemd-217?): Found ordering cycle on basic.target/start
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 Oct 31 07:42:29 ubik systemd[1]: Breaking ordering cycle by deleting job systemd-update-utmp.service/verify-active Oct 31 07:42:29 ubik systemd[1]: Job systemd-update-utmp.service/verify-active deleted to break ordering cycle starting with basic.target/start Oct 31 07:42:29 ubik systemd[1]: Deleting job systemd-update-utmp-runlevel.service/start as dependency of job systemd-update-utmp.service/verify-active 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 auditd.service/start 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 Oct 31 07:42:29 ubik systemd[1]: Breaking ordering cycle by deleting job auditd.service/start Oct 31 07:42:29 ubik systemd[1]: Job auditd.service/start deleted to break ordering cycle starting with basic.target/start 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-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 Oct 31 07:42:29 ubik systemd[1]: Breaking ordering cycle by deleting job systemd-tmpfiles-setup.service/start Oct 31 07:42:29 ubik systemd[1]: Job systemd-tmpfiles-setup.service/start deleted to break ordering cycle starting with basic.target/start Oct 31 07:42:29 ubik systemd[1]: Looking at job sshd-keygen.service/stop conflicted_by=no Oct 31 07:42:29 ubik systemd[1]: Looking at job sshd-keygen.service/start conflicted_by=no Oct 31 07:42:29 ubik systemd[1]: Fixing conflicting jobs sshd-keygen.service/stop,sshd-keygen.service/start by deleting job sshd-keygen.service/stop Oct 31 07:42:29 ubik systemd[1]: Looking at job plymouth-quit.service/stop conflicted_by=yes Oct 31 07:42:29 ubik systemd[1]: Looking at job plymouth-quit.service/start conflicted_by=no Oct 31 07:42:29 ubik systemd[1]: Fixing conflicting jobs plymouth-quit.service/stop,plymouth-quit.service/start by deleting job plymouth-quit.service/start Oct 31 07:42:29 ubik systemd[1]: Looking at job gdm.service/start conflicted_by=no Oct 31 07:42:29 ubik systemd[1]: Looking at job gdm.service/stop conflicted_by=no Oct 31 07:42:29 ubik systemd[1]: Fixing conflicting jobs gdm.service/start,gdm.service/stop by deleting job gdm.service/stop Oct 31 07:42:29 ubik systemd[1]: Looking at job getty@tty1.service/stop conflicted_by=yes Oct 31 07:42:29 ubik systemd[1]: Looking at job getty@tty1.service/start
Re: possibly problem with rawhide (systemd-217?): Found ordering cycle on basic.target/start
By the way, sudo systemctl start systemd-tmpfiles-setup sudo rm /var/run/nologin sudo systemctl restart gdm got me to a functioning GNOME desktop. -- Matthew Miller mat...@fedoraproject.org Fedora Project Leader -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: possibly problem with rawhide (systemd-217?): Found ordering cycle on basic.target/start
On 10/31/2014 12:57 PM, Matthew Miller wrote: 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 Oct 31 07:42:29 ubik systemd[1]: Breaking ordering cycle by deleting job systemd-update-utmp.service/verify-active This ordering cycle was introduced recently by changes in nfs-utils's unit files when nfs-client.target got an After dependency on gssproxy. nfs-client.target wants to be started before any remote filesystems are mounted (which is before basic.target). gssproxy.service has default dependencies, so it wants to start quite late during boot (after basic.target). [CC Steve.] Regards, Michal -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: possibly problem with rawhide (systemd-217?): Found ordering cycle on basic.target/start
On Fri, 31.10.14 07:57, Matthew Miller (mat...@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 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: possibly problem with rawhide (systemd-217?): Found ordering cycle on basic.target/start
On Fri, Oct 31, 2014 at 01:44:27PM +0100, Michal Schmidt wrote: This ordering cycle was introduced recently by changes in nfs-utils's unit files when nfs-client.target got an After dependency on gssproxy. Are you sure? Looks like I last updated nfs-utils on Oct 26th, and I've rebooted several times since then without incident — it's only after this last update that the problem occured. I mean, I believe you that this is a problem, but did something else change too? -- Matthew Miller mat...@fedoraproject.org Fedora Project Leader -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: possibly problem with rawhide (systemd-217?): Found ordering cycle on basic.target/start
On 10/31/2014 02:03 PM, Matthew Miller wrote: On Fri, Oct 31, 2014 at 01:44:27PM +0100, Michal Schmidt wrote: This ordering cycle was introduced recently by changes in nfs-utils's unit files when nfs-client.target got an After dependency on gssproxy. Are you sure? Looks like I last updated nfs-utils on Oct 26th, and I've rebooted several times since then without incident — it's only after this last update that the problem occured. I mean, I believe you that this is a problem, but did something else change too? Maybe you already had an ordering cycle on Oct 26, but different units were chosen for deletion when breaking the cycle, and by luck it had fewer directly observable consequences. Could you check older logs for ordering cycles? Michal -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: possibly problem with rawhide (systemd-217?): Found ordering cycle on basic.target/start
On Fri, Oct 31, 2014 at 02:15:45PM +0100, Michal Schmidt wrote: Maybe you already had an ordering cycle on Oct 26, but different units were chosen for deletion when breaking the cycle, and by luck it had fewer directly observable consequences. Could you check older logs for ordering cycles? Yeah, I was just doing that, and there's no ordering cycle logged before late last night (e.g. the ill-fated reboot). That said, as you expected, disabling nfs-client.target does make the system boot successfully. I'm still getting a problem with dev-mqueue.mount, though: Oct 31 09:19:46 ubik systemd[1]: dev-mqueue.mount: Directory /dev/mqueue to mount over is not empty, mounting anyway. Oct 31 09:19:46 ubik mount[4484]: mount: mount point /dev/mqueue does not exist Oct 31 09:19:46 ubik systemd[1]: dev-mqueue.mount mount process exited, code=exited status=32 Oct 31 09:19:46 ubik systemd[1]: Failed to mount POSIX Message Queue File System. On a related but different note — is there a way to detect potential ordering cycles from a set of RPMs on disk (possibly installed in a chroot or something) _without_ actually booting? Maybe we could add a taskotron check for that for packages with changes to systemd unit files. (I realize that what is enabled on people's systems will have an impact, but we could check against a set of defaults at least.) -- Matthew Miller mat...@fedoraproject.org Fedora Project Leader -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: possibly problem with rawhide (systemd-217?): Found ordering cycle on basic.target/start
On 10/31/2014 02:30 PM, Matthew Miller wrote: Oct 31 09:19:46 ubik systemd[1]: dev-mqueue.mount: Directory /dev/mqueue to mount over is not empty, mounting anyway. Oct 31 09:19:46 ubik mount[4484]: mount: mount point /dev/mqueue does not exist Oct 31 09:19:46 ubik systemd[1]: dev-mqueue.mount mount process exited, code=exited status=32 Oct 31 09:19:46 ubik systemd[1]: Failed to mount POSIX Message Queue File System. I saw this too, but didn't look into it. On a related but different note — is there a way to detect potential ordering cycles from a set of RPMs on disk (possibly installed in a chroot or something) _without_ actually booting? Maybe we could add a taskotron check for that for packages with changes to systemd unit files. (I realize that what is enabled on people's systems will have an impact, but we could check against a set of defaults at least.) It's not the perfect solution, but this command would report the cycle you saw: /usr/lib/systemd/systemd --test --system Michal -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: possibly problem with rawhide (systemd-217?): Found ordering cycle on basic.target/start
I see many this messages. But Matthew solution haven't fixed my problem. -Igor Gnatenko On Oct 31, 2014 4:42 PM, Michal Schmidt mschm...@redhat.com wrote: On 10/31/2014 02:30 PM, Matthew Miller wrote: Oct 31 09:19:46 ubik systemd[1]: dev-mqueue.mount: Directory /dev/mqueue to mount over is not empty, mounting anyway. Oct 31 09:19:46 ubik mount[4484]: mount: mount point /dev/mqueue does not exist Oct 31 09:19:46 ubik systemd[1]: dev-mqueue.mount mount process exited, code=exited status=32 Oct 31 09:19:46 ubik systemd[1]: Failed to mount POSIX Message Queue File System. I saw this too, but didn't look into it. On a related but different note — is there a way to detect potential ordering cycles from a set of RPMs on disk (possibly installed in a chroot or something) _without_ actually booting? Maybe we could add a taskotron check for that for packages with changes to systemd unit files. (I realize that what is enabled on people's systems will have an impact, but we could check against a set of defaults at least.) It's not the perfect solution, but this command would report the cycle you saw: /usr/lib/systemd/systemd --test --system Michal -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: possibly problem with rawhide (systemd-217?): Found ordering cycle on basic.target/start
On Thu, Oct 30, 2014 at 21:47:36 -0400, Matthew Miller mat...@fedoraproject.org wrote: Updated my rawhide system. Now it doesn't boot cleanly. Will try to figure out the details in the morning (long week!), but Found ordering cycle on basic.target/start seems to be part of it, and I wanted to see if anyone else is hitting this (and possibly caution care on upgrading right now). Note Breaking ordering cycle by deleting job sysinit.target/start. The system partially comes up, but there is a _lot_ of failure-to-work afterwards - probably related. I have a similar but not identical issue on some of my systems. It has been a problem for a couple of weeks that I have been avoiding by using older initramfs for. I haven't wanted to spend the time to figure out exactly what is triggering the problem. (It doesn't happen on all of my machines.) -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: possibly problem with rawhide (systemd-217?): Found ordering cycle on basic.target/start
On Fri, 31 Oct 2014 14:01:12 +0100 Lennart Poettering mzerq...@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 have gssproxy disabled here and still see loops and issues. I did not with 216. gssproxy itself hasn't been updated in a long time. Happy to provide info from my install here, what info would be good to get from everyone? Perhaps in bug would be a better place to collect it: https://bugzilla.redhat.com/show_bug.cgi?id=1159117 kevin signature.asc Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: possibly problem with rawhide (systemd-217?): Found ordering cycle on basic.target/start
On 10/31/2014 03:42 PM, Kevin Fenzi wrote: On Fri, 31 Oct 2014 14:01:12 +0100 Lennart Poettering mzerq...@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. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: possibly problem with rawhide (systemd-217?): Found ordering cycle on basic.target/start
On Fri, 31.10.14 16:13, Michal Schmidt (mschm...@redhat.com) wrote: On 10/31/2014 03:42 PM, Kevin Fenzi wrote: On Fri, 31 Oct 2014 14:01:12 +0100 Lennart Poettering mzerq...@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. Lennart -- Lennart Poettering, Red Hat -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: possibly problem with rawhide (systemd-217?): Found ordering cycle on basic.target/start
On Fri, 31.10.14 16:20, Lennart Poettering (mzerq...@0pointer.de) wrote: On Fri, 31.10.14 16:13, Michal Schmidt (mschm...@redhat.com) wrote: On 10/31/2014 03:42 PM, Kevin Fenzi wrote: On Fri, 31 Oct 2014 14:01:12 +0100 Lennart Poettering mzerq...@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) Thanks, Lennart -- Lennart Poettering, Red Hat -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: possibly problem with rawhide (systemd-217?): Found ordering cycle on basic.target/start
On Fri, 31 Oct 2014 16:30:31 +0100 Lennart Poettering mzerq...@0pointer.de wrote: On Fri, 31.10.14 16:20, Lennart Poettering (mzerq...@0pointer.de) wrote: On Fri, 31.10.14 16:13, Michal Schmidt (mschm...@redhat.com) wrote: On 10/31/2014 03:42 PM, Kevin Fenzi wrote: On Fri, 31 Oct 2014 14:01:12 +0100 Lennart Poettering mzerq...@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 signature.asc Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: possibly problem with rawhide (systemd-217?): Found ordering cycle on basic.target/start
On Fri, Oct 31, 2014 at 09:46:13AM -0600, Kevin Fenzi wrote: 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. Readahead was removed from systemd, so if you were using it, you should remove stale symlinks. -- Tomasz TorczThere exists no separation between gods and men: xmpp: zdzich...@chrome.pl one blends softly casual into the other. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: possibly problem with rawhide (systemd-217?): Found ordering cycle on basic.target/start
On Fri, 31.10.14 16:55, Tomasz Torcz (to...@pipebreaker.pl) wrote: On Fri, Oct 31, 2014 at 09:46:13AM -0600, Kevin Fenzi wrote: 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. Readahead was removed from systemd, so if you were using it, you should remove stale symlinks. I figure systemd.rpm is currently missing the right postinst scripts to remove those automatically on upgrade... Lennart -- Lennart Poettering, Red Hat -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: possibly problem with rawhide (systemd-217?): Found ordering cycle on basic.target/start
Fixes my problem, but black screen instead of gdm On Oct 31, 2014 7:31 PM, Lennart Poettering mzerq...@0pointer.de wrote: On Fri, 31.10.14 16:20, Lennart Poettering (mzerq...@0pointer.de) wrote: On Fri, 31.10.14 16:13, Michal Schmidt (mschm...@redhat.com) wrote: On 10/31/2014 03:42 PM, Kevin Fenzi wrote: On Fri, 31 Oct 2014 14:01:12 +0100 Lennart Poettering mzerq...@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) Thanks, Lennart -- Lennart Poettering, Red Hat -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: possibly problem with rawhide (systemd-217?): Found ordering cycle on basic.target/start
On Thu, Oct 30, 2014 at 09:47:36PM -0400, Matthew Miller wrote: Oct 30 21:39:37 ubik.home.mkmiller.org systemd[1]: Configuration file /usr/lib/systemd/system/auditd.service is marked world-inaccessible. This has no effect as configuration data is accessible via APIs without restrictions. Proceeding anyway. Nb. audit maintainer still refuses to fix this bug. https://bugzilla.redhat.com/show_bug.cgi?id=959483 -- Tomasz TorczThere exists no separation between gods and men: xmpp: zdzich...@chrome.pl one blends softly casual into the other. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: possibly problem with rawhide (systemd-217?): Found ordering cycle on basic.target/start
systemd-logind: failed to get session: PID 879 doesnt belong to any known session On Oct 31, 2014 7:31 PM, Lennart Poettering mzerq...@0pointer.de wrote: On Fri, 31.10.14 16:20, Lennart Poettering (mzerq...@0pointer.de) wrote: On Fri, 31.10.14 16:13, Michal Schmidt (mschm...@redhat.com) wrote: On 10/31/2014 03:42 PM, Kevin Fenzi wrote: On Fri, 31 Oct 2014 14:01:12 +0100 Lennart Poettering mzerq...@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) Thanks, Lennart -- Lennart Poettering, Red Hat -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: possibly problem with rawhide (systemd-217?): Found ordering cycle on basic.target/start
On 10/31/2014 04:57 PM, Igor Gnatenko wrote: systemd-logind: failed to get session: PID 879 doesnt belong to any known session That's not necessarily related to the problem. I have this message in the log even when gdm works fine. Michal -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: possibly problem with rawhide (systemd-217?): Found ordering cycle on basic.target/start
On Fri, 31 Oct 2014 20:04:24 +0400 Igor Gnatenko i.gnatenko.br...@gmail.com wrote: Probably. How to debug? On Oct 31, 2014 8:01 PM, Michal Schmidt mschm...@redhat.com wrote: On 10/31/2014 04:57 PM, Igor Gnatenko wrote: systemd-logind: failed to get session: PID 879 doesnt belong to any known session That's not necessarily related to the problem. I have this message in the log even when gdm works fine. Michal One possible reason for this: what version of mutter do you have? You might have the new 3.15 one, but the older gnome-shell. Either downgrade mutter or upgrade gnome-shell from the one just built in koji. They would have both gone out in today's rawhide, but there was a build failure on the gnome-shell build. kevin signature.asc Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: possibly problem with rawhide (systemd-217?): Found ordering cycle on basic.target/start
Probably. How to debug? On Oct 31, 2014 8:01 PM, Michal Schmidt mschm...@redhat.com wrote: On 10/31/2014 04:57 PM, Igor Gnatenko wrote: systemd-logind: failed to get session: PID 879 doesnt belong to any known session That's not necessarily related to the problem. I have this message in the log even when gdm works fine. Michal -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: possibly problem with rawhide (systemd-217?): Found ordering cycle on basic.target/start
I have all packages from koji. On Oct 31, 2014 8:10 PM, Kevin Fenzi ke...@scrye.com wrote: On Fri, 31 Oct 2014 20:04:24 +0400 Igor Gnatenko i.gnatenko.br...@gmail.com wrote: Probably. How to debug? On Oct 31, 2014 8:01 PM, Michal Schmidt mschm...@redhat.com wrote: On 10/31/2014 04:57 PM, Igor Gnatenko wrote: systemd-logind: failed to get session: PID 879 doesnt belong to any known session That's not necessarily related to the problem. I have this message in the log even when gdm works fine. Michal One possible reason for this: what version of mutter do you have? You might have the new 3.15 one, but the older gnome-shell. Either downgrade mutter or upgrade gnome-shell from the one just built in koji. They would have both gone out in today's rawhide, but there was a build failure on the gnome-shell build. kevin -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: possibly problem with rawhide (systemd-217?): Found ordering cycle on basic.target/start
yeah. gnome-shell 3.15.1 fixes problem. On Fri, Oct 31, 2014 at 7:09 PM, Kevin Fenzi ke...@scrye.com wrote: On Fri, 31 Oct 2014 20:04:24 +0400 Igor Gnatenko i.gnatenko.br...@gmail.com wrote: Probably. How to debug? On Oct 31, 2014 8:01 PM, Michal Schmidt mschm...@redhat.com wrote: On 10/31/2014 04:57 PM, Igor Gnatenko wrote: systemd-logind: failed to get session: PID 879 doesnt belong to any known session That's not necessarily related to the problem. I have this message in the log even when gdm works fine. Michal One possible reason for this: what version of mutter do you have? You might have the new 3.15 one, but the older gnome-shell. Either downgrade mutter or upgrade gnome-shell from the one just built in koji. They would have both gone out in today's rawhide, but there was a build failure on the gnome-shell build. kevin -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct -- -Igor Gnatenko -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
