mirror of
https://github.com/systemd/systemd-stable.git
synced 2024-12-24 21:34:08 +03:00
9727f2427f
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.
17 lines
683 B
Desktop File
17 lines
683 B
Desktop File
[Unit]
|
|
Description=TEST-63-ISSUE-17433
|
|
|
|
[Service]
|
|
ExecStartPre=rm -f /failed /testok
|
|
Type=oneshot
|
|
ExecStart=rm -f /tmp/nonexistent
|
|
ExecStart=systemctl start test63.path
|
|
ExecStart=touch /tmp/test63
|
|
# Make sure systemd has sufficient time to hit the start limit for test63.service.
|
|
ExecStart=sleep 2
|
|
ExecStart=sh -x -c 'test "$(systemctl show test63.service -P ActiveState)" = failed'
|
|
ExecStart=sh -x -c 'test "$(systemctl show test63.service -P Result)" = start-limit-hit'
|
|
ExecStart=sh -x -c 'test "$(systemctl show test63.path -P ActiveState)" = failed'
|
|
ExecStart=sh -x -c 'test "$(systemctl show test63.path -P Result)" = unit-start-limit-hit'
|
|
ExecStart=sh -x -c 'echo OK >/testok'
|