Actually I think I just answered my own question and in the process realized that I didn't provide enough context in my original question. There is a race condition in my code because when service B receives SIGTERM, it calls g_dbus_connection_flush_sync <https://developer.gnome.org/gio/stable/GDBusConnection.html#g-dbus-connection-flush-sync> after a g_dbus_proxy_call <https://developer.gnome.org/gio/stable/GDBusProxy.html#g-dbus-proxy-call> to service A in an incorrect attempt to ensure that service A has handled the DBus proxy call. The problem with this is that g_dbus_connection_flush_sync ensures all outgoing messages are sent over the DBus connection but doesn't wait around for replies to those messages. Service B should instead call g_dbus_proxy_call_sync <https://developer.gnome.org/gio/stable/GDBusProxy.html#g-dbus-proxy-call-sync> and call neither g_dbus_connection_flush_sync nor g_dbus_proxy_call. Please correct me if I am missing something.
On a separate note, how long does systemd wait after sending a SIGTERM to a service before sending it a SIGKILL? Is it reasonable to assume that a few g_dbus_proxy_call_sync calls would complete in that time if the slowest part of those calls is just the standard overhead of a DBus call? I ask because currently I acquire a shutdown inhibitor <http://www.freedesktop.org/wiki/Software/systemd/inhibit/> in service B, and I now suspect this is unnecessary. Be well, Kurt On Thu, Apr 2, 2015 at 9:49 AM, Kurt von Laven <k...@endlessm.com> wrote: > 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/> > -- 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