IF YOU WOULD LIKE TO GET AN ACCOUNT, please write an
email to Administrator. User accounts are meant only to access repo
and report issues and/or generate pull requests.
This is a purpose-specific Git hosting for
BaseALT
projects. Thank you for your understanding!
Только зарегистрированные пользователи имеют доступ к сервису!
Для получения аккаунта, обратитесь к администратору.
Otherwise we might never hit the trigger limit and wait indefinitely.
Found when trying to run the test on an EC2 xen machine without a nested
virt in CentOS CI (in preparations for some ... unforseseen consequences).
(cherry picked from commit 0f1f5629747011d0401730ce81c955ec1d430e3d)
since in that case we might be also slow enough to miss the rate-limit
window. However, let's not set the trigger limit unconditionally to
still have coverage for the unaltered path unit (but without sacrificing
CI stability).
See: https://github.com/systemd/systemd/pull/21808#issuecomment-998927401
Fixes#17433. Currently, if any of the validations we do before we
check start rate limiting fail, we can still enter a busy loop as
no rate limiting gets applied. A common occurence of this scenario
is path units triggering a service that fails a condition check.
To fix the issue, we simply move up start rate limiting checks to
be the first thing we do when starting a unit. To achieve this,
we add a new method to the unit vtable and implement it for the
relevant unit types so that we can do the start rate limit checks
earlier on.