shaba/systemd-stable
1
1
Fork 0
mirror of https://github.com/systemd/systemd-stable.git synced 2024-12-23 17:34:00 +03:00
Code
77ecc1aaa5
systemd-stable/test/units/testsuite-48.sh

59 lines
1.9 KiB
Bash
Raw Normal View History

core: reload cache if it's dirty when starting a UNIT_NOT_FOUND unit The time-based cache allows starting a new unit without an expensive daemon-reload, unless there was already a reference to it because of a dependency or ordering from another unit. If the cache is out of date, check again if we can load the fragment.
2020-05-08 01:26:53 +03:00
#!/usr/bin/env bash
# -*- mode: shell-script; indent-tabs-mode: nil; sh-basic-offset: 4; -*-
# ex: ts=8 sw=4 sts=4 et filetype=sh
set -ex
cat > /run/systemd/system/testservice-48.target <<EOF
[Unit]
Wants=testservice-48.service
EOF
systemctl daemon-reload
systemctl start testservice-48.target
# The filesystem on the test image, despite being ext4, seems to have a mtime
# granularity of one second, which means the manager's unit cache won't be
# marked as dirty when writing the unit file, unless we wait at least a full
# second after the previous daemon-reload.
# May 07 23:12:20 systemd-testsuite testsuite-48.sh[30]: + cat
# May 07 23:12:20 systemd-testsuite testsuite-48.sh[30]: + ls -l --full-time /etc/systemd/system/testservice-48.service
# May 07 23:12:20 systemd-testsuite testsuite-48.sh[52]: -rw-r--r-- 1 root root 50 2020-05-07 23:12:20.000000000 +0100 /
# May 07 23:12:20 systemd-testsuite testsuite-48.sh[30]: + stat -f --format=%t /etc/systemd/system/testservice-48.servic
# May 07 23:12:20 systemd-testsuite testsuite-48.sh[53]: ef53
core: store timestamps of unit load attempts When the system is under heavy load, it can happen that the unit cache is refreshed for an unrelated reason (in the test I simulate this by attempting to start a non-existing unit). The new unit is found and accounted for in the cache, but it's ignored since we are loading something else. When we actually look for it, by attempting to start it, the cache is up to date so no refresh happens, and starting fails although we have it loaded in the cache. When the unit state is set to UNIT_NOT_FOUND, mark the timestamp in u->fragment_loadtime. Then when attempting to load again we can check both if the cache itself needs a refresh, OR if it was refreshed AFTER the last failed attempt that resulted in the state being UNIT_NOT_FOUND. Update the test so that this issue reproduces more often.
2020-06-16 20:46:55 +03:00
sleep 3.1
core: reload cache if it's dirty when starting a UNIT_NOT_FOUND unit The time-based cache allows starting a new unit without an expensive daemon-reload, unless there was already a reference to it because of a dependency or ordering from another unit. If the cache is out of date, check again if we can load the fragment.
2020-05-08 01:26:53 +03:00
cat > /run/systemd/system/testservice-48.service <<EOF
[Service]
ExecStart=/bin/sleep infinity
EOF
systemctl start testservice-48.service
systemctl is-active testservice-48.service
core: store timestamps of unit load attempts When the system is under heavy load, it can happen that the unit cache is refreshed for an unrelated reason (in the test I simulate this by attempting to start a non-existing unit). The new unit is found and accounted for in the cache, but it's ignored since we are loading something else. When we actually look for it, by attempting to start it, the cache is up to date so no refresh happens, and starting fails although we have it loaded in the cache. When the unit state is set to UNIT_NOT_FOUND, mark the timestamp in u->fragment_loadtime. Then when attempting to load again we can check both if the cache itself needs a refresh, OR if it was refreshed AFTER the last failed attempt that resulted in the state being UNIT_NOT_FOUND. Update the test so that this issue reproduces more often.
2020-06-16 20:46:55 +03:00
# Stop and remove, and try again to exercise https://github.com/systemd/systemd/issues/15992
systemctl stop testservice-48.service
rm -f /run/systemd/system/testservice-48.service
systemctl daemon-reload
sleep 3.1
cat > /run/systemd/system/testservice-48.service <<EOF
[Service]
ExecStart=/bin/sleep infinity
EOF
# Start a non-existing unit first, so that the cache is reloaded for an unrelated
# reason. Starting the existing unit later should still work thanks to the check
# for the last load attempt vs cache timestamp.
systemctl start testservice-48-nonexistent.service || true
systemctl start testservice-48.service
systemctl is-active testservice-48.service
core: reload cache if it's dirty when starting a UNIT_NOT_FOUND unit The time-based cache allows starting a new unit without an expensive daemon-reload, unless there was already a reference to it because of a dependency or ordering from another unit. If the cache is out of date, check again if we can load the fragment.
2020-05-08 01:26:53 +03:00
echo OK > /testok
exit 0
Copy Permalink