Rename UnitStates.unhealthy to UnitStates.unavailable / UnitStates.inactive.

[pzmarzly]

Looking at UnitStates:

pub struct UnitStates {
    pub active_state: SystemdUnitActiveState,
    pub load_state: SystemdUnitLoadState,
    // Unhealthy is only calculated for SystemdUnitLoadState::loaded units based on !SystemdActiveState::active
    // and !SystemdUnitLoadState::masked
    pub unhealthy: bool,
    // Time in microseconds since the unit state has changed ...
    // Expensive to lookup, so config disable available - Use optional to show that
    pub time_in_state_usecs: Option<u64>,
}

I don't think that units that aren't active should automatically be called "unhealthy". They can be activating/deactivating, which says nothing about their health (unless they are stuck in that state for longer, but that's what time_in_state_usecs is for). In fact, for almost every program that chooses to handle SIGTERM on its own, deactivating state is to be expected.

A more accurate name for this field, in my opinion, would be unavailable or inactive. What do you think?

[pzmarzly]

Or is this nomenclature coming from systemd itself?

[cooperlees]

No, this is a made up thing between bunn and I, I don't think the term as come from systemd definitions etc. etc. I happy to put more thought into this.

The goal was a simple "am I up and running" doing what I should be doing or not. I argue if we're activating/deactivating we're not doing our expected job, so we are "unhealthy"

• But I also do also agree it can be misleading here ...

We could possibly use time_in_state_usecs + activation/deactivation states maybe ...

• But tuning this is hard ... as you say, it differs between service ... Thus why we made this simple ...
  • It also makes monitord do more each run, which has been a priority to make it as cheap/dumb as possible ...

Playing with this is going to open up lots of edge cases and fun I feel but I'm all for ideas ...