Mount resource only updated /etc/fstab, did not mount

[wdullaer]

Versions:

• mgmt version (eg: mgmt --version): 0.0.18

• operating system/distribution (eg: uname -a): Ubuntu 19.04

Description:

Trying to mount a few local ext4 filesystems updated /etc/fstab correctly, but did not mount the disks after mgmt had converged.

The mcl files was simple

file "/mnt/disk1/" {
	state => "exists",
}

mount "/mnt/disk1" {
	state => "exists",
	device => "UUID=8f3b7486-7529-4552-820c-284232c8354d",
	type => "ext4",
	options => {
		"noatime"=>"",
		"defaults"=>"",
	},

	Depend => File["/mnt/disk1/"],
}

The log contained statements like this one, which seems to indicate that the mount logic inside of mgmt did get called

17:54:48 main.go:496: gapi: lang: running interpret...
17:54:48 main.go:414: engine: mount[/mnt/disk4]: CheckApply(true)
17:54:48 main.go:414: engine: mount[/mnt/disk4]: resource: mountCheckApply(true)

[purpleidea]

As previously mentioned in IRC, here is one fix for the mount portion of that code:

8f1f5d3

It's in git master now.

If you can confirm that this did not fix the problem, then that would be helpful. If it does not, then perhaps something is wrong with our systemd mount logic.

Can you also confirm:

1. Are you running mgmt as root?
2. What is the output of systemd-mount --list and systemd-mount --version on your system?

Lastly, our logic is currently "update fstab, and poke systemd so that it sees the change and mounts it". If that is incorrect on some systems, that something we should know, so that instead of updating fstab we add systemd .mount files instead. @jonathangold any thoughts?

[emmmmygold]

It's been a while since I worked on this, but IIRC I asked the systemd-developers mailing list, and at the time, "update fstab, and poke systemd so that it sees the change and mounts it" was the officially recommended way to mount disks, both manually and programmatically. I have an Ubuntu VM I can try to reproduce this on when I get a chance (after trying on my arch install). If the local-fs.target and remote-fs.target units are being reloaded as well as the systemd daemon, I can't imagine why it wouldn't mount, unless perhaps the "wait for the systemd job to complete" is now broken.

[purpleidea]

perhaps the "wait for the systemd job to complete" is now broken

I had that thought, but I hope it is not the case. My other thought is the "systemd load from fstab mechanism" is not working.

[wdullaer]

1. Are you running mgmt as root

Yes

2. What is the output of systemd-mount --list

NODE      PATH                   MODEL                 WWN                TYPE LABEL UUID                                
/dev/sda1 pci-0000:00:14.1-ata-1 KINGSTON_SA400S37240G 0x50026b7782729481 ext4 n/a   7c31fb53-55c8-4606-8e46-501c98c45de1
/dev/sdb1 pci-0000:00:11.0-ata-1 VB0250EAVER           0x5000c5004b42c814 ext4 n/a   8f3b7486-7529-4552-820c-284232c8354d
/dev/sdc1 pci-0000:00:11.0-ata-2 SAMSUNG_HD154UI       0x50024e9003427964 ext4 Data  ba85c14c-173a-4f71-8618-8733a46af67b
/dev/sdd1 pci-0000:00:11.0-ata-3 WDC_WD30EZRX-00D8PB0  0x50014ee2b475997a ext4 n/a   f01ded31-2132-495f-9900-45eda4980e60
/dev/sde1 pci-0000:00:11.0-ata-4 WDC_WD30EZRX-00D8PB0  0x50014ee209cb1945 ext4 n/a   ac0a0d55-8263-4e1b-8912-cc7942762141

Keep in mind that I have mounted them manually in the mean time (at some point this server has to do some work)

2. What is the output of systemd-mount --version

systemd 240
+PAM +AUDIT +SELINUX +IMA +APPARMOR +SMACK +SYSVINIT +UTMP +LIBCRYPTSETUP +GCRYPT +GNUTLS +ACL +XZ +LZ4 +SECCOMP +BLKID +ELFUTILS +KMOD -IDN2 +IDN -PCRE2 default-hierarchy=hybrid

I'll try to recreate the issue here later today

[purpleidea]

My understanding is that this should be fixed now. If you can reproduce with git master, please let me know here and I can re-open, or you can open a new issue. Thanks!