[opensuse] Some weirdness re systemd and mount (42.2)
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, in the process of setting up my new miniserver, I bumped into a curios situation. Two days ago I copied several files from the old server, one of them, some entries from fstab. One, was this: /dev/mapper/cr_hoard2 /data/hoard xfs nofail,noatime 0 3 LABEL=old_d_tmpry /data/waterhoard xfs user,relatime,exec,nofail 1 3 Then I noticed that systemd was trying to mount them and complaining about some dependency not found re mounting the disks - obviously, as they were not yet connected, I needed a new usb3 enclosure instead of the old usb2. No big deal, just some log noise. I simply commented out the line: #/dev/mapper/cr_hoard2 /data/hoard xfs nofail,noatime 0 3 #LABEL=old_d_tmpry /data/waterhoard xfs user,relatime,exec,nofail 1 3 Well, today I assembled the two disks and connected them. Both went online as soon as each was powered up, despite the line in fstab being deactivated! No, I don't mean mounted somewhere in /media via the desktop. No. They were mounted in the places that figured in the fstab file! Seems things are getting worse in this respect in 42.2 than in 13.1 :-( (the password for the encrypted disk is in a file on the encrypted home partition, so that part was not a surprise) - -- Cheers Carlos E. R. (from 13.1 x86_64 "Bottle" at Telcontar) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) iEYEARECAAYFAlg/V/QACgkQtTMYHG2NR9VNJgCcDNYbBD3sl2JTdRr5+V7uBLvl HVoAnjBBEkaQwNwDreujqGZN5EZhQvPg =kkZ1 -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
01.12.2016 01:51, Carlos E. R. пишет:
Hi,
in the process of setting up my new miniserver, I bumped into a curios situation. Two days ago I copied several files from the old server, one of them, some entries from fstab. One, was this:
/dev/mapper/cr_hoard2 /data/hoard xfs nofail,noatime 0 3 LABEL=old_d_tmpry /data/waterhoard xfs user,relatime,exec,nofail 1 3
Then I noticed that systemd was trying to mount them and complaining about some dependency not found re mounting the disks - obviously, as they were not yet connected, I needed a new usb3 enclosure instead of the old usb2.
No big deal, just some log noise. I simply commented out the line:
#/dev/mapper/cr_hoard2 /data/hoard xfs nofail,noatime 0 3 #LABEL=old_d_tmpry /data/waterhoard xfs user,relatime,exec,nofail 1 3
Well, today I assembled the two disks and connected them. Both went online as soon as each was powered up, despite the line in fstab being deactivated!
/etc/fstab is read once when systemd is started. Editing it after that has no effect unless you reload systemd (systemctl daemon-reload) and even then previous units may be carried over.
No, I don't mean mounted somewhere in /media via the desktop. No. They were mounted in the places that figured in the fstab file!
When systemd creates mount unit from /etc/fstab line with "auto" option, it adds Wants dependency from device to mount unit. Which means that as soon as device appears (is announced by udev) systemd tries to start mount unit.
Seems things are getting worse in this respect in 42.2 than in 13.1 :-(
Well, systemd author believes it's a feature. If you can find arguments to convince him in the contrary ... I could not. Workaround is to create mount units manually, without this dependency.
(the password for the encrypted disk is in a file on the encrypted home partition, so that part was not a surprise)
Could you send me output of systemctl show '*'
On 2016-12-01 04:29, Andrei Borzenkov wrote:
01.12.2016 01:51, Carlos E. R. пишет:
Well, today I assembled the two disks and connected them. Both went online as soon as each was powered up, despite the line in fstab being deactivated!
/etc/fstab is read once when systemd is started. Editing it after that has no effect unless you reload systemd (systemctl daemon-reload) and even then previous units may be carried over.
:-(
No, I don't mean mounted somewhere in /media via the desktop. No. They were mounted in the places that figured in the fstab file!
When systemd creates mount unit from /etc/fstab line with "auto" option, it adds Wants dependency from device to mount unit. Which means that as soon as device appears (is announced by udev) systemd tries to start mount unit.
Yes, I know that... but I did not expect "removed" lines in fstab to not be honored.
Seems things are getting worse in this respect in 42.2 than in 13.1 :-(
Well, systemd author believes it's a feature. If you can find arguments to convince him in the contrary ... I could not.
:-/
Workaround is to create mount units manually, without this dependency.
Sigh. I'll have to learn one day.
(the password for the encrypted disk is in a file on the encrypted home partition, so that part was not a surprise)
Could you send me output of
systemctl show '*'
Sure, but it has 9832 lines. Better I email that direct to you. -- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" at Telcontar)
01.12.2016 07:05, Carlos E. R. пишет:
(the password for the encrypted disk is in a file on the encrypted home partition, so that part was not a surprise)
Could you send me output of
systemctl show '*'
Sure, but it has 9832 lines. Better I email that direct to you.
Id=systemd-cryptsetup@cr_hoard2.service WantedBy=dev-disk-by\x5cx2duuid-24f77e79\x5cx2d947e\x5cx2d4025\x5cx2d8d71\x5cx2d5816411e669d.device What is device with UUID 24f77e79-947e-4025-8d71-5816411e669d? But anyway, this is the same pattern. Device actively pulls in cryptsetup. P.S. apparently we also have double escaping but it's another issue.
On 2016-12-01 05:14, Andrei Borzenkov wrote:
01.12.2016 07:05, Carlos E. R. пишет:
(the password for the encrypted disk is in a file on the encrypted home partition, so that part was not a surprise)
Could you send me output of
systemctl show '*'
Sure, but it has 9832 lines. Better I email that direct to you.
Id=systemd-cryptsetup@cr_hoard2.service WantedBy=dev-disk-by\x5cx2duuid-24f77e79\x5cx2d947e\x5cx2d4025\x5cx2d8d71\x5cx2d5816411e669d.device
What is device with UUID 24f77e79-947e-4025-8d71-5816411e669d?
Isengard:~ # l /dev/disk/by-uuid/ | grep 24f77e79-947e-4025-8d71-5816411e669d lrwxrwxrwx 1 root root 10 Nov 30 22:36 24f77e79-947e-4025-8d71-5816411e669d -> ../../sdb1 Isengard:~ # Yes, that's my encrypted disk.
But anyway, this is the same pattern. Device actively pulls in cryptsetup.
Yes, if the intention is to mount those entries listed in fstab at boot time, but anytime the device appears, it certainly does so. The disk is encrypted and has an entry in /etc/crypttab, so it is no surprise that it also mounts it: cr_hoard2 /dev/disk/by-uuid/24f77e79-947e-4025-8d71-5816411e669d /home/cer/Keys/the_hoard_keyfile auto See? That's the uuid. As soon as it appears, it creates the corresponding devmapper device, which in turns triggers its mount. So, it works as intended, but not as /I/ intended. ;-)
P.S. apparently we also have double escaping but it's another issue.
Well... -- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" at Telcontar)
On 11/30/2016 10:29 PM, Andrei Borzenkov wrote:
/etc/fstab is read once when systemd is started. Editing it after that has no effect unless you reload systemd (systemctl daemon-reload) and even then previous units may be carried over.
Hmmm. It occurs to me that what systemd actually does is run a converter that generated unit files for each mount . I see they are in /run/systemd/generator/ Oh, and I see that the generator also produces dependencies in /run/systemd/generator/local-fs.target.requires Take a look on your own system and see what you have :-) So if you edit /etc/fstab you will need to get the generator re-run, as Andrei says, by restarting systemd. HOWEVER I see no reason that the old mount files will be deleted. Perhaps this constituents a bug? What do the systemd experts think? -- A: Yes. > Q: Are you sure? >> A: Because it reverses the logical flow of conversation. >>> Q: Why is top posting frowned upon? -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On Thu, Dec 01, 2016 at 08:48:53AM -0500, Anton Aylward wrote:
On 11/30/2016 10:29 PM, Andrei Borzenkov wrote:
/etc/fstab is read once when systemd is started. Editing it after that has no effect unless you reload systemd (systemctl daemon-reload) and even then previous units may be carried over.
Hmmm. It occurs to me that what systemd actually does is run a converter that generated unit files for each mount .
I see they are in /run/systemd/generator/
Oh, and I see that the generator also produces dependencies in /run/systemd/generator/local-fs.target.requires
Take a look on your own system and see what you have :-)
So if you edit /etc/fstab you will need to get the generator re-run, as Andrei says, by restarting systemd.
HOWEVER I see no reason that the old mount files will be deleted.
Perhaps this constituents a bug? What do the systemd experts think?
Maybe systemctl list-units shows you all units even those which to not exist on disk nor ramdisk Werner -- "Having a smoking section in a restaurant is like having a peeing section in a swimming pool." -- Edward Burr
On 2016-12-01 14:48, Anton Aylward wrote:
On 11/30/2016 10:29 PM, Andrei Borzenkov wrote:
/etc/fstab is read once when systemd is started. Editing it after that has no effect unless you reload systemd (systemctl daemon-reload) and even then previous units may be carried over.
Hmmm. It occurs to me that what systemd actually does is run a converter that generated unit files for each mount .
I see they are in /run/systemd/generator/
Oh, and I see that the generator also produces dependencies in /run/systemd/generator/local-fs.target.requires
Take a look on your own system and see what you have :-)
Well, now the comments are removed in fstab, so at this point I can't check the difference.
So if you edit /etc/fstab you will need to get the generator re-run, as Andrei says, by restarting systemd.
It seems so.
HOWEVER I see no reason that the old mount files will be deleted.
Perhaps this constituents a bug? What do the systemd experts think?
It appears to be intentional, so bug reports are ignored. -- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" at Telcontar)
On 2016-12-01 14:48, Anton Aylward wrote:
On 11/30/2016 10:29 PM, Andrei Borzenkov wrote:
/etc/fstab is read once when systemd is started. Editing it after that has no effect unless you reload systemd (systemctl daemon-reload) and even then previous units may be carried over.
Hmmm. It occurs to me that what systemd actually does is run a converter that generated unit files for each mount .
I see they are in /run/systemd/generator/
Oh, and I see that the generator also produces dependencies in /run/systemd/generator/local-fs.target.requires
Take a look on your own system and see what you have :-)
So if you edit /etc/fstab you will need to get the generator re-run, as Andrei says, by restarting systemd.
HOWEVER I see no reason that the old mount files will be deleted.
Perhaps this constituents a bug? What do the systemd experts think?
Apparently it is intentional :-( -- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" at Telcontar)
Andrei Borzenkov wrote:
01.12.2016 01:51, Carlos E. R. пишет:
/etc/fstab is read once when systemd is started. Editing it after that has no effect unless you reload systemd (systemctl daemon-reload) and even then previous units may be carried over.
---- So they only way to get it to respect a new run-time change to fstab, is to restart systemd, which forces a reboot of the machine to ensure a new copy of systemd? It also sounds like /etc/fstab has become "/etc/fsinittab", in practice, and that a new file-system mount table, "/etc/fsruntab", needs to be created to restore the original usage and intent of /etc/fstab?
Seems things are getting worse in this respect in 42.2 than in 13.1 :-(
Well, systemd author believes it's a feature. If you can find arguments to convince him in the contrary ... I could not.
Lovely. Still reminds me of the M5 computer evolving beyond its original purpose. Still seems like this is emphasizing the need for a new run-time-fstab... ;-( It's a bit worrisome how things continue to change in lack of a roadmap. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 2016-12-01 20:55, L A Walsh wrote:
Andrei Borzenkov wrote:
01.12.2016 01:51, Carlos E. R. пишет:
/etc/fstab is read once when systemd is started. Editing it after that has no effect unless you reload systemd (systemctl daemon-reload) and even then previous units may be carried over.
---- So they only way to get it to respect a new run-time change to fstab, is to restart systemd, which forces a reboot of the machine to ensure a new copy of systemd?
No no, no reboot. Just try "systemctl daemon-reload". With caveats. -- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" at Telcontar)
participants (5)
-
Andrei Borzenkov -
Anton Aylward -
Carlos E. R. -
Dr. Werner Fink -
L A Walsh