On Mo, 18.02.19 16:46, aleivag (aleivag@xxxxxxxxx) wrote: > 1.- Is this change in behaviour, intended, or a side effect of something > else? When a unit is first created it is in "dead" state. It only changes to "active" state as soon as it actually starts running. Note that PropertiesChanged is currently sent a bit too eagerly: when some property changes we'll update you with the full data, not just what changed. In an older verison we forgot to send out these change messages in some conditions, which was fixed (iirc something about the job assignment changing). Note that a unit may stay in "dead" state for a while actually before it moves to "active", since dependencies might need to be started first. In general: if you want to properly watch a transient service starting and then running and exiting, the way to do this is like this: 1. First watch for the JobRemoved event for the job you got back when you create the transient unit. 2. Now wait until the unit itself for PropertiesChanged, and wait until it transitions back do "dead" or "failed". 3. In some cases a unit might go directly to "dead" again (without going through "active"; for example when a condition is defined that results in the job to be shortcut). Because of this, after you saw the JobRemoved, and you subscribed to PropertieChanged you should explicitly query the ActiveStatus property to see where are at. > 2.- was what i was doing the best way to decide if a transient unit has > finished? i'm super temped to instead check when the > `org.freedesktop.systemd1.Service.MainPID == 0` i think its the best idea, > but maybe you guys have one that is better. Not all processes have a main PID (i.e. Type=forking where no main process can be identified, or those where RemaiNAfterExit= is set and the service exited), hence checking that is not the best approach. But yeah, the right approach is to wait until you saw JobRemoved for the job you installed. And then wait until the unit is dead/failed again, see above. Lennart -- Lennart Poettering, Red Hat _______________________________________________ systemd-devel mailing list systemd-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/systemd-devel