On Tue, Mar 17, 2020 at 7:58 PM Chris Murphy <lists@colorremedies.com> wrote:
Alternate 1:
'must not timeout when'

Alternate 2:
'must not consistently timeout when'

I think blocking on transient unit timeouts may not be practical even
if desirable. But there remains a problem with all of these: what if
the timeout is 90s and the unit consistently takes 80s to stop? I
think that's no different than 90s and systemd just killing it off.
Some  units have 5 minute or even indefinite timeouts set. If the
criterion is hinged on the timeout being reached, then it may often
not be a blocker even if that's the intent.

That was a tradeoff I was willing to do...
 

Alternate 3:
'must not consistently hang for more than 30s when'

...but I like this one even better. The word hang implies that it's not doing anything. So if e.g. libvirt-guests.service takes 45 seconds to save the state of all your VMs, that's not hanging (and it will not occur when you have no VMs running, so this is easy to distinguish). If the filesystem needs to be synced, that's not hanging (and if you sync before reboot, it will not happen, easy to distinguish). The word consistently is also important, it will not apply to e.g. cups.service or packagekit.service acting up once per 30 reboots. But if cups.service hangs each time you print a document, that's consistent, and now we need to determine whether it's serious enough to block the release. This was the reason why I also included frequently in the original proposal - I think there should be a judgement call when it doesn't occur every single time. If it is consistent but infrequent (e.g. each time you print), it might not be a good idea to block on it. Although, I guess I should've used and instead of or, i.e. "frequently and consistently".