Support oneshot services (inactive vs. failure services)

Hey @joonty, I've been digging around in the code again and wanted to propose extending functionality to address use cases that include oneshot services (a github issue seems like the best place for this discussion, let me know if it belongs elsewhere.)

To illustrate, the use case I'm thinking of would be a cron replacement using timer units and oneshot service units. Each time a timer triggers its accompanying service unit, as long as systemd doesn't see a nonzero exit code, the service unit does not go into a failure state but remains inactive (dead) (after briefly transitioning to activating.) However, for a oneshot service that does not RemainAfterExit, this is basically still a "good" state to be in - it just means the last service execution was a success (nonzero exit.)

Currently, when trying to use systemd_mon with oneshot services, I get errors about calls to first in state_change.rb.

The current state paradigm indicates that inactive is a bad state, but for oneshot services, this could actually be ok. The "important" states in the case of a oneshot would be whether ActiveState is inactive or failed.

I think the easiest way to implement this may be to pass the Type of a service unit to the State constructor and, if oneshot, alter the possible ok_states and failure_states that ActiveState can take on (I think Type is a gettable property from the unit's dbus handle.)

Does this sound like a reasonable + good idea? I'm asking before coding it up because my ruby is kind of rusty and want to confirm this would work for the way you've got the state change algorithm set up; I don't grok it fully. :smile: If so I'll throw a PR together, the aforementioned implementation doesn't seem hard, just needs to fit correctly into the current paradigm you've got going.

joonty / systemd_mon

Support oneshot services (inactive vs. failure services) #2