D-Bus not starting on boot

[MikeyCarter]

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?

[jpollard]

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.

[MikeyCarter]

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"

[jpollard]

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.

[MikeyCarter]

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.

[jpollard]

Well... they have implemented a dependency hell....

way to go - complete MS emulation.

[RahulSundaram]

Hi

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.

[jpollard]

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.

[RahulSundaram]

Hi

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.

https://bugzilla.redhat.com/show_bug.cgi?id=689861

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

[MikeyCarter]

"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?

[RahulSundaram]

Hi

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.

[jpollard]

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).

[RahulSundaram]

Hi

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

http://lists.freedesktop.org/mailman.../systemd-devel

[jpollard]

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.

[RahulSundaram]

"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