Bug 104058 - dbus starts too late
Summary: dbus starts too late
Alias: None
Product: Fedora
Classification: Fedora
Component: dbus
Version: rawhide
Hardware: All
OS: Linux
Target Milestone: ---
Assignee: John (J5) Palmieri
QA Contact:
: 150195 150196 176522 (view as bug list)
Depends On:
Blocks: CambridgeTarget 150195 FC5Blocker
TreeView+ depends on / blocked
Reported: 2003-09-09 15:01 UTC by David Woodhouse
Modified: 2013-03-13 04:49 UTC (History)
7 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2006-02-06 15:31:43 UTC
Type: ---

Attachments (Terms of Use)

Description David Woodhouse 2003-09-09 15:01:53 UTC
S25bluetooth depends on S97messagebus. 

Please start dbus earlier.

Comment 1 Havoc Pennington 2003-10-04 05:27:57 UTC
First services are currently: 


I can imagine kudzu, network, syslog, pcmcia, apmd etc. using dbus someday, so
arguably dbus should be S03. I can imagine dbus requiring some of those other
things, but then again I don't think it currently does; it doesn't listen on
remote network sockets (thankfully).

Any opinions on the proper dbus priority?

Comment 2 Bill Nottingham 2003-10-06 05:21:22 UTC
Current policy is that all services that depend on netowrking must start after
network (duh), and all services that depend on things outside of the root FS
must start after netfs.

If neither of those is required, start as early as you want.

Comment 3 Havoc Pennington 2003-10-06 15:19:47 UTC
"network" covers TCP/IP, but would not cover a unix domain socket, right?

What does "root fs" mean for netfs? Does it include /etc config, /usr/bin, and
/var/ lockfiles?

Comment 4 Bill Nottingham 2003-10-06 19:13:28 UTC
Nah, unix domain sockets are fine.

"root fs" = /, /lib, /etc, /sbin, /tmp, /var. *NOT* /usr.

Comment 5 John (J5) Palmieri 2004-09-10 17:54:23 UTC
As dbus stands right now all of its libraries are in /usr/lib and
binaries in /usr/bin.  This means the earliest we can start dbus is
after S25netfs.  If we want to start it earlier, perhaps before kudzu,
we need to move dbus into /sbin and /lib.  And what about HAL?  It is
concevable that kudzu will also use HAL in the future.

Should I move dbus up to S26 for now (bluetooth would still need to
move down)?  Do we need to get it up higher in the chain and therefor
start the task of having everything installed in /lib and /sbin or can
that be put off for another release?

Just noticed this is an old bug.  Do we care about it anymore?

Comment 6 Bill Nottingham 2004-09-10 18:43:48 UTC
If bluetooth still needs it, we could move it up. As I understood,
bluetooth uses it for asking the user for data, though - that's not as
relevant during system startup.

Comment 7 John (J5) Palmieri 2005-03-11 20:27:20 UTC
*** Bug 150196 has been marked as a duplicate of this bug. ***

Comment 8 John (J5) Palmieri 2005-03-11 20:27:30 UTC
*** Bug 150195 has been marked as a duplicate of this bug. ***

Comment 9 John (J5) Palmieri 2005-03-11 20:32:52 UTC
I need to talk to upstream about putting dbus in /sbin and /lib.  We should do
that.  Unfortunatly it doesn't solve the issue of networking which needs HAL. 
Hal links to glib so it can't be easily moved into /sbin and /lib.  Chicken and
the egg problem occures when a user is relying on NetworkManager to bring up an
NFS mounted /usr.  I will work on the problem of dbus starting late first and
then we can figure out what to do about HAL and NetworkManager.

Comment 10 Steve Grubb 2006-01-19 12:30:00 UTC
Just a note on this, we need the dbus SE Linux messages to land in the audit
deamon, so dbus has to start after the audit daemon. I've moved the audit daemon
to start just before syslog.

Comment 11 John (J5) Palmieri 2006-01-20 21:46:40 UTC
I'm starting dbus at 22 and stopping at 85 (auditd stops at 88) in the next
build however bluetooth stops at 90.  It should most likely stop before we stop

Comment 12 John (J5) Palmieri 2006-02-06 15:29:59 UTC
*** Bug 176522 has been marked as a duplicate of this bug. ***

Note You need to log in before you can comment on or make changes to this bug.