On Wed, Mar 18, 2020 at 2:08 AM Kamil Paral <kparal@xxxxxxxxxx> wrote: > > On Tue, Mar 17, 2020 at 7:58 PM Chris Murphy <lists@xxxxxxxxxxxxxxxxx> 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 _______________________________________________ test mailing list -- test@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to test-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/test@xxxxxxxxxxxxxxxxxxxxxxx
