View Full Version : D-Bus not starting on boot

21st March 2011, 03:53 PM
I've applied all the latest rawhide packages and rebooted. Now I'm getting all sorts of failures on boot up and most of my LVM drives don't mount. Even the root filesystem was started readonly.

I fixed the readonly problem by changing the ro to rw in the boot/grub/grub.conf file. But I think the other failures are the fact that dbus isn't started. What starts it and when?

21st March 2011, 04:03 PM
Normally, root is always mounted read only to start with.

Once the filesystem has been verified it would be remounted read/write.

I didn't think dbus had anything to do with LVM...

Are you running F15 (I assume)?

If LVM depends on dbus, then I think this is another instance of overdependance of the system boot.

21st March 2011, 04:22 PM
Yes F15, sorry posting in the rawhide I thought it was a given..

On reboot LVM doesn't mount and a pile of services fail. Looking at the /var/log/messages many services are failing because they can't contact the dbus. further checking showed the dbus isn't started. Since theirs no other failures I figured if I can find why it's not starting on boot it might tell me why everything else is failing.

---------- Post added at 11:22 AM ---------- Previous post was at 11:16 AM ----------

Umm wonder if this has something to do with it all...

"Breaking ordering cycle by deleting job dbus.socket/start"

21st March 2011, 04:25 PM
On Fedora 14, dbus is only started in runlevel 2/3/4 or 5 (messagebus).

lvm monitoring is started in 1/2/3/4/5 - implying it is started first, before dbus.

Which makes sense, as LVM could be needed to mount the root filesystem (not the boot filesystem).

To me, it makes no sense to make LVM depend on dbus, as dbus can't be started before the root filesystem is mounted.

"Breaking ordering cycle by deleting job dbus.socket/start"

Ouch. An unusable system.

Glad I'm not using 15.

21st March 2011, 04:48 PM
F15 was working till I rebooted. Saw a kernel update... (and old kernel doesn't work either if anyone's going to ask)

If I play by restarting services and such I can get the system up and running. dbus failing is definitely most of my problems.

21st March 2011, 09:48 PM
Well... they have implemented a dependency hell....

way to go - complete MS emulation.

22nd March 2011, 09:55 AM

File a bug report in bugzilla. It is far more effective in resolving problems such as these. Jpollard, would be nice if you can be constructive. Thanks.

22nd March 2011, 02:03 PM
They have been ignoring bug reports for a while.

I realize that some things take a long time to fix.

But this kind of dependency would have shown up as soon as they implemented it.

Obviously, they didn't bother to test at all.

25th March 2011, 02:44 PM

I am sorry but you unless you can provide examples of ignored bug reports against systemd, you are merely trolling. Btw, this bug seems to be user introduced seeing the bug report that was filed.


I highly recommend that you understand the specific problem before commenting.

25th March 2011, 02:58 PM
"bug seems to be user introduced" I don't doubt it. But what gives you this indication? Is there some area that I introduced I should be looking at?

25th March 2011, 03:06 PM

The problem seems user introduced before noone else has reported this problem and my Rawhide system boots fine. It seems a fairly simple ordering issue. We will keep further analysis within bugzilla.

25th March 2011, 03:29 PM
Actually, several people have indicated this. and with different services.

Nothing really unusual... except that systemd appears to be either doing things out of order OR layered applications (LVM for one) has changed causing a dependency loop.

And not exactly trolling - I have been ignored when asking how to debug systemd and how to trace the order things get done. I just get referred to the old documentation on how it "should" work, but that only addressed the starting of network services.... Either I missed it, or there wasn't any documentation on services that use domain sockets, or no sockets at all (using shared memory, or event queues).

25th March 2011, 03:45 PM

No. Several people have NOT complained about this specific issue and you have yet to provide a single evidence of any bug report against being ignored. I introduced systemd into Fedora originally and still get copied on all the bug reports against it in Fedora, so I am open to actual evidence of any bug report being ignored and otherwise consider your post just trolling and nothing more.

Where have you asked for information exactly? Not in the upstream developers mailing list which is here


25th March 2011, 04:53 PM
Its been several months now (5/6?), but it was not in the development list, as I am not a systemd developer. It was somewhere with the announcement that systemd was replacing the standard startup.

I'm not totally against systemd, just that information on how it works, why it works the way is does, and how to control it just wasn't very forthcoming - basically a "go away, were busy working" type of response
with the standard "look at the documentation here" thing.

No problem, other than the documentation was not very clear, and obviously out of date even then.

The primary advantage SysV init has is that it is simple to create, modify, and update. the disadvantage is that it is relatively slow.

The primary advantage systemd has is that it is fast. but it also appears difficult to modify, and update. It also seems to be difficult to have repeatable operation as asynchronous events could cause problems where the "event" doesn't happen to the developers, or even happen very often.

The example I'm thinking of has likely not happened, and is based on the reports that LVM can't start because dbus hasn't started. This may not be an issue.. unless LVM needs to log something that is preventing it from initializing the system disk... but dbus appears to require the system disk to get started...

I grant that this is a bit of a contrived example, and it may be totally inadvertent but documentation on tracing something like this (and I have had to do that level of tracing before) wasn't available then.

With the SysV init, all that was necessary was to set the shell scripts to "sh -vx", and look where it hung to see what odd thing that it was depending on. In my case, it turned out to be an external system. Everything was fine if the other system was running... but if both were booted simultaneously, then one or the other (or both) would hang. They were requesting information from a remote server before starting their own server causing in inversion deadlock, both sides would wait for a server to respond before they started their server - a simple reordering of the activity fixed it.

Some things cannot be automatically determined, and it appears (from my skimpy knowledge) that systemd is attempting to automatically determine everything.

---------- Post added at 11:53 AM ---------- Previous post was at 11:27 AM ----------

After browsing the systemd mail list... I see they too are still having problems with loops.

One added note... the more they expand the configuration file the slower systemd will get. Worst case it will devolve into another shell.

25th March 2011, 06:01 PM
"Some things cannot be automatically determined, and it appears (from my skimpy knowledge) that systemd is attempting to automatically determine everything"

Nope. systemd doesn't do that. You have never filed a single bug report or posted to any place where any systemd developer would actually read it yet you complain about how your vague unspecified issues are not resolved. Need I say more? I rest my case

25th March 2011, 08:39 PM
I wasn't complaining. If I were a systemd user then you bet I would have been giving bug reports.

Just stating what I perceive as severe problems, and having browsed the mailing list, had them confirmed.

Will it get fixed? Probably. Will it be reliable and easy to maintain? That is up in the air.

26th March 2011, 06:24 AM

If you browse a developer mailing list of any software, you will be able to find bugs. That isn't news.

Let's go back to what you said

"They have been ignoring bug reports for a while."

You now admit that you have reported no bugs and don't even use the software. Yet you did clearly complain. This is trolling and I am asking you to stop. If you have a actual problem, point it out and be specific. Perceptions based on a very vague understanding on how the software works and no actual experience does not count.

26th March 2011, 12:50 PM
As I said - "go away, don't bother us, we're busy". Just as you did.

I've worked with PERT chart data (and that is all systemd appears to be) and I know it is hard to setup. I also know you have additional problems with it - having to make branches optional, how to identify loops, what to do with loops, what to do it disconnected branches, tracing...

And having to keep up with the applications that change under you.

It isn't something simple, nor easily configured, nor easily maintained.

And documenting it is even harder.

26th March 2011, 01:34 PM

"As I said - "go away, don't bother us, we're busy". Just as you did."

No. I did not say that nor have you pointed to any systemd developer saying that. You have not asked in any place a systemd developer could answer your questions. You have not filed a single bug report nor have you posted a single mail in the systemd developer mailing list. So stop your misleading claims or point out the evidence.

26th March 2011, 02:12 PM
I'll repeat for the last time.

Where is the design documentation on how it works, how to debug the flow, and how to use it?

26th March 2011, 02:17 PM

I will repeat for the last time, ask in the systemd developer mailing list if you have questions. This is a end user forum. Not a developers forum.


All available documentation is linked from


I am closing this thread