shaba/systemd
1
0
Fork 0
mirror of https://github.com/systemd/systemd.git synced 2025-03-09 12:58:26 +03:00
Code
systemd/test/testsuite-63.units/test63.service

9 lines
227 B
SYSTEMD
Raw 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]
core: Propagate condition failed state to triggering units. Alternative to https://github.com/systemd/systemd/pull/20531. Whenever a service triggered by another unit fails condition checks, stop the triggering unit to prevent systemd busy looping trying to start the triggered unit.
2021-10-18 14:17:02 +02:00
ConditionPathExists=/tmp/nonexistent
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
[Service]
service: set TRIGGER_UNIT= and TRIGGER_PATH= on activation by path unit When a service is triggered by a path unit, pass the path unit name and the path that triggered it via env vars to the spawned processes. Note that this is best-effort, as there might be many triggers at the same time, but we only get woken up by one.
2022-08-02 20:07:35 +01:00
ExecStartPre=sh -c 'test "$TRIGGER_PATH" = /tmp/test63'
ExecStartPre=sh -c 'test "$TRIGGER_UNIT" = 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=true
Copy Permalink