systemd/test/units/testsuite-63.service

# SPDX-License-Identifier: LGPL-2.1-or-later
[Unit]
Description=TEST-63-PATH

[Service]
ExecStartPre=rm -f /failed /testok
ExecStart=/usr/lib/systemd/tests/testdata/units/%N.sh
Type=oneshot
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]`
test-63: convert to full shell script and generalize Will add more path unit tests later 2022-08-03 16:50:39 +01:00			`Description=TEST-63-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
			`[Service]`
			`ExecStartPre=rm -f /failed /testok`
test-63: convert to full shell script and generalize Will add more path unit tests later 2022-08-03 16:50:39 +01:00			`ExecStart=/usr/lib/systemd/tests/testdata/units/%N.sh`
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			`Type=oneshot`