snapd getting into EPEL as described in Snapd updates in Fedora EPEL for Enterprise Linux I’ve started some work on integrating CentOS with our spread suite.
The latest CentOS version publicly available is 7.5 at the moment, this is what is used in spread. I am using RHEL 7.6 locally for doing some extra verification.
We have run into problems related to mount namespaces and bind mounts that prevent snaps using layout or parallel installed snaps from working properly. It is possible to install the snap, however the snap cannot be removed, unless the mount namespace is discarded beforehand (i.e. one runs
sudo /usr/libexec/snapd/snap-discard-ns <snapname>).
The minimal use case that demonstrates the problem:
# 1st terminal, on the host [rhel@rhel ~]$ mkdir foo bar [rhel@rhel ~]$ ls -l total 0 drwxrwxr-x. 2 rhel rhel 6 Nov 16 12:31 bar drwxrwxr-x. 2 rhel rhel 6 Nov 16 12:31 foo
# 2nd terminal, create mount namespace, slave propagation (like s-c) [rhel@rhel ~]$ sudo unshare -m --propagation slave [sudo] password for rhel: [root@rhel rhel]# [root@rhel rhel]# ls bar foo [root@rhel rhel]# mount -o bind $PWD/foo $PWD/bar
# 1st terminal [rhel@rhel ~]$ rmdir foo [rhel@rhel ~]$ rmdir bar rmdir: failed to remove ‘bar’: Device or resource busy [rhel@rhel ~]$ sudo rmdir bar rmdir: failed to remove ‘bar’: Device or resource busy
# 2nd terminal, back in the unshared mount ns [root@rhel rhel]# cat /proc/$$/mountinfo |grep bar 209 84 253:0 /home/rhel/foo//deleted /home/rhel/bar rw,relatime - xfs /dev/mapper/rhel-root rw,seclabel,attr2,inode64,noquota
I’ve discussed the problem with @zyga and we are looking at the kernel as the main culprit here. One, within an unshared mount ns can effectively block operations in the host mount ns.
The systems this was observed on:
- RHEL 7.6 (
- CentOS 7.5 (
Newer kernels do not have this behavior and the mount goes away automatically. I have verified that the behavior is also correct on RHEL 8 beta (