4a1f92c704aad80e9fde3f3d1678a5e5e944ae47 added '!' through confusion:
the goal was probably to exclude those directories from cleanup at
runtime. But as discussed below, that exclusion is not needed. In fact,
we want the rule to be active during runtime, so that if the directory
were removed or wasn't created earlier for whatever reason, it'd be
created during one of those later runs too. This just makes the system
more robust.
Those directories are used for sockets, and tmpfiles will not remove
live sockets. So it is fine to run the cleanup on those directories,
it doesn't have any effect in normal circumstances. The only case where
the cleanup would matter would be if the service was running, crashed
without removing the socket, and the system would remain up for more
than 10 days after that. This is not a particularly likely scenario, but
OTOH, we can imaging that somebody tried to run Xorg, it didn't work,
and they switched to Wayland. Or their DE crashes every once in a while,
leaving some state behind. Keeping the cleanup in place seems OK, it
makes the system slightly more robust in fringe scenarios.
In fact, this cleanup will work better if we reduce the delay from
10 days to something small. systemd-tmpfiles-clean.timer runs once
per day, so the cleanup will not be very fast anyway. So use '1h' as
an arbitrary small value. (I think '0' would be risky, because it's
possible for the socket to be set up through a script where it's
created first and the service is connected to it, so it is momentarily
"not live". I think people used to do this. Not sure if that happens
anymore, but let's be safe.)
Co-authored-by: Jarl Gullberg <jarl.gullberg@visar-systems.com>
projects / thirdparty / systemd.git / commitdiff
