Re: [systemd-devel] dbus and exit-on-idle

[Matthijs van Duin]

On 22 May 2017 at 10:36, Lennart Poettering  wrote:

> Yes, the exit-on-idle logic on dbus is impossible to implement
> correctly for non-trivial cases right now.
>

Hmm? Can you elaborate? Apart from the two issues I identified (which look
easily fixable to me), are there more known races that would remain?

non-trivial additions to the dbus spec


Yeah, I'm not holding my breath for that one...
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] dbus and exit-on-idle

[Colin Walters]

On Sun, May 21, 2017, at 08:26 PM, Matthijs van Duin wrote:
> I've been pondering how to allow my bus-activated service to exit when
> it's unneeded (which is 99% of the time), and in particular how to deal
> with exit/activate races correctly...

See also https://lists.freedesktop.org/archives/dbus/2015-May/016671.html
I was recently working on using this in 
https://github.com/projectatomic/rpm-ostree/pull/606
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] dbus and exit-on-idle

[Lennart Poettering]

On Mon, 22.05.17 02:26, Matthijs van Duin (matthijsvand...@gmail.com) wrote:

> I've been pondering how to allow my bus-activated service to exit when
> it's unneeded (which is 99% of the time), and in particular how to deal
> with exit/activate races correctly...
> 
> In the systemd sources I stumbled across the helper function
> bus_event_loop_with_idle() which does a clever trick by
>  - using sd_notify("STOPPING=1") to make sure systemd will queue any
>activations from here on
>  - releasing the dbus service name
>  - handling any remaining requests until the name deregistration is
>confirmed by the dbus daemon
> 
> Thus, any incoming request will either be delivered to you, or trigger a
> new activation and be delivered to the next instance of your service.
> 
> I see two problems here:
>  1. sd_notify is asynchronous and nothing is done to ensure systemd has
> acted on it before the service name is released.
>  2. If you get an incoming request that requires you to continue running
> after you've told systemd you're stopping, you're screwed.
> 
> The first problem could be solved by monitoring your own unit status I
> suppose, although it would be more elegant if the sd_notify() could be
> replaced by a dbus call.
> 
> The second problem is more annoying... although you could just register
> your bus name again (which presumably suffices to get any queued calls
> delivered to you?), once you've told systemd you're stopping there's no
> way back currently, and it will SIGKILL you if you take too long.
> 
> Could this be solved by simply allowing a stopping service to change its
> mind, e.g. with sd_notify("STOPPING=0") or perhaps another READY=1 ?

Yes, the exit-on-idle logic on dbus is impossible to implement
correctly for non-trivial cases right now. It's a pity. I think the
best option to solve this properly would be to switch to
AF_UNIX/SOCK_SEQPACKET sockets for this, as an alternate transport,
then do away with all the auth/nego logic and permit assigning names
to such bus connects as part of systemd itself. That way we'd have
unified all connection state logic in a single socket, and could do
dbus activation the same way as normal socket activation and the whole
race problem goes away... 

But of course, that's a lot of work, and would require non-trivial
additions to the dbus spec.

In the meantime, adding a way to "cancel" stopping sounds OK to me.

Lennart

-- 
Lennart Poettering, Red Hat
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

[systemd-devel] dbus and exit-on-idle

[Matthijs van Duin]

I've been pondering how to allow my bus-activated service to exit when
it's unneeded (which is 99% of the time), and in particular how to deal
with exit/activate races correctly...

In the systemd sources I stumbled across the helper function
bus_event_loop_with_idle() which does a clever trick by
 - using sd_notify("STOPPING=1") to make sure systemd will queue any
   activations from here on
 - releasing the dbus service name
 - handling any remaining requests until the name deregistration is
   confirmed by the dbus daemon

Thus, any incoming request will either be delivered to you, or trigger a
new activation and be delivered to the next instance of your service.

I see two problems here:
 1. sd_notify is asynchronous and nothing is done to ensure systemd has
acted on it before the service name is released.
 2. If you get an incoming request that requires you to continue running
after you've told systemd you're stopping, you're screwed.

The first problem could be solved by monitoring your own unit status I
suppose, although it would be more elegant if the sd_notify() could be
replaced by a dbus call.

The second problem is more annoying... although you could just register
your bus name again (which presumably suffices to get any queued calls
delivered to you?), once you've told systemd you're stopping there's no
way back currently, and it will SIGKILL you if you take too long.

Could this be solved by simply allowing a stopping service to change its
mind, e.g. with sd_notify("STOPPING=0") or perhaps another READY=1 ?

Matthijs van Duin
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel