HAL fails to initialise when /etc/init.d/rc sets CONCURRENCY=shell

Happened to me too. I read online that this option would multi-thread the boot up and speed it up. I'm running an Opteron 165 dual core with Gutsy x64.

Setting the /etc/init.d/rc back to "concurrency=none" fixed the issue.

I can confirm, I tried this in the beta of gutsy (x64), and it still shows this behaviour.

I run it on a dell xps m1710, a core2 duo platform...

If hardware specs or logfiles are needed, i'm willing to provide them, so just let know here!

I can confirm this as well, seems to be some kind of order dependency issue between dbus and HAL.

I can confirm this as well running Gutsy Beta on Dell Latitude D520

I can confirm this as well, running Kubuntu 7.10 on intel C2D e4300.

The proble is that HAL starts more quickly than DBus so it says that DBus is not running. So to solve this issue I changed the starting level of HAL with
mv /etc/rc2.d/S12hal /etc/rc2.d/S13hal
Now I works fine!

I can confirm the bug. After setting CONCURRENCY=shell, HAL attempts to initialise before DBus, causing an error. HAL starts fine manually after boot up, and changing it's starting level fixes the problem as Andrea mentioned above.

I confirm that solution. More I've added a point to /etc/rc2.d/S13gdm to be sure it's invoked just after hal as were before.

Rarely HAL doesn't start anymore (I've got 2 very fast processors :D), so I've added `sleep 1` to /etc/rc/hal.

I change the priority to Low because the problem can be easily solved with a workaround.

Couldn't this be fixed with the dependencies mechanism of upstart ?

Bug #164127 seems related without being a duplicate (at least I think so).

This is a race condition between hal and dbus which happens when the two initscripts are started concurrently by upstart.

This should not happen because hal initscript requires dbus for starting but instead happens when upstart concurrency is enabled because the scripts have been symlinked with the same number (12).

The solution is to install hal initscripts with NN=13 (see attached patch).

Bug and workaround confirmed here on Ubuntu Gutsy amd64.

Bug and workaround confirmed in Kubuntu Gutsy amd64, in Kubuntu Hardy amd64 there isn't bug

In Hardy, hal now starts at priority 24, and gdm at 30, so this should be fixed.

Confirmed in Hardy Beta. But my hal and dbus are both set to S12 in the rc#.d folders, not 24 (though gdm is at 30).

Yes, there's a workaround, but doesn't it make sense to set the two of them a little apart by default? Editing init.d filenames is not the most user-friendly of actions. Will the above patch be included in standard updates?

I've just been bitten by this bug, using the Hardy Beta Kubuntu "remix" with KDE4, on an AMD64 (Turion) based laptop.
In /etc/rc2.d, I had:
s12dbus
S24hal
s13kdm

And I needed to do this to get past the problem:
   mv S24hal S13hal
   mv s13kdm s14kdm

And yes, I suggest that this bug is far worse than a priority of "Low". Yes, a workaround exists,
but shrugging off this kind of problem is sabotaging the efforts of everyone trying to improve
the usability reputation of linux.

I can confirm the same issue on Hardy (upgraded from gutsy).

pls reopen this bug. it affects hardy too.
although below command fixed it,
mv /etc/rc2.d/S12hal /etc/rc2.d/S13hal
(thanks Andrea Corbellini)

I can confirm this in Hardy as well with the latest updates (including proposed). The workaround does solve the issue, but the average user will simply get frustrated.

this is my current default settings as i find them in /etc/rc2.d:
S12dbus
S24hal
S30gdm
it seems to be fixed and concurrency=shell works fine :)
running ubuntu hardy 8.04