LXC helper processes hide themselve in .lxc cgroup, we don't have to
deal with the inside tests (and the error in conversion to unit is handled).
Skip those but keep iterating over remaining processes to detect what
can be created around us.
cg_pidref_get_path() cannot work (current implementaion) without
cgroupfs (when it checks unified or not setup). Similarly,
cg_pidref_get_unit() assumes all processes are part of a unit. So carry
out the test only when running on a systemd setup.
The test is supposed to check a battery of cgroup helpers on each
process found but it doesn't literally check anything besides presence
of procfs. (One can visually check printed output only. Introduction in
aff38e74bd ("nspawn: suffix the nspawn cgroups with ".nspawn"").)
Make some assumptions about visible processes and turn the test into
testing that systemd helpers can deal with whatever process they find on
the SUT.
Reported by Coverity and
Fixes CID#1587767
The capsule instances are related to user instances, so treat them
equally to user@.service when handling cgroup paths. This also saves us
from polluting public libsystemd API with variant for capsules too.
Fix: #36098
inotify FD may take several milliseconds to close. We measured
daemon-reload
default: (0.427 ± 0.05) s
async: (0.323 ± 0.02) s
with 5 path units out of 422 units. I.e. ~1% of units cause ~25% of
delay, hence this fix seems like low-hanging fruit on the daemon-reload
critical path.
Particular inotify slowness pointed out by @fbuihuu.
The test expects _not_ to find the patterns but the run_and_grep would
still print 'FAIL:' message. Use the dedicated -n option that inverts
the semantics cleaner than shell's !.
Since we can evaluate even the case with invalid ids (non-matching) we
can switch the function to pure boolean with no error cases and simpler
(none) return error handling.
The commit 7419291670 ("userdb: move UserDBMatch handling from userdbctl
into generic userdb code to allow it to be done server side")
unintentionally passes return value from group_record_match() as its
return value and thus diverges from other search functions that return 0
on success. Align that by returning 0 instead of 1, all existing callers
are invariant to this change.
I'm not that familiar with outer code to guide Coverity with an
assert(), so consider invalid uid/gid as non-matching in order to avoid
-EINVAL for bit shifts calculation.
Fixes: CID#1590746
Hinted by CID#1591563 but the issue is different -- when
sd_event_source_set_destroy_callback() fails, we would use the old
n_sources value and possibly missing sd_event_source_unref() of the last
added source.
The method was added with migration of resources in mind (e.g. process's
allocated memory will follow it to the new scope), however, such a
resource migration is not in cgroup semantics. The method may thus have
the intended users and others could be guided to StartTransientUnit().
Since this API was advertised in a regular release, start the removal
with a deprecation message to callers.
Eventually, the goal is to remove the method to clean up DBus API and
simplify code (removal of cgroup_context_copy()).
Part of DBus docs is retained to satisfy build checks.
Different device paths may resolve to same device node
(lookup_block_device()), e.g.
IOReadBandwidthMax=/dev/sda1 18879
IOReadBandwidthMax=/dev/sda2 18878
where both partitions resolve to /dev/sda and when these values are
applied (they are associated with original paths, i.e. as if applied for
different device) in the order from io_device_limits.
The parsing code prepends, so they end up in reverse order wrt config
file. Switch the direction so that the order of application matches the
order of configuration -- i.e. semantics in all other unit file
directives.
Apply same change to all directives that use per-device lists. (The
question whether partitions should be resolved to base device is
independent.)
And apply the changes equally to DBus properties write handlers.
Fixes#34126
It means: a) user cannot be created, something's wrong in the
test environment -> fail the test; b) user already exists, we shall not
continue and delete (foreign) user.
This reverts commit 60d064d3fd.
The logged test failure was because of missing memory controller in
testing cgroup. With the test fixed in previous commit, memory
attributes are delegated as expected.
Ref: #32439
When the test used to be run on distro that doesn't enable memory
accounting by default (such as openSUSE TW), there is no guarantee that
testing unit has memory.* cgroup attributes and delegation test would
fail if they are missing.
Require memory controller explicitly inside the unit so that test can
work in any environment.
The method returns prematurely (before jobs it triggers terminate). This
is externally visible because other methods may fail if jobs did not
finish.
Postpone the DBus method response until we collect all signals for
finished jobs.
systemd-timedated keeps track of in-flight DBus requests and answers
them all in unspecified order when jobs finish. The capacity of requests
in systemd-timedated is limited.
Fixes: #17739
The situation is a service like
Type=notify
NotifyAccess=main
and the service uses some of the systemd helper utilities, e.g.
coredumpctl. The service process will pass NOTIFY_SOCKET to the helper
child (accidentally) and the result is a spurious notification and
the warning message:
> Jan 18 09:38:01 host systemd[1]: sdnotify.service: Got notification message from PID 13736, but reception only permitted for main PID 13549
Notification from helpers seem like an unintentional composition of the
commit c118b577fa ("coredumpctl: define main through macro") and commit
6b636c2d27 ("main-func: send main exit code to parent via sd_notify() on
exit"). The former used the handy macro for a main function, the latter
equipped any main function with the notification. (Further extended in
the commit 623a00020f ("notify: Add EXIT_STATUS field").)
Since notification from systemd utitilities are meant to extend
rudimentary exit()/wait() pair generally, they may happen to land into
service's NOTIFY_SOCKET. Tone down messages of notification that won't
match NotifyAccess=.
Global resource (whole system or root cg's (e.g. in a container)) is
also a well-defined limit for memory and tasks, take it into account
when calculating effective limits.
Users become perplexed when they run their workload in a unit with no
explicit limits configured (moreover, listing the limit property would
even show it's infinity) but they experience unexpected resource
limitation.
The memory and pid limits come as the most visible, therefore add new
unit read-only properties:
- EffectiveMemoryMax=,
- EffectiveMemoryHigh=,
- EffectiveTasksMax=.
These properties represent the most stringent limit systemd is aware of
for the given unit -- and that is typically(*) the effective value.
Implement the properties by simply traversing all parents in the
leaf-slice tree and picking the minimum value. Note that effective
limits are thus defined even for units that don't enable explicit
accounting (because of the hierarchy).
(*) The evasive case is when systemd runs in a cgroupns and cannot
reason about outer setup. Complete solution would need kernel support.
The actual default is 2^15 and that is also 32b kernels default.
Fix the value, mention 32b and do not talk about default which may
depend on nr_cpus.
Fix: #29607
Without memory accounting explicitly disabled, we may not obtain current
consumption from all units on the ancestry path.
Use a descendant value as lower bound estimate for ancestors if
ancestor's consumption cannot be directly queried.
This makes MemoryAvailable= an upper bound of available values.
unit_get_memory_available() duplicates similar logic contained in
unit_get_memory_current(). Instead, it can call it for each unit it
needs data for.
Additionally, simplify the flow by treating all units from leaf to root
uniformly in one loop.
Functional change when a queried unit does not have MemoryAccounting=yes
(or cgroup_path), we will try getting an estimate from ancestors.
Currently, querying a unit's available memory would result in infinity
if there are no limits set on the unit or ancestors.
That undermines semantics implied by the name, so look at the physical
memory if the search propagates up to the -.slice.
This makes sense even in systemd user instances, limits of -.slice are
still looked at too.
Also change printed representation of infinite MemoryAvailable which
means we could not figure out a good estimate.
Originally, the source code was copied under /root/src.
This home directory is part of root FS and the new mkosi building
paradigm has only ephemeral root FS that is generated lazily.
Any files placed on the root FS in the build environment are that
excluded from the final image.
It is useful to have source codes available in the image's runtime (not
build time) environment for debugging.
ExtraTrees= as used currently are ineffective, so change the destination
to copy files under /usr to achieve the intention.
gdb sees source files as:
> 1354 ../src/src/systemctl/systemctl.c: No such file or directory.
Modify gdb configration in the built image accordingly (that file cannot
be in /root neither) to resolve to the moved sources.
(Commit fdecbf7 ("Enable unprivileged image builds") envisions bind
mounting or virtiofsd for nspawn or qemu containers respectively.)
When mkosi is run from git-worktree(1), the .git is not a repository
directory but a textfile pointing to the real git dir
(e.g. /home/user/systemd/.git/worktrees/systemd-worktree). This git dir
is not bind mounted into build environment and it fails with:
> fatal: not a git repository: /home/user/systemd/.git/worktrees/systemd-worktree
> test/meson.build:190:16: ERROR: Command `/usr/bin/env -u GIT_WORK_TREE /usr/bin/git --git-dir=/root/src/.git ls-files ':/test/dmidecode-dumps/*.bin'` failed with status 128.
There is already a fallback to use shell globbing instead of ls-files,
use it with git worktrees as well.
Unit that requires its own mount namespace creates a temporary directory
to implement dynamic bind mounts (org.freedesktop.systemd1.Manager.BindMountUnit).
However, this directory is never removed and they will accumulate for
each unique unit (e.g. templated units of systemd-coredump@).
Attach the auxiliary runtime directory existence to lifetime of other
"runtime" only per-unit directories.
Previously mere MemoryLow= directive would lead to emitting the compat
message 'Applying MemoryMax=18446744073709551615 as MemoryLimit=' even
though it carries little information.
--recursive=no will overwrite possible -P or -k option hence making the
recursive disabling impossible.
Check what counting types the system supports (encoded in the ordering
of our enum) of and pick whatever user requests but is also supported.
Fixes: #25248
Filenames to store user linger requests are created with C-escaping.
When we enumerate the files to acquire ligering users, we use the
filenames verbatim. In the case C-escaping is not an identity map (such
as "DOMAIN\User"), we won't be able to start user instances of
such mangled users.
Unescape filenames when we treat them as usernames again.
Fixes: #25448
The lists of directives for fuzzer tests are maintained manually in the
repo. There is a tools/check-directives.sh script that runs during test
phase and reports stale directive lists.
Let's rework the script into a generator so that these directive files
are created on-the-flight and needn't be updated whenever a unit file
directives change. The scripts is rewritten in Python to get rid of gawk
dependency and each generated file is a separate meson target so that
incremental builds refresh what is just necessary (and parallelize
(negligible)).
Note: test/fuzz/fuzz-unit-file/directives-all.slice is kept since there
is not automated way to generate it (it is not covered by the check
script neither).
A single device cannot have more than a single proportional control
policy at the same time. So either io.bfq.weight or io.weight will
always fail. Process the resulting values and emit a warning message
only when none was really configured.
This patch also drops warnings when setting [blk]io.bfq.weight fails,
the code would be too convoluted otherwise.
Old kernels (795fe54c2a82 ("bfq: Add per-device weight") v5.4) won't
allow io.bfq.weight per-device configuration, don't get too excited
about it but give the user one warning message to be aware this settings
don't apply.
There are two possible IO control mechanisms (io.cost and BFQ) that
expose separate weights APIs. In systemd units we configure only a
single device weight value so we need to write it to both attribute
files.
This patch extends to devices what is already done for default cgroup IO
weight in commit 2dbc45aea7 ("cgroup: Also set io.bfq.weight"). This
is possible with kernels >= v5.4 with commit 795fe54c2a82 ("bfq: Add
per-device weight"). A warning is logged if the write fails on older kernels.
Since per-device weight of a particular device cannot use both io.cost
policy and BFQ scheduler, at least one warning is always expected with
this approach (the method that is unconfigured).
The BFQ weights are not passed verbatim to the kernel, provide that
information in a form of debug message so that users are not
surprised/confused when IOWeight != io.bfq.weight.
This reverts commit ab6df52083.
The image build failed during kernel RPM installation (bug in %post
scriptlet). This has been fixed in the package suse-module-tools 16.0.13
[1]. The fix is in openSUSE Tumbleweed repos so the tests can be enabled
again.
[1] https://github.com/openSUSE/suse-module-tools/pull/53Fixes: #21019
The unit queues are not serialized/deserialized (they are recreated
after reexec/reload instead). The destroyed units are not removed from
the cgroup_oom_queue. That means the queue may contain possibly invalid
pointers to released units.
Fix this by removing the units from cgroup_oom_queue as we do for
others. When at it, sync assert checks with currently existing queues
and put them in order in the manager cleanup code.
The current pattern '#' triggers on the openSUSE kernel version that is
printed early during boot when no actual prompt is ready
> [ 0.000000] Linux version 5.12.10-1-default (geeko@buildhost) (gcc (SUSE Linux) 11.1.1 20210510 [revision 23855a176609fe8dda6abaf2b21846b4517966eb], GNU ld (GNU Binutils; openSUSE Tumbleweed) 2.36.1.20210326-4) #1 SMP Fri Jun 11 05:05:06 UTC 2021 (b92eaf7)
Instead wait for pattern that: a) should have fewer false positives, b)
still be with working on distro shells:
openSUSE (red color)
^[[1m^[[31mimage:~ #^[[m^O
arch
[root@image ~]#
debian
root@image:~#
ubuntu
root@image:~#
fedora
[root@image ~]#
The current boot test relies on terminal login, therefore network setup
inside image is unnecessary. This opens up possibility to test images
that don't support the network setup via veth devices.
Cgroups may be unnecessarily realized when they are not needed. This
happens, e.g. for mount units parsed from /proc/$PID/mountinfo, check
touch /run/ns_mount
unshare -n sh -c "mount --bind /proc/self/ns/net /run/ns_mount"
# no cgroup exists
file /sys/fs/cgroup/system.slice/run-ns_mount.mount
systemctl daemon-reload
# the vain cgroup exists
file /sys/fs/cgroup/system.slice/run-ns_mount.mount
. (Such cgroups can account to a large number with many similar mounts.)
The code already accounts for "lazy" realization (see various checks for
Unit.cgroup_realized) but the unit_deserialize() in the reload/reexec
path performs unconditional realization.
Invalidate (and queue) the units for realization only if we know that
they were already realized in the past. This is a safe thing to do even
in the case the reload brings some new cgroup setting (controllers, BPF)
because units that aren't realized will use the updated setting when the
time for their realization comes. (It's not even needed to add a code
comment because the current formulation suggests the changed behavior.)
PID 1 will now check upfront which v1 controller hiearchies are
available and modifiable and therefore it will not attempt to touch
them. If we get an EROFS failure then, it points to another
inconsistency so we will report it again. The revert also simplifies the
code a bit.
systemd user instance assumed same controllers are available to it as to
PID 1. That is not true generally, in v1 (legacy, hybrid) we don't delegate any
controllers to anyone and in v2 (unified) we may delegate only subset of
controllers.
The user instance would fail silently when the controller cgroup cannot
be created or the controller cannot be enabled on the unified hierarchy.
The changes in 7b63961415 ("cgroup: Swap cgroup v1 deletion and
migration") caused some attempts of operating on non-delegated
controllers to be logged.
Make the user instance first check what controllers are availble to it
and narrow operations only to these controllers. The original checks are
kept in place.
Note that daemon-reexec needs to be invoked in order to update the set
of unabled controllers after a change.
Fixes: #18047Fixes: #17862
The function controller_is_accessible() doesn't do really much in case
of the unified hierarchy. Move common parts into cg_get_path_and_check
and make controller check v1 specific. This is refactoring only.
Some masks shouldn't be needed externally, so keep their functions in
the module (others would fit there too but they're used in tests) to
think twice if something would depend on them.
Drop unused function cg_attach_many_everywhere.
Use cgroup_realized instead of cgroup_path when we actually ask for
realized.
This should not cause any functional changes.
The usage in unit_get_own_mask is redundant, we only need apply
disable_mask at the end befor application, i.e. calculating enable or
target mask.
(IOW, we allow all configurations, but disabling affects effective
controls.)
Modify tests accordingly and add testing of enable mask.
This is intended as cleanup, with no effect but changing unit_dump
output.
The unit_add_siblings_to_cgroup_realize_queue does more than mere
siblings queueing, hence define a family of a unit as (immediate)
children of the unit and immediate children of all ancestors.
Working with this abstraction simplifies the queuing calls and it
shouldn't change the functionality.
Merge members mask invalidation into
unit_add_siblings_to_cgroup_realize_queue, this way unit_realize_cgroup
needn't be called with members mask invalidation.
We have to retain the members mask invalidation in unit_load -- although
active units would have cgroups (re)realized (unit_load queues for
realization), the realization would happen with potentially stale mask.
unit_free(u) realizes direct parent and invalidates members mask of all
ancestors. This isn't sufficient in v1 controller hierarchies since
siblings of the freed unit may have existed only because of the removed
unit.
We cannot be lazy about the siblings because if parent(u) is also
removed, it'd migrate and rmdir cgroups for siblings(u). However,
realized masks of siblings(u) won't reflect this change.
This was a non-issue earlier, because we weren't removing cgroup
directories properly (effectively matching the stale realized mask),
removal failed because of tasks left by missing migration (see previous
commit).
Therefore, ensure realization of all units necessary to clean up after
the free'd unit.
Fixes: #14149
When we are about to derealize a controller on v1 cgroup, we first
attempt to delete the controller cgroup and migrate afterwards. This
doesn't work in practice because populated cgroup cannot be deleted.
Furthermore, we leave out slices from migration completely, so
(un)setting a control value on them won't realize their controller
cgroup.
Rework actual realization, unit_create_cgroup() becomes
unit_update_cgroup() and make sure that controller hierarchies are
reduced when given controller cgroup ceased to be needed.
Note that with this we introduce slight deviation between v1 and v2 code
-- when a descendant unit turns off a delegated controller, we attempt
to disable it in ancestor slices. On v2 this may fail (kernel enforced,
because of child cgroups using the controller), on v1 we'll migrate
whole subtree and trim the subhierachy. (Previously, we wouldn't take
away delegated controller, however, derealization was broken anyway.)
Fixes: #14149
When we're disabling controller on a direct child of root cgroup, we
forgot to add root slice into cgroup realization queue, which prevented
proper disabling of the controller (on unified hierarchy).
The mechanism relying on "bounce from bottom and propagate up" in
unit_create_cgroup doesn't work on unified hierarchy (leaves needn't be
enabled). Drop it as we rely on the ancestors to be queued -- that's now
intentional but was artifact of combining the two patches:
cb5e3bc37d ("cgroup: Don't explicitly check for member in UNIT_BEFORE") v240~78
65f6b6bdcb ("core: fix re-realization of cgroup siblings") v245-rc1~153^2
Fixes: #14917
The current implementation is LIFO, which is a) confusing b) prevents
some ordered operations on the cgroup tree (e.g. removing children
before parents).
Fix it quickly. Current list implementation turns this from O(1) to O(n)
operation. Rework the lists later.
This fixes commit db2b8d2e28 that
rectified parsing empty values but broke parsing explicit infinity.
Intended parsing semantics will be captured in a testcase in a follow up
commit.
Ref: #16248
Currently, an empty assignment of Memory{Low,Min}= directives would be
interpretted as setting it to global default, i.e. zero. However, if we
set a runtime protection value on a unit that inherits parent's
DefaultMemory{Low,Min}=, it is not possible to revert it back to the
state where the DefaultMemory{Low,Min}= is propagated from parent
slice(s).
This patch changes the semantics of the empty assignments to explicitly
nullify any value set by the user previously. Since DBus API uses
uint64_t where 0 is a valid configuration, the patch modifies DBus API
by exploiting the variant type of property value to pass the NULL value.
When MemoryLow= or MemoryMin= is set, it is interpretted as setting the
values to infinity. This is inconsistent with the default initialization
to 0.
It'd be nice to interpret the empty assignment as fallback to
DefaultMemory* of parent slice, however, current DBus API cannot convey
such a NULL value, so stick to simply interpretting that as hard-wired
default.
Many dependencies were pulled via dracut->systemd. Since we can build
stripped images without initrd and dracut, we need to add systemd
runtime dependencies explicitely.
User accounts of given names are necessary for the build script and
tests to succeed.
(Fixup of #15527, too keen cleaning of dependencies and cached image
caused this.)
HUGE_SIZE was defined inconsistently.
> In file included from ../src/basic/alloc-util.h:9,
> from ../src/journal/test-compress.c:9:
> ../src/journal/test-compress.c: In function ‘main’:
> ../src/journal/test-compress.c:280:33: error: ‘HUGE_SIZE’ undeclared (first use in this function)
> 280 | assert_se(huge = malloc(HUGE_SIZE));
The setup is meant to run against openSUSE Tumbleweed and install
minimum packages necessary for successful build and passing tests.
To speed up incremental build an external build directory is used.
Some testcases in test-execute rely on existence of user groups with
certain gids. However, their existence is not universally granted [1].
Although the test could be skipped in their absence and give up testing
some code paths, different approach was chosen -- create dummy groups in
the testing image.
[1] See how systemd-sysusers allocates gids (e.g.
src/test/test-uid-range.c).
Distributions may be build with various configs, e.g. customized
rootprefix. It'd be unmaintanable to have specific mkosi.build for each
supported distro. Hence, make the build script flexible yet distro
oblivious.
job_compare return value is undefined in case the jobs have a loop
between them, so better make a test to make sure transaction cycle
detection catches it.
The test-engine Test2 tests the cycle detection when units a, b and d
all start at once
,-------------------after-----------------,
v |
a/start ---after---> d/start ---after---> b/start
Extend the test with Test11 that adds i.service which causes a and d
stop (by unordered Conflicts=) while starting b. Because stops precede
starts, we effectively eliminate the job cycle and all transaction jobs
should be applicable.
,-------------------after-----------------,
v |
a/stop <---after--- d/stop <---after--- b/start
. . ^
. . |
'. . . . . . . . . i/start ---after------'
When we are validating a transaction, we take into account declared
ordering between job units. However, since JOB_STOP goes always first
regardless of the ordering constraint between respective units, we may
detect some false cycles in the transaction which would not prevent the
execution though.
Use the same logic in transaction checking as we use for job execution.
The job ordering logic is spread at multiple places of the code, making
it hard to maintain and also a bit to understand. The actual execution
order of two jobs always depends on their types and the ordering
contraint between their units. Extract this logic to a new function
job_compare. The second change is simplification of the order
evaluation, JOB_STOP takes always precedence (as documented), unless two
units are both stopping, then the ordering constraint is taken into
account.
We keep a mark whether a single-shot timer was triggered in the caller's
variable initial. When such a timer elapses while we are
serializing/deserializing the inner state, we consider the timer
incorrectly as elapsed and don't trigger it later.
This patch exploits last_trigger timestamp that we already serialize,
hence we can eliminate the argument initial completely.
A reproducer for OnBootSec= timers:
cat >repro.c <<EOD
/*
* Compile: gcc repro.c -o repro
* Run: ./repro
*/
#include <errno.h>
#include <fcntl.h>
#include <stdio.h>
#include <stdlib.h>
#include <sys/stat.h>
#include <sys/types.h>
#include <time.h>
#include <unistd.h>
int main(int argc, char *argv[]) {
char command[1024];
int pause;
struct timespec now;
while (1) {
usleep(rand() % 200000); // prevent periodic repeats
clock_gettime(CLOCK_MONOTONIC, &now);
printf("%i\n", now.tv_sec);
system("rm -f $PWD/mark");
snprintf(command, 1024, "systemd-run --user --on-boot=%i --timer-property=AccuracySec=100ms "
"touch $PWD/mark", now.tv_sec + 1);
system(command);
system("systemctl --user list-timers");
pause = (1000000000 - now.tv_nsec)/1000 - 70000; // fiddle to hit the middle of reloading
usleep(pause > 0 ? pause : 0);
system("systemctl --user daemon-reload");
sync();
sleep(2);
if (open("./mark", 0) < 0)
if (errno == ENOENT) {
printf("mark file does not exist\n");
break;
}
}
return 0;
}
EOD
We add n_installed_jobs and n_failed_jobs to our inner state after
deserialization. This is fine during daemon-reexec when we start with clear
Manager (and some jobs possibly queued before deserialization), however,
daemon-reload works with the same manager and adding the values would
effectively double the counters. Reset the counters before we deserialize and
add their values again.
Similar semantics applies to {System,Runtime}MaxUse= as to
{System,Runtime}MaxFiles=, i.e. active files aren't vacuumed and the limit
is not thus strictly honored.
When a unit job finishes early (e.g. when fork(2) fails) triggered unit goes
through states
stopped->failed (or failed->failed),
in case a ExecStart= command fails unit passes through
stopped->starting->failed.
The former transition doesn't result in unit active/inactive timestamp being
updated and timer (OnUnitActiveSec= or OnUnitInactiveSec=) would use an expired
timestamp triggering immediately again (repeatedly).
This patch exploits timer's last trigger timestamp to ensure the timer isn't
triggered more frequently than OnUnitActiveSec=/OnUnitInactiveSec= period.
Steps to reproduce:
0) Create sample units:
cat >~/.config/systemd/user/looper.service <<EOD
[Service]
ExecStart=/usr/bin/sleep 2
EOD
cat >~/.config/systemd/user/looper.timer <<EOD
[Timer]
AccuracySec=5
OnUnitActiveSec=5
EOD
1) systemctl --user daemon-reload
2) systemctl --user start looper.timer
# to have first activation timestamp/sentinel
systemctl --user start looper.service
o Observe the service is being regularly triggered.
3) systemctl set-property user@$UID.service TasksMax=2
o Observe the tight looping as long as the looper.service cannot be started.
Ref: #5969
Michal Koutný