On Wed, Mar 18, 2020 at 2:08 AM Kamil Paral <kparal(a)redhat.com> wrote:
On Tue, Mar 17, 2020 at 7:58 PM Chris Murphy <lists(a)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".
I have no objection to using frequently. A frequent occurrence happens
less often than a consistent occurrence, so there may be more wiggle
room using frequently.
--
Chris Murphy