]> git.ipfire.org Git - thirdparty/systemd.git/commit - src/core/unit.h
Rework how we cache mtime to figure out if units changed 16885/head
authorZbigniew Jędrzejewski-Szmek <zbyszek@in.waw.pl>
Fri, 28 Aug 2020 10:21:48 +0000 (12:21 +0200)
committerZbigniew Jędrzejewski-Szmek <zbyszek@in.waw.pl>
Mon, 31 Aug 2020 18:53:38 +0000 (20:53 +0200)
commitc2911d48ff0fc61fb3cfab7050110992a7390417
tree49523b56178301d3ef75b875947aa8f2d76513dd
parent02103e57162946b5ac620c552123ff5e305a2791
Rework how we cache mtime to figure out if units changed

Instead of assuming that more-recently modified directories have higher mtime,
just look for any mtime changes, up or down. Since we don't want to remember
individual mtimes, hash them to obtain a single value.

This should help us behave properly in the case when the time jumps backwards
during boot: various files might have mtimes that in the future, but we won't
care. This fixes the following scenario:

We have /etc/systemd/system with T1. T1 is initially far in the past.
We have /run/systemd/generator with time T2.
The time is adjusted backwards, so T2 will be always in the future for a while.
Now the user writes new files to /etc/systemd/system, and T1 is updated to T1'.
Nevertheless, T1 < T1' << T2.
We would consider our cache to be up-to-date, falsely.
src/basic/siphash24.h
src/core/load-fragment.c
src/core/manager.c
src/core/manager.h
src/core/unit.c
src/core/unit.h
src/shared/unit-file.c
src/shared/unit-file.h