Hi. I've read the unit files you provide and I'm wondering about a possible race condition related to dbus activation.
For example let's see the unit gconf.service: > [Unit] > Description=settings daemon for gnome > > > [Service] > Type=dbus > BusName=org.gnome.GConf > ExecStart=/usr/libexec/gconfd-2 > > > [Install] > WantedBy=gnome.target > Alias=dbus-org.gnome.GConf.service Why this line Alias= ? Creating this alias is only useful if you add a line "SystemdService=dbus-org.gnome.GConf.service" to the file /usr/share/dbus-1/services/org.gnome.GConf.service (this is a major pain in the current dbus and systemd architecture…). Moreover, even if you did, I thought that bus activation in the user session was not implemented ? (I'd be very happy to be proved wrong here :). Now, in such a situation, this is how a race condition can appear: Let's say that gnome-settings-daemon makes use of the well known name org.gnome.GConf on the bus (it's probably the case). Usually, gconf.service will be launched, will take the name on the bus, then gnome-settings-daemon.service will be launched, will talk to this name, gconf will answer and everything is fine. However gconf.service and gnome-settings-daemon.service are actually launched *in parallel*. Let's imagine than for any reason gconf.service takes a looong time before taking the well-know name on the bus. During this time gnome-settings-daemon launches and try to talk to org.gnome.GConf. Since no one owns this name (remember, gconf.service is a snail today), the dbus daemon will launch gconf according to the file /usr/share/dbus-1/services/org.gnome.GConf.service. This causes the first problem : the gconf daemon will be part of the dbus.service cgroup, which is bad. Then a second problem appears : gconf.service finally awakes from its nap and try to take the name on the bus. Ooops : it's already taken by the daemon launched by dbus-daemon… Thus gconf.service will fail. Race condition, not good. The exact same kind of stuff appears with pulseaudio (launched by gnome-settings-daemon aswell) and virtually any bus-activated user service that you'd like to be a service managed by systemd instead of dbus-daemon. Regards, Léo Gillot-Lamure. _______________________________________________ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel