S25bluetooth depends on S97messagebus. Please start dbus earlier.
First services are currently: S05kudzu S08iptables S09isdn S10network S12syslog S13portmap S14nfslock S17keytable S20random S24pcmcia S25netfs S26apmd 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 /var/ lockfiles?
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 dbus.
*** Bug 176522 has been marked as a duplicate of this bug. ***