Re: [systemd-devel] ActiveState property with value "inactive"is not being sent out when service is killed by signal
For the moment, I gave up writing a nice script based on DBus's PropertiesChanged events, and I made a temporary dirty script which poll the service status. I did not solve that in a good way. -- Adrien BESNARD 2016-07-27 11:47 GMT+02:00 Pradeepa Kumar : > Thanks Adrien. > yes it is same issue. > Could you please let me know how did you resolve this ? > I was browsing through sytemd code and my theory is that by the time > properties changed signal is being prepared to be sent, service has already > gone through mutiple state changes or the unit is unloaded and hence no > property changeg signal is sent out. > As workaround , I am planning to watch on SubState instead of ActiveState > in PropertiesChanged signal and also have ExecStopPost in service file. > I have noticied that, when a service becomes inactive I always get > SubState=stop-post (when i have ExecStopPost ). > > Can anyone please comment if this is correct work-around ? > > Thanks > > > On Wed, Jul 27, 2016 at 2:26 PM, Adrien Besnard > wrote: > >> I may be wrong, but it sounds like the issue I encoutered here: >> https://github.com/systemd/systemd/issues/3390. I also wanted to build a >> service monitoring tool :) >> >> Cheers, >> -- >> Adrien BESNARD >> >> 2016-07-26 11:24 GMT+02:00 Pradeepa Kumar : >> >>> Hi >>> ActiveState property with value "inactive"is not being sent out when >>> service is killed by signal >>> I am using 219 version. >>> I logged issue https://github.com/systemd/systemd/issues/3807 >>> Thanks >>> >>> >>> >>> ___ >>> 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] ActiveState property with value "inactive"is not being sent out when service is killed by signal
I may be wrong, but it sounds like the issue I encoutered here: https://github.com/systemd/systemd/issues/3390. I also wanted to build a service monitoring tool :) Cheers, -- Adrien BESNARD 2016-07-26 11:24 GMT+02:00 Pradeepa Kumar : > Hi > ActiveState property with value "inactive"is not being sent out when > service is killed by signal > I am using 219 version. > I logged issue https://github.com/systemd/systemd/issues/3807 > Thanks > > > > ___ > 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
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
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
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
