diff options
| author | Zbigniew Jędrzejewski-Szmek <zbyszek@in.waw.pl> | 2020-08-28 12:21:48 +0200 |
|---|---|---|
| committer | Zbigniew Jędrzejewski-Szmek <zbyszek@in.waw.pl> | 2020-08-31 20:53:38 +0200 |
| commit | c2911d48ff0fc61fb3cfab7050110992a7390417 (patch) | |
| tree | 49523b56178301d3ef75b875947aa8f2d76513dd /test/testsuite-10.units | |
| parent | core: always try to reload not-found unit (diff) | |
| download | systemd-c2911d48ff0fc61fb3cfab7050110992a7390417.tar.xz systemd-c2911d48ff0fc61fb3cfab7050110992a7390417.zip | |
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.
Diffstat (limited to 'test/testsuite-10.units')
0 files changed, 0 insertions, 0 deletions