When you say 'Check the "state" instead ' Did you mean ActiveState ? <div class="gmail_quote">On Jul 3, 2015 3:39 PM, "Lennart Poettering" <<a href="mailto:lennart@poettering.net">lennart@poettering.net</a>> wrote: <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On Fri, 03.07.15 15:29, Pradeepa Kumar (<a href="mailto:cdpradeepa@gmail.com">cdpradeepa@gmail.com</a>) wrote: > I am writing lib which will monitor apps and notify/callback higher level > if apps went down. > How can I achieve this? > I tried doing this using propertieschanged signal and reading > substate We reserve the liberty to introduce new substates, and hence you shouldn't check "Substate" anyway if you want to stay compatible with future versions of systemd. Check the "State" instead, which is more abstract and is considered API. > property and that msg does not have old value and new value in the msg. > I noticed that when app go down i get two signals and hence two substates - > stop and stop-term. > So it is difficult to call registered callbacks only when substate changes > from running->stop. > Do i need to maintain current state of app in my lib? If you want to track these state changes, you'd have to cache the states client-side. > is there any other easier way for this ?? I fear not, sorry. Lennart -- Lennart Poettering, Red Hat </blockquote></div>