]> git.ipfire.org Git - thirdparty/systemd.git/commit
pid1: use the cache mtime not clock to "mark" load attempts
authorZbigniew Jędrzejewski-Szmek <zbyszek@in.waw.pl>
Fri, 28 Aug 2020 09:19:38 +0000 (11:19 +0200)
committerZbigniew Jędrzejewski-Szmek <zbyszek@in.waw.pl>
Tue, 1 Sep 2020 15:27:22 +0000 (17:27 +0200)
commit8ae22f0d64006dfe8dd4738a48198019ec9bd2c5
treef35c8c8fa9a8f331f2b2d24d32189496fb4d8a78
parent715507c2772272a285a2f14c9bd7f7a734cdc518
pid1: use the cache mtime not clock to "mark" load attempts

We really only care if the cache has been reloaded between the time when we
last attempted to load this unit and now. So instead of recording the actual
time we try to load the unit, just store the timestamp of the cache. This has
the advantage that we'll notice if the cache mtime jumps forward or backward.

Also rename fragment_loadtime to fragment_not_found_time. It only gets set when
we failed to load the unit and the old name was suggesting it is always set.

In https://bugzilla.redhat.com/show_bug.cgi?id=1871327
(and most likely https://bugzilla.redhat.com/show_bug.cgi?id=1867930
and most likely https://bugzilla.redhat.com/show_bug.cgi?id=1872068) we try
to load a non-existent unit over and over from transaction_add_job_and_dependencies().
My understanding is that the clock was in the future during inital boot,
so cache_mtime is always in the future (since we don't touch the fs after initial boot),
so no matter how many times we try to load the unit and set
fragment_loadtime / fragment_not_found_time, it is always higher than cache_mtime,
so manager_unit_cache_should_retry_load() always returns true.

(cherry picked from commit c149d2b49128700a2ae361f43b9065b51c174838)
src/core/manager.c
src/core/unit.c
src/core/unit.h