Both services A and B specify Requires=dbus.service and After=dbus.service. If I am interpreting everything that's being said correctly, there is a race condition in my code since service A's implementation doesn't require it to wait until it has processed the method call from service B before it stops listening for method calls. Does that sound right?
On Thu, Apr 2, 2015 at 6:31 AM, Lennart Poettering <lenn...@poettering.net> wrote: > On Thu, 02.04.15 13:07, Michael Biebl (mbi...@gmail.com) wrote: > > > 2015-04-02 13:03 GMT+02:00 Lennart Poettering <lenn...@poettering.net>: > > > On Thu, 02.04.15 13:00, Michael Biebl (mbi...@gmail.com) wrote: > > > > > >> 2015-04-02 11:06 GMT+02:00 Lennart Poettering <lenn...@poettering.net > >: > > >> > If you want to ensure that bus communication still works in your > > >> > shutdown code, you hence need to make sure you place > > >> > After=dbus.service in your services, so that you are shut down > before > > >> > dbus is. > > >> > > >> Type=dbus service currently only get a dependency on dbus.socket (via > > >> After=basic.target). > > > > > > Yeah, and rightfully so. I mean, a service really should be able to > > > shutdown if dbus is dead. In fact, it should be able to shutdown in > > > pretty much any situation... > > > > Apparently they don't. There were all sorts of failures caused by dbus > > being shut down too early. > > > > https://bugs.launchpad.net/ubuntu/+source/dbus/+bug/1438612 is one of > > the related bug reports afair. > > Hmm? I really don't see how the NFS vs wpa_supplicant issue has > anything to do with dbus? NFS doesn't care about dbus at all... > > You need to order wpa_supplicant and NM Before=remote-fs-pre.target > and pull it it via Wants=remote-fs-pre.target. With that in place > during shutdown the mounts will be unmounted first, and NM/wpa only > shut down after that. See systemd.special(7) for details. > > I really don't see what dbus has to do with all this... > > Lennart > > -- > Lennart Poettering, Red Hat > -- Kurt von Laven | Endless Mobile | EndlessM.com <http://endlessm.com/>
_______________________________________________ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
