Created attachment 981599 [details] /proc/mounts Description of problem: I guess since I made /var/lib/mock a symlink to a non-root filesystem I am getting thousands mounts in /proc/mounts which I cannot umount. I do not want to discuss how I created such system state. But IMO I should be able to unmount all the directories, shouldn't I? Only if you have some hint for debugging, thanks. Version-Release number of selected component (if applicable): util-linux-2.25.2-2.fc21.x86_64 kernel-core-3.17.8-300.fc21.x86_64 How reproducible: In one day with my cron-run scripts. Steps to Reproduce: No easy reproducer for such mounts. I have various scripts around mock, particularly http://git.jankratochvil.net/?p=nethome.git;a=blob;f=bin/mocksetup which sets up the mock chroot --bind mounts similarly to what mock does. cat /proc/mounts |awk '{print $2}'|grep mock|wc -l umount `cat /proc/mounts |awk '{print $2}'|grep mock` cat /proc/mounts |awk '{print $2}'|grep mock|wc -l Actual results: 572 umount: /hdd/var/lib/mock/fedora-rawhide-x86_64/root/hdd: not mounted umount: /export/root/hdd/var/lib/mock/fedora-rawhide-x86_64/root/hdd: not mounted umount: /hdd/var/lib/mock/fedora-rawhide-i386/root/hdd: not mounted [...] umount: /hdd/var/lib/mock/fedora-21-x86_64/root/hdd/var/lib/mock/fedora-20-i386/root/hdd: mountpoint not found umount: /hdd/var/lib/mock/fedora-20-i386/root/hdd: not mounted umount: /export/root/hdd/var/lib/mock/fedora-rawhide-x86_64/root/hdd: not mounted 572 - errors "not mounted" and "mountpoint not found" are present there Expected results: 572 (if anything) <no errors> 0 Additional info: dr-xr-xr-x. 6 root root 4096 /hdd/ lrwxrwxrwx 1 root root 22 /var/lib/mock -> ../../hdd/var/lib/mock/ /etc/fstab: /dev/mapper/luks-[...] /hdd ext4 defaults,x-systemd.device-timeout=0 1 2 /hdd /export/root/hdd none bind,noauto 0 0 - but it is mounted http://git.jankratochvil.net/?p=nethome.git;a=blob;f=bin/mocksetup
> errors "not mounted" and "mountpoint not found" are present there sounds like mount(2) syscall returns ENOENT and EINVAL. It's usually enough to call "strace -e umount umount /mountpoint" to see that syscall is called with correct arguments. Or you can try LIBMOUNT_DEBUG=0xffff umount /mountpoint to get more verbose output. BTW, if you have the same directory (e.g. /hdd) in sources and targets column in fstab, then it's more robust to use --source or --target on mount(8) command line to be more explicit -- by default mount(8) looks for mountpoint (target) and then for device (source).
18778: libmount: CXT: [0x7f4c9c3ee120]: do umount 18778: libmount: CXT: [0x7f4c9c3ee120]: umount(2) [target='/hdd/var/lib/mock/fedora-20-i386/root/hdd', flags=0x00000000] 18778: libmount: CXT: [0x7f4c9c3ee120]: umount(2) failed [errno=22] umount: /hdd/var/lib/mock/fedora-20-i386/root/hdd: not mounted umount("/hdd/var/lib/mock/fedora-20-i386/root/hdd", 0) = -1 EINVAL (Invalid argument) /proc/self/mountinfo: 3216 77 253:2 / /hdd/var/lib/mock/fedora-20-i386/root/hdd rw,relatime shared:31 - ext4 /dev/mapper/luks-28e0d1d7-c2b6-4c67-8b32-2efa2824011c rw,stripe=256,data=ordered I think I should make it --make-private or so? I will investigate more. But that should be the default. So maybe it is still a kernel bug.
Created attachment 981897 [details] /proc/self/mountinfo after mount --make-rprivate / After: mount --make-rprivate / I now have /proc/self/mountinfo: 3216 77 253:2 / /hdd/var/lib/mock/fedora-20-i386/root/hdd rw,relatime - ext4 /dev/mapper/luks-28e0d1d7-c2b6-4c67-8b32-2efa2824011c rw,stripe=256,data=ordered There is no 'shared:' anywhere anymore. Still all the errors are the same.
'mount --make-rprivate /' since system boot does not help. But I found that something like mount -text4 /dev/sdX /mnt1 sleep 1h >/mnt1/file & mount --bind /mnt1 /mnt2 umount /mnt2 ### here it fails with 'mountpoint not found' or 'not mounted' But so far I am unable to create a reproducer, reproducibility is somehow related to mock/chroot.
*********** MASS BUG UPDATE ************** We apologize for the inconvenience. There are a large number of bugs to go through and several of them have gone stale. Due to this, we are doing a mass bug update across all of the Fedora 21 kernel bugs. Fedora 21 has now been rebased to 3.18.3-201.fc21. Please test this kernel update (or newer) and let us know if you issue has been resolved or if it is still present with the newer kernel. If you experience different issues, please open a new bug report for those.
Problem got fixed by mount --make-rslave / in rc.local. But I have no idea why.
*********** MASS BUG UPDATE ************** We apologize for the inconvenience. There is a large number of bugs to go through and several of them have gone stale. Due to this, we are doing a mass bug update across all of the Fedora 21 kernel bugs. Fedora 21 has now been rebased to 3.19.5-200.fc21. Please test this kernel update (or newer) and let us know if you issue has been resolved or if it is still present with the newer kernel. If you have moved on to Fedora 22, and are still experiencing this issue, please change the version to Fedora 22. If you experience different issues, please open a new bug report for those.
kernel-4.1.4-100.fc21.x86_64 # wc -c /proc/mounts 589623115 /proc/mounts
This message is a reminder that Fedora 21 is nearing its end of life. Approximately 4 (four) weeks from now Fedora will stop maintaining and issuing updates for Fedora 21. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a Fedora 'version' of '21'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora 21 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior this bug is closed as described in the policy above. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete.
kernel-4.2.6-300.fc23.x86_64
*********** MASS BUG UPDATE ************** We apologize for the inconvenience. There is a large number of bugs to go through and several of them have gone stale. Due to this, we are doing a mass bug update across all of the Fedora 23 kernel bugs. Fedora 23 has now been rebased to 4.7.4-100.fc23. Please test this kernel update (or newer) and let us know if you issue has been resolved or if it is still present with the newer kernel. If you have moved on to Fedora 24 or 25, and are still experiencing this issue, please change the version to Fedora 24 or 25. If you experience different issues, please open a new bug report for those.
kernel-4.6.4-301.fc24.x86_64 still was FAILing. kernel-4.7.3-200.fc24.x86_64 is running now and I do not know the result yet.
kernel-4.8.14-300.fc25.x86_64 is still FAILing # wc /proc/mounts 2606788 15640728 954524007 /proc/mounts
*********** MASS BUG UPDATE ************** We apologize for the inconvenience. There is a large number of bugs to go through and several of them have gone stale. Due to this, we are doing a mass bug update across all of the Fedora 25 kernel bugs. Fedora 25 has now been rebased to 4.10.9-200.fc25. Please test this kernel update (or newer) and let us know if you issue has been resolved or if it is still present with the newer kernel. If you have moved on to Fedora 26, and are still experiencing this issue, please change the version to Fedora 26. If you experience different issues, please open a new bug report for those.
*********** MASS BUG UPDATE ************** This bug is being closed with INSUFFICIENT_DATA as there has not been a response in 2 weeks. If you are still experiencing this issue, please reopen and attach the relevant data from the latest kernel you are running and any data that might have been requested previously.