shaba/systemd
1
0
Fork 0
mirror of https://github.com/systemd/systemd.git synced 2025-03-21 02:50:18 +03:00
Code
systemd/test/units/testsuite-63.service

31 lines
1.4 KiB
SYSTEMD
Raw Permalink Normal View History

tests: add spdx license header to test unit/link/network/conf files Those are all consumed by our parser, so they all support comments. I was considering whether they should have a license header at all, but in the end I decided to add it because those files are often created by copying parts of real unit files. And if the real ones have a license, then those might as well. It's easier to add it than to make an exception.
2021-10-17 18:07:22 +02:00
# SPDX-License-Identifier: LGPL-2.1-or-later
core: Check unit start rate limiting earlier 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.
2021-08-24 16:46:47 +01:00
[Unit]
Description=TEST-63-ISSUE-17433
[Service]
ExecStartPre=rm -f /failed /testok
Type=oneshot
core: Add trigger limit for path units When conditions fail on a service unit, a path unit can cause PID 1 to busy loop as it keeps trying to activate the service unit. To avoid this from happening, add a trigger limit to the path unit, identical to the trigger limit we have for socket units. Initially, let's start with a high limit and not make it configurable. If needed, we can add properties to configure the rate limit similar to the ones we have for socket units.
2021-12-17 20:01:31 +01:00
# Test that a path unit continuously triggering a service that fails condition checks eventually fails with
# the trigger-limit-hit error.
core: Check unit start rate limiting earlier 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.
2021-08-24 16:46:47 +01:00
ExecStart=rm -f /tmp/nonexistent
ExecStart=systemctl start test63.path
ExecStart=touch /tmp/test63
core: Add trigger limit for path units When conditions fail on a service unit, a path unit can cause PID 1 to busy loop as it keeps trying to activate the service unit. To avoid this from happening, add a trigger limit to the path unit, identical to the trigger limit we have for socket units. Initially, let's start with a high limit and not make it configurable. If needed, we can add properties to configure the rate limit similar to the ones we have for socket units.
2021-12-17 20:01:31 +01:00
# Make sure systemd has sufficient time to hit the trigger limit for test63.path.
core: Check unit start rate limiting earlier 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.
2021-08-24 16:46:47 +01:00
ExecStart=sleep 2
core: Add trigger limit for path units When conditions fail on a service unit, a path unit can cause PID 1 to busy loop as it keeps trying to activate the service unit. To avoid this from happening, add a trigger limit to the path unit, identical to the trigger limit we have for socket units. Initially, let's start with a high limit and not make it configurable. If needed, we can add properties to configure the rate limit similar to the ones we have for socket units.
2021-12-17 20:01:31 +01:00
ExecStart=sh -x -c 'test "$(systemctl show test63.service -P ActiveState)" = inactive'
ExecStart=sh -x -c 'test "$(systemctl show test63.service -P Result)" = success'
core: Check unit start rate limiting earlier 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.
2021-08-24 16:46:47 +01:00
ExecStart=sh -x -c 'test "$(systemctl show test63.path -P ActiveState)" = failed'
core: Add trigger limit for path units When conditions fail on a service unit, a path unit can cause PID 1 to busy loop as it keeps trying to activate the service unit. To avoid this from happening, add a trigger limit to the path unit, identical to the trigger limit we have for socket units. Initially, let's start with a high limit and not make it configurable. If needed, we can add properties to configure the rate limit similar to the ones we have for socket units.
2021-12-17 20:01:31 +01:00
ExecStart=sh -x -c 'test "$(systemctl show test63.path -P Result)" = trigger-limit-hit'
# Test that starting the service manually doesn't affect the path unit.
ExecStart=rm -f /tmp/test63
ExecStart=systemctl reset-failed
ExecStart=systemctl start test63.path
ExecStart=systemctl start test63.service
ExecStart=sh -x -c 'test "$(systemctl show test63.service -P ActiveState)" = inactive'
ExecStart=sh -x -c 'test "$(systemctl show test63.service -P Result)" = success'
ExecStart=sh -x -c 'test "$(systemctl show test63.path -P ActiveState)" = active'
ExecStart=sh -x -c 'test "$(systemctl show test63.path -P Result)" = success'
core: Check unit start rate limiting earlier 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.
2021-08-24 16:46:47 +01:00
ExecStart=sh -x -c 'echo OK >/testok'
Copy Permalink