S25bluetooth depends on S97messagebus.
Please start dbus earlier.
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?
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.
"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
Nah, unix domain sockets are fine.
"root fs" = /, /lib, /etc, /sbin, /tmp, /var. *NOT* /usr.
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?
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.
*** Bug 150196 has been marked as a duplicate of this bug. ***
*** Bug 150195 has been marked as a duplicate of this bug. ***
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.
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.
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
*** Bug 176522 has been marked as a duplicate of this bug. ***