Timeline for How to automatically reload daemons after `/etc/fstab` was changed?
Current License: CC BY-SA 4.0
6 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Oct 22 at 13:35 | comment | added | Marcus Müller | (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!) | |
| Oct 22 at 12:40 | comment | added | Marcus Müller | 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. | |
| Oct 22 at 11:52 | comment | added | Rainer Glaschick | 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. | |
| Oct 22 at 11:02 | comment | added | Marcus Müller |
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?
|
|
| Oct 22 at 9:26 | comment | added | Rainer Glaschick |
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.
|
|
| Oct 21 at 15:41 | history | answered | Marcus Müller | CC BY-SA 4.0 |