summaryrefslogtreecommitdiff
path: root/test/TEST-48-START-STOP-NO-RELOAD
diff options
context:
space:
mode:
authorLuca Boccassi <luca.boccassi@microsoft.com>2020-06-16 18:46:55 +0100
committerZbigniew Jędrzejewski-Szmek <zbyszek@in.waw.pl>2020-06-30 16:50:00 +0200
commit7233e91af000b539c1724996758528af6d6dcc36 (patch)
treea62b8ffc410cf0c3afc2a979077b745f3592d134 /test/TEST-48-START-STOP-NO-RELOAD
parentf93dd4b9402bb71fbe6a1ccb6763a1bc46c4177c (diff)
downloadsystemd-7233e91af000b539c1724996758528af6d6dcc36.tar.gz
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.
Diffstat (limited to 'test/TEST-48-START-STOP-NO-RELOAD')
-rw-r--r--test/TEST-48-START-STOP-NO-RELOAD/blacklist-ubuntu-ci0
1 files changed, 0 insertions, 0 deletions
diff --git a/test/TEST-48-START-STOP-NO-RELOAD/blacklist-ubuntu-ci b/test/TEST-48-START-STOP-NO-RELOAD/blacklist-ubuntu-ci
deleted file mode 100644
index e69de29bb2..0000000000
--- a/test/TEST-48-START-STOP-NO-RELOAD/blacklist-ubuntu-ci
+++ /dev/null