[systemd-devel] DBus's PropertiesChanged signal is not triggered when an Unit stop successfully

[Adrien Besnard]

Okay, thank you: now I see the purpose of systemd's jobs.

So, if I get it well: if I want to monitor any kind of service
(Type=oneshot, Type=simple, etc.), I need to catch UnitRemoved event and
invoke the LoadUnit to get the status of the stopped (either in failure or
in success) Unit, right?

The tricky part is that calling LoadUnit cause an UnitNew event (which I
also monitor) and I may be caught in an infinite loop, because the
UnitRemoved is also launched just after...

I will be easier if the PropertiesChanged event is also launched on a Unit
finishing in success!





Adrien BESNARD

2016-05-30 14:22 GMT+02:00 Jan Alexander Steffens <jan.steffens at gmail.com>:

> Any Start/Stop/Restart operation you issue creates a job that will
> eventually (almost immediately, when starting a Type=simple service) get
> completed (or fail) and trigger a JobRemoved signal containing the result.
>
> When StartUnit/StopUnit/etc return they give you the job's object path you
> need to check the incoming signals against to get the result of the job you
> issued.
>
> Type=simple services complete their Start job so quickly that you're
> extremely unlikely to catch them on list-jobs.
>
>
> On Mon, May 30, 2016 at 2:12 PM Adrien Besnard <adrien.besnard at gmail.com>
> wrote:
>
>> Thank you! I'll try that ASAP. Do I need to listen to JobRemoved because
>> I use the [type=oneshot] or is it the way to do for every kind of service
>> (like [type=simple], for example)?
>>
>> I'm asking that because I just dicovered that [systemctl list-jobs] lists
>> my [type=oneshot] service when I start it, but I have no idea if it's
>> related or not...
>>
>> Cheers,
>>
>> Adrien BESNARD
>>
>> 2016-05-26 11:59 GMT+02:00 Jan Alexander Steffens <jan.steffens at gmail.com
>> >:
>>
>>> You need to listen to JobRemoved signals. All of them, before you start
>>> your job - trying to match on the specific job you get back from StopUnit
>>> might not complete before the job is already removed.
>>>
>>> On Thu, May 26, 2016 at 8:20 AM Adrien Besnard <adrien.besnard at gmail.com>
>>> wrote:
>>>
>>>> I managed to do what I wanted to do using add_timeout with the GLib's
>>>> MainLoop: I poll every second the state of the unit and manually call the
>>>> callback connected to DBus to fake the event when the unit is stopped.
>>>>
>>>> It works but this is a dirty hack. So I'm still interested by a real
>>>> solution :)
>>>>
>>>> Cheers!
>>>> Le 23 mai 2016 11:55, "Adrien Besnard" <adrien.besnard at gmail.com> a
>>>> écrit :
>>>>
>>>>> Hello,
>>>>>
>>>>> I'm trying to make a small Python script which send an email when a *Type=oneshot
>>>>> *service ends (either in success or in failure).
>>>>>
>>>>> To do that, I'm using the dbus binding for Python, and connecting to
>>>>> the *PropertiesChanged* signal on the unit I'm monitoring.
>>>>>
>>>>> It works great when the process fails (the signal is triggered and I
>>>>> see *ActiveState* and *SubState* refleting the failure) but not when
>>>>> the service end successully.
>>>>>
>>>>> All I see is an *UnitRemoved* signal triggered by the manager
>>>>> interface... Is that normal?
>>>>>
>>>>> Do you guys have an idea of what I'm missing here?
>>>>>
>>>>> Thanks!
>>>>> --
>>>>> Adrien BESNARD
>>>>>
>>>> _______________________________________________
>>>> systemd-devel mailing list
>>>> systemd-devel at lists.freedesktop.org
>>>> https://lists.freedesktop.org/mailman/listinfo/systemd-devel
>>>>
>>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/systemd-devel/attachments/20160530/fb5497c3/attachment-0001.html>