5

Whenever /etc/fstab has changed, and one then calls mount, the following message arrives:

mount: (hint) your fstab has been modified, but systemd still uses
       the old version; use 'systemctl daemon-reload' to reload.

What are the consequences if this is not done?

Why is it not done automatically? (Because the edit may not be finished?)

Should I create a script vifstab similar to visudo? And is there a script to check /etc/fstab?

Improve this question
2
  • Great question - this has 'bugged me' for years now. My "solution" was to add a job to my crontab that ran systemctl daemon-reload every hour. Commented Oct 21 at 22:39
  • open-edit-save-check "crap". open-edit-save-check "crap". open-edit-save-check "finally" commit. That commit is the systemctl daemon-reload -- it allows the various systemd scripts that mount/unmount things access to the updates all-at-once, instead of potentially updating them with the "crap" instances, or even a correct-but-incomplete transaction. Commented Oct 23 at 2:36

2 Answers 2

Reset to default
6

What are the consequences if this is not done?

systemd won’t be aware of the changes; whether that’s important or not depends on the nature of the changes. systemd provides a number of generators which process /etc/fstab, whatever they generate may be out-of-date after changing /etc/fstab.

Why not automatically? (because the edit may not be finished?)

Because mount could be run from a context where reloading the systemd configuration would not be appropriate (for example, from a unit).

Should I create a script vifstab similar to visudo; and is there a script to check /etc/fstab?

You could! findmnt will report parsing errors; if you want to check /etc/fstab itself, you can run findmnt --fstab (or findmnt -s), and you can check arbitrary files using -F. This only checks the general format of fstab-style files however; it won’t identify errors involving incorrect device names, file system types, or file system options, and won’t complain about non-existant mount points etc.

Improve this answer
7
  • I got tired of this incessant warning from systemd (even when I had made no changes to /etc/fstab); I simply added a job in my crontab to run the prescriptive command hourly. It's stopped systemd from whining, but yr answer leaves me with questions re my "solution"... Commented Oct 21 at 22:46
  • 2
    It’s not a warning from systemd, it’s from mount itself — it’s also not supposed to be systemd-specific, but the way it’s phrased does suggest it is. Anyway regarding your main point, reloading the configuration hourly could indeed lead to surprises if you’re making changes at the wrong moment. Commented Oct 22 at 5:18
  • What sort of changes? ... and it seems you're suggesting that there is no (fail safe) solution to preclude the warning?? Commented Oct 22 at 5:39
  • 1
    For example if you make changes to related units, in multiple files, and the reload happens in the middle, you’ll end up potentially reloading an inconsistent configuration. I think the best way to go about this is some sort of vifstab that reloads the configuration after editing /etc/fstab, similar to visudo or vipw (although the main purpose of those is to check the modifications, not reload configuration). Commented Oct 22 at 7:20
  • Good hint to use findmnt with options, even if it is not yet clear for me what is checked with which option. Commented Oct 22 at 9:31
4

What are the consequences if this is not done?

That depends a bit on what's in there. But, for example, if you added (or changed) an entry that would lead to a directory being automatically mounted on usage, systemd wouldn't know about that, and the automount wouldn't work.

Improve this answer
5
  • So it seems clear that automount via systemd is the reason (never used it). Hopefully restarting deamons should report errors; thus a function to check via mount and then reload the daemons would be ok. Commented Oct 22 at 9:26
  • 1
    ah not quite, systemd units can depend on files on mounts for activation, and them not being detected can also affect your system's functionality. Restarting demons will usually not report errors. What's the downside of running systemd daemon-reload that you want to avoid? Commented Oct 22 at 11:02
  • If it is uncritical, it could have be done by whatever mechanism automatically. This warning was probably added in reaction of a problem report, and I hoped for more details. Thank you for giving them. Commented Oct 22 at 11:52
  • no, that's a logical fallacy. Just because it's not done by mount automatically doesn't mean you shouldn't do it yourself. Please do it yourself, as mount recommends you do. Commented Oct 22 at 12:40
  • 1
    (it's not critical in your situation. If this was during an installation and the daemon would be reloading just automatically, that could be catastrophic. It's not a common task to have to change /etc/fstab manually at all, and thus, not automating steps after assuming that the user that did the modification probably is doing something more complicated is pretty reasonable!) Commented Oct 22 at 13:35

You must log in to answer this question.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.