All of lore.kernel.org
 help / color / mirror / Atom feed
From: Dave Chinner <david@fromorbit.com>
To: fstests@vger.kernel.org
Subject: [PATCH 8/8] xfs/189: systemd monitoring of /etc/fstab sucks
Date: Thu,  2 Jun 2022 10:31:26 +1000	[thread overview]
Message-ID: <20220602003126.2903779-9-david@fromorbit.com> (raw)
In-Reply-To: <20220602003126.2903779-1-david@fromorbit.com>

From: Dave Chinner <dchinner@redhat.com>

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>
---
 tests/xfs/189 | 38 +++++++++++++++++++++++++++++++++++++-
 1 file changed, 37 insertions(+), 1 deletion(-)

diff --git a/tests/xfs/189 b/tests/xfs/189
index e601881a..6287a733 100755
--- a/tests/xfs/189
+++ b/tests/xfs/189
@@ -32,6 +32,27 @@
 #
 # <---- Normal programming is resumed ---->
 #
+# <---- Bbbzzzzzzztttt ---->
+#
+# < systemd enters the chat >
+#
+# 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.
+#
+# So now mount/systemd sees that /etc/fstab has changed (because mtime changed)
+# and so it now whines that it needs updating on every mount from this point
+# onwards. Yes, that's totally obnoxious behaviour from mount/systemd but we
+# have to work around it.
+#
+# Hence we save/restore the mtime of /etc/fstab around every modification we
+# make so that any time /etc/fstab is checked in future it won't appear to have
+# changed.
+#
+# < systemd leaves the chat >
 #
 . ./common/preamble
 _begin_fstest mount auto quick
@@ -190,31 +211,46 @@ ENDL
 # Example fstab entry
 # /dev/sdb2            /mnt/scratch1        xfs       defaults 0 0
 #
+# Note that to avoid systemd whinging about /etc/fstab being modified, we
+# need to ensure the mtime of /etc/fstab does not change across all these
+# modifications.
+#
 _add_scratch_fstab()
 {
+	local mtime="$(stat -c %y /etc/fstab)"
+
 	# comment out any existing SCRATCH_DEV
 	$SED_PROG -i "s;$SCRATCH_DEV;#$SCRATCH_DEV;" /etc/fstab
 
 	# add our fstab entry
 	echo "$SCRATCH_DEV $SCRATCH_MNT xfs defaults 0 0 # $tag" >> /etc/fstab
+
+	touch -m --date="$mtime" /etc/fstab
 }
 
 _modify_scratch_fstab()
 {
-	opts=$1
+	local opts=$1
+	local mtime="$(stat -c %y /etc/fstab)"
 
 	# modify our fstab entry that we added
 	# modify opts by looking for last word which has non-space chars
 	$SED_PROG -i "s; [^ ]* 0 0 # $tag; $opts 0 0 # $tag;" /etc/fstab
+
+	touch -m --date="$mtime" /etc/fstab
 }
 
 _putback_scratch_fstab()
 {
+	local mtime="$(stat -c %y /etc/fstab)"
+
 	# uncomment out any existing SCRATCH_DEV
 	$SED_PROG -i "s;#$SCRATCH_DEV;$SCRATCH_DEV;" /etc/fstab
 
 	# remove the one we added at the end
 	$SED_PROG -i "/# $tag/d" /etc/fstab
+
+	touch -m --date="$mtime" /etc/fstab
 }
 
 # Import common functions.
-- 
2.35.1


  parent reply	other threads:[~2022-06-02  0:31 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-06-02  0:31 fstests: new tests and various fixes Dave Chinner
2022-06-02  0:31 ` [PATCH 1/8] xfstests: Add Log Attribute Replay test Dave Chinner
2022-06-02  1:05   ` Darrick J. Wong
2022-06-03  1:41   ` [PATCH 1/8 v2] fstests: " Dave Chinner
2022-06-03  2:43     ` Darrick J. Wong
2022-06-03  4:55       ` Zorro Lang
2022-06-03  5:29         ` Dave Chinner
2022-06-02  0:31 ` [PATCH 2/8] README: document _begin_fstests better Dave Chinner
2022-06-02  0:51   ` Darrick J. Wong
2022-06-02  0:31 ` [PATCH 3/8] generic/081: don't run on DAX capable devices Dave Chinner
2022-06-02  2:03   ` Darrick J. Wong
2022-06-02  0:31 ` [PATCH 4/8] generic/038: kill background threads on interrupt Dave Chinner
2022-06-02  0:51   ` Darrick J. Wong
2022-06-02  0:31 ` [PATCH 5/8] xfs/538: fix fsstress scaling Dave Chinner
2022-06-02  0:52   ` Darrick J. Wong
2022-06-02  0:31 ` [PATCH 6/8] xfs/070: filter the bad sb magic number error Dave Chinner
2022-06-02  0:52   ` Darrick J. Wong
2022-06-02  0:31 ` [PATCH 7/8] xfs/167: adjust runtime with TIME_FACTOR Dave Chinner
2022-06-02  0:53   ` Darrick J. Wong
2022-06-02  0:31 ` Dave Chinner [this message]
2022-06-02  1:04   ` [PATCH 8/8] xfs/189: systemd monitoring of /etc/fstab sucks Darrick J. Wong
2022-06-03  1:54   ` [PATCH 8/8 v2] " Dave Chinner
2022-06-03  2:41     ` Darrick J. Wong

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20220602003126.2903779-9-david@fromorbit.com \
    --to=david@fromorbit.com \
    --cc=fstests@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.