Hide Forgot
systemctl list-units --all | grep dbus dbus.service loaded inactive dead D-Bus System Message dbus.socket loaded inactive dead D-Bus System Message dbus.target loaded active active D-Bus When my system starts anything using d-bus is failing. Also none of my lvm mounts are mounting on boot either... they do start like 20 minutes later however. This all happened on a reboot yesterday with all the latest updates applied. Before that everything was fine.
Another thing: When I boot I put systemd in debug mode. I see this in the logs: Breaking ordering cycle by deleting job dbus.socket/start That's all I can find of why it's not starting. I can manually start it with systemctl start dbus.service fine. It's just not going on boot.
Looks like a systemd problem to me...
(In reply to comment #1) > When I boot I put systemd in debug mode. I see this in the logs: > > Breaking ordering cycle by deleting job dbus.socket/start That certainly looks relevant. Please attach the complete log to this bug.
Created attachment 487142 [details] Boot Log with all the messages The other thing happening is the lvm drives are not setup on boot. They tend to get triggered like 20 minutes later and all start mounting. I have a feeling the problems are related.
We some ordering cycles here. I cannot find a service called "cf_hostname" in Fedora. Is that your own service? Trying to enqueue job graphical.target/start/replace Found ordering cycle on basic.target/start Walked on cycle path to udev-retry.service/start Walked on cycle path to cf_hostname.service/start Walked on cycle path to basic.target/start Breaking ordering cycle by deleting job udev-retry.service/start Found ordering cycle on basic.target/start Walked on cycle path to sockets.target/start Walked on cycle path to dbus.socket/start Walked on cycle path to sysinit.target/start Walked on cycle path to systemd-random-seed-load.service/start Walked on cycle path to local-fs.target/start Walked on cycle path to quotacheck.service/start Walked on cycle path to u2-CarterFamilyMedia-CarterFamilyPictures.mount/start Walked on cycle path to network.target/start Walked on cycle path to network.service/start Walked on cycle path to ip6tables.service/start Walked on cycle path to cf_hostname.service/start Walked on cycle path to basic.target/start Breaking ordering cycle by deleting job dbus.socket/start Deleting job dbus.service/start as dependency of job dbus.socket/start Found ordering cycle on basic.target/start Walked on cycle path to sysinit.target/start Walked on cycle path to systemd-random-seed-load.service/start Walked on cycle path to local-fs.target/start Walked on cycle path to quotacheck.service/start Walked on cycle path to u2-CarterFamilyMedia-CarterFamilyPictures.mount/start Walked on cycle path to network.target/start Walked on cycle path to network.service/start Walked on cycle path to ip6tables.service/start Walked on cycle path to cf_hostname.service/start Walked on cycle path to basic.target/start Breaking ordering cycle by deleting job systemd-random-seed-load.service/start Found ordering cycle on basic.target/start Walked on cycle path to sysinit.target/start Walked on cycle path to local-fs.target/start Walked on cycle path to quotacheck.service/start Walked on cycle path to u2-CarterFamilyMedia-CarterFamilyPictures.mount/start Walked on cycle path to network.target/start Walked on cycle path to network.service/start Walked on cycle path to ip6tables.service/start Walked on cycle path to cf_hostname.service/start Walked on cycle path to basic.target/start Breaking ordering cycle by deleting job local-fs.target/start
Any thing with cf_ is my own stuff. Which I'm in the process of converting to systemd now. Their just simple scripts to gather and save information to the HD for my own debugging.
You seem to have create a dependency loop here. Your service "cf_hostname" wants to be both before basic.target and after basic.target (the latter indirectly via network.service). If systemd encounters such a loop it tries to break it by removing services from the transaction. It doesn't really know which service really matters to you and hence you might end up with stuff droipped you are really missing. The right fix is to fix the dep loop: decide whether you want the cf_hostname run before or after basic.target. If you want it before you need to use "DefaultDependencies=no" in it and configure all deps manually.
Just wanted to add this in case someone has a similar issue. cf_hostname is a script created prior to systemd and used SYSV (at least I think that's what it's called) So it was to run based on the 0-99 priority. If this is causing a loop then other legacy scripts can fall into the same problem. To fix I just converted to systemd and set the proper dependencies... ie I only need the cf_hostname check to run before firstboot.
Seeing quotacheck.service and udev-retry.service in the cycles makes me believe that this problem is probably gone with the current systemd and udev versions. (udev-retry is gone and a known bug where quotacheck was added when it should not has been fixed.)
(In reply to comment #8) > Just wanted to add this in case someone has a similar issue. > > cf_hostname is a script created prior to systemd and used SYSV (at least I > think that's what it's called) > > So it was to run based on the 0-99 priority. If this is causing a loop then > other legacy scripts can fall into the same problem. Yupp, systemd is a bit more strict here, we actually try to honour the ordering requests... This sometimes brings us into trouble...