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.besn...@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.steff...@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.besn...@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.besn...@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@lists.freedesktop.org >>> https://lists.freedesktop.org/mailman/listinfo/systemd-devel >>> >> >
_______________________________________________ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
