[systemd-devel] Synchronization Between Services at Shutdown

[Kurt von Laven]

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 <kurt at 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 <lennart at poettering.net
> > wrote:
>
>> On Thu, 02.04.15 13:07, Michael Biebl (mbiebl at gmail.com) wrote:
>>
>> > 2015-04-02 13:03 GMT+02:00 Lennart Poettering <lennart at poettering.net>:
>> > > On Thu, 02.04.15 13:00, Michael Biebl (mbiebl at gmail.com) wrote:
>> > >
>> > >> 2015-04-02 11:06 GMT+02:00 Lennart Poettering <
>> lennart at 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/>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/systemd-devel/attachments/20150402/5d9c6402/attachment-0001.html>