Re: [systemd-devel] DBus's PropertiesChanged signal is not triggered when an Unit stop successfully
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 : > 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 > 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 > >: >> >>> 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 >>> 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" 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
Re: [systemd-devel] DBus's PropertiesChanged signal is not triggered when an Unit stop successfully
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 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 > : > >> 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 >> 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" 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
Re: [systemd-devel] DBus's PropertiesChanged signal is not triggered when an Unit stop successfully
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 : > 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 > 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" 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
Re: [systemd-devel] DBus's PropertiesChanged signal is not triggered when an Unit stop successfully
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 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" 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
Re: [systemd-devel] DBus's PropertiesChanged signal is not triggered when an Unit stop successfully
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" 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] DBus's PropertiesChanged signal is not triggered when an Unit stop successfully
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 because not *PropertiesChanged* signal is triggered. 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
