New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Changes in /etc/fstab are ignored #3568

Closed
jkufner opened this Issue Jun 20, 2016 · 10 comments

Comments

6 participants
@jkufner

jkufner commented Jun 20, 2016

Submission type

  • Bug report

systemd version the issue has been seen with

$ systemd --version
systemd 230
+PAM +AUDIT +SELINUX +IMA +APPARMOR +SMACK +SYSVINIT +UTMP +LIBCRYPTSETUP +GCRYPT +GNUTLS +ACL +XZ -LZ4 +SECCOMP +BLKID +ELFUTILS +KMOD -IDN

Used distribution

Debian

The Bug

My hard drive failed so i bought a new one and copied data. After the copy was finished, I changed /etc/fstab to mount new hard drive to old mount point, then unmounted old drive, mounted the new one and disconnected the broken hard drive to let it rest for a minute. Then I reconnected the old broken drive. Instantly, systemd unmounted the new drive and mounted the old broken drive, not respecting changes in /etc/fstab. I was lucky noone has been using the server and badblocks has a check to not run on mounted drives, otherwise a lot of bad things would happen.

Before mounting anything, systemd MUST check /etc/fstab for changes. It is not acceptable to cache obsolete data and use the wrong data to do wrong things automatically.

This systemd's behavior may result in significant data loss.

@evverx

This comment has been minimized.

Show comment
Hide comment
@evverx

evverx Jun 20, 2016

Member

https://www.freedesktop.org/software/systemd/man/systemd.generator.html#Examples

After editing /etc/fstab, the user should invoke systemctl daemon-reload. This will re-run all generators and cause systemd to reload units from disk. To actually mount new directories added to fstab, systemctl start /path/to/mountpoint or systemctl start local-fs.target may be used.

Did you run systemctl daemon-reload?

Member

evverx commented Jun 20, 2016

https://www.freedesktop.org/software/systemd/man/systemd.generator.html#Examples

After editing /etc/fstab, the user should invoke systemctl daemon-reload. This will re-run all generators and cause systemd to reload units from disk. To actually mount new directories added to fstab, systemctl start /path/to/mountpoint or systemctl start local-fs.target may be used.

Did you run systemctl daemon-reload?

@jkufner

This comment has been minimized.

Show comment
Hide comment
@jkufner

jkufner Jun 20, 2016

Of course not... Well... I did run that after I realized what happened.

The point is, that systemd must check /etc/fstab for changes before it mounts anything. Otherwise it can lead to dangerous situations and possible data loss.

jkufner commented Jun 20, 2016

Of course not... Well... I did run that after I realized what happened.

The point is, that systemd must check /etc/fstab for changes before it mounts anything. Otherwise it can lead to dangerous situations and possible data loss.

@arvidjaar

This comment has been minimized.

Show comment
Hide comment
@arvidjaar

arvidjaar Jun 21, 2016

Contributor

Did you run systemctl daemon-reload?

And what about all other generators that may be installed on your system by arbitrary other package? Do you imply that administrators today must know this and run daemon-reload when any file used by any of them changed?

Contributor

arvidjaar commented Jun 21, 2016

Did you run systemctl daemon-reload?

And what about all other generators that may be installed on your system by arbitrary other package? Do you imply that administrators today must know this and run daemon-reload when any file used by any of them changed?

@evverx

This comment has been minimized.

Show comment
Hide comment
@evverx

evverx Jun 21, 2016

Member

Do you imply that administrators today must know this

No, I don't.

And what about all other generators that may be installed on your system by arbitrary other package?

So, /etc/fstab-checking doesn't really make sense. Right?

Member

evverx commented Jun 21, 2016

Do you imply that administrators today must know this

No, I don't.

And what about all other generators that may be installed on your system by arbitrary other package?

So, /etc/fstab-checking doesn't really make sense. Right?

@jkufner

This comment has been minimized.

Show comment
Hide comment
@jkufner

jkufner Jun 21, 2016

@evverx No. The opposite. Other generators shoud perform similar checks too.

jkufner commented Jun 21, 2016

@evverx No. The opposite. Other generators shoud perform similar checks too.

@poettering

This comment has been minimized.

Show comment
Hide comment
@poettering

poettering Jun 21, 2016

Member

This is by really by design: configuration stays in effect until systemd's configuration is explicitly reloaded, so that incomplete changes are not read at the wrong time. THis is indeed different from classic SysV where changes made to init scripts or /etc/fstab had an immediate effect on subsequent operations on that script or mount point.

I have documented this on https://www.freedesktop.org/wiki/Software/systemd/Incompatibilities now, given that this indeed might be something to stumble over, but I am very sure systemd's behaviour in this regards is the more correct one.

Member

poettering commented Jun 21, 2016

This is by really by design: configuration stays in effect until systemd's configuration is explicitly reloaded, so that incomplete changes are not read at the wrong time. THis is indeed different from classic SysV where changes made to init scripts or /etc/fstab had an immediate effect on subsequent operations on that script or mount point.

I have documented this on https://www.freedesktop.org/wiki/Software/systemd/Incompatibilities now, given that this indeed might be something to stumble over, but I am very sure systemd's behaviour in this regards is the more correct one.

@poettering poettering closed this Jun 21, 2016

@jkufner

This comment has been minimized.

Show comment
Hide comment
@jkufner

jkufner Jun 21, 2016

So after every change in /etc we have to run systemctl daemon-reload, because there is no way of knowing whether there is a part of systemd using a changed file. And there are no safety checks to detect changed configuration and inhibit potentially dangerous automatic actions.

@poettering Btw, that Incompatibilities page is completely unreadable and very poorly structured. Some headings would help a lot.

jkufner commented Jun 21, 2016

So after every change in /etc we have to run systemctl daemon-reload, because there is no way of knowing whether there is a part of systemd using a changed file. And there are no safety checks to detect changed configuration and inhibit potentially dangerous automatic actions.

@poettering Btw, that Incompatibilities page is completely unreadable and very poorly structured. Some headings would help a lot.

@arvidjaar

This comment has been minimized.

Show comment
Hide comment
@arvidjaar

arvidjaar Jun 22, 2016

Contributor

So after every change in /etc we have to run systemctl daemon-reload

after every change (dropping /etc), exactly

because there is no way of knowing whether there is a part of systemd using a changed file.

Contributor

arvidjaar commented Jun 22, 2016

So after every change in /etc we have to run systemctl daemon-reload

after every change (dropping /etc), exactly

because there is no way of knowing whether there is a part of systemd using a changed file.

@reusch

This comment has been minimized.

Show comment
Hide comment
@reusch

reusch Jul 31, 2017

Nice to know that systemd unmounts your intentionally mounted drives.

And also interesting: Removing logical volumes and creating them in a different volume group, changing the fstab and running mount on this mountpoint leads to the situation that nothing is mounted because systemd unmounts the new one and the old one has gone and cannot bei mounted.

SysV did not read fstab all the time to mount all volumes exactly as defined in fstab. Systemd does this partly and may leave a half-complete system state by doing this (from my perspective).

Sorry for waking up sleeping dogs, though...

reusch commented Jul 31, 2017

Nice to know that systemd unmounts your intentionally mounted drives.

And also interesting: Removing logical volumes and creating them in a different volume group, changing the fstab and running mount on this mountpoint leads to the situation that nothing is mounted because systemd unmounts the new one and the old one has gone and cannot bei mounted.

SysV did not read fstab all the time to mount all volumes exactly as defined in fstab. Systemd does this partly and may leave a half-complete system state by doing this (from my perspective).

Sorry for waking up sleeping dogs, though...

@wdoekes

This comment has been minimized.

Show comment
Hide comment
@wdoekes

wdoekes May 2, 2018

Nice to know that systemd unmounts your intentionally mounted drives.

It also mounted my intentionally unmounted drive that I was supposed to be doing e2fs stuff on.

wdoekes commented May 2, 2018

Nice to know that systemd unmounts your intentionally mounted drives.

It also mounted my intentionally unmounted drive that I was supposed to be doing e2fs stuff on.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment