xfs/189: systemd monitoring of /etc/fstab sucks v2022.06.05
authorDave Chinner <dchinner@redhat.com>
Fri, 3 Jun 2022 01:54:13 +0000 (11:54 +1000)
committerZorro Lang <zlang@kernel.org>
Fri, 3 Jun 2022 05:18:15 +0000 (13:18 +0800)
commit568ac9fffeb6afec03e5d6c9936617232fd7fc6d
tree5b002a859ee79701ca352284937859c237ab3243
parent01dc3329bcc08fc60c2970015c6524e76011c782
xfs/189: systemd monitoring of /etc/fstab sucks

On a recently upgraded system, xfs/189 still works just fine, but
every test run after it now gets spammed from mount/systemd
like so:

xfs/189 [not run] noattr2 mount option not supported on /dev/vdc
xfs/190 1s ... mount: (hint) your fstab has been modified, but systemd still uses
       the old version; use 'systemctl daemon-reload' to reload.
 1s
xfs/192 3s ... mount: (hint) your fstab has been modified, but systemd still uses
       the old version; use 'systemctl daemon-reload' to reload.
 2s
xfs/193 2s ... mount: (hint) your fstab has been modified, but systemd still uses
       the old version; use 'systemctl daemon-reload' to reload.
 2s
xfs/194 1s ... mount: (hint) your fstab has been modified, but systemd still uses
       the old version; use 'systemctl daemon-reload' to reload.

This is because xfs/189 modifies /etc/fstab during the test, then
restores it to it's original condition so there's nothing to update.
However, systemd is sees that the mtime of /etc/fstab has changed,
and assumes they sky has fallen and so everything must be reloaded
from scratch to silence the unnecessary "hint".

We can avoid this clumsiness by capturing the mtime of /etc/fstab
before we modify it, and restore it afterwards and that means
systemd doesn't even notice that we've being playing around with
/etc/fstab.

Signed-off-by: Dave Chinner <dchinner@redhat.com>
Reviewed-by: Darrick J. Wong <djwong@kernel.org>
Signed-off-by: Zorro Lang <zlang@kernel.org>
tests/xfs/189