mount fs sub dir to other new mountpoint. mergerfs will exit when umount -f new mountpoint .

[pj520]

Describe the bug

mount fs sub dir to other new mountpoint. mergerfs will exit when umount -f new mountpoint .

To Reproduce

1. mount -o bind /tmp/zfuse/path/path/ /root/path/
2. umount -f /root/path/
3. df -h

df: /tmp/fuse: Transport endpoint is not connected
df: /tmp/fuse: Transport endpoint is not connected

Expected behavior

System information:

• OS, kernel version: uname -a

 Linux  4.19.206 #41 SMP Fri Mar 11 14:14:03 CST 2022 aarch64 GNU/Linux

• mergerfs version: mergerfs -V

mergerfs version: 6e9fc77-dirty
FUSE library version: 2.9.7-mergerfs_2.30.0
fusermount version: 2.9.9
using FUSE kernel interface version 7.31

• mergerfs settings

rw
use_ino
inodecalc=devino-hash
fsname=mergerfs
cache.files=partial
dropcacheonclose=true
allow_other
category.create=mfs
category.search=newest
cache.attr=0

• List of drives, filesystems, & sizes:
  • df -h

/dev/sdb3       1.8T   23M  1.8T    1% /data_2
/dev/sda3       1.8T   22M  1.8T    1% /data_1
mergerfs        3.6T   45M  3.6T    1% /tmp/zfuse

• lsblk -f

NAME         MAJ:MIN RM  SIZE RO TYPE  MOUNTPOINT
sda            8:0    0  1.8T  0 disk
├─sda1         8:1    0    4G  0 part
│ └─md0        9:0    0    4G  0 raid1 [SWAP]
├─sda2         8:2    0   20G  0 part
│ └─md1        9:1    0   20G  0 raid1 /srp
└─sda3         8:3    0  1.8T  0 part  /data_2
sdb            8:16   0  1.8T  0 disk
├─sdb1         8:17   0    4G  0 part
│ └─md0        9:0    0    4G  0 raid1 [SWAP]
├─sdb2         8:18   0   20G  0 part
│ └─md1        9:1    0   20G  0 raid1 /srp
└─sdb3         8:19   0  1.8T  0 part  /data_1

• A strace of the application having a problem:
  • strace -fvTtt -s 256 -o /tmp/app.strace.txt <cmd>
  • strace -fvTtt -s 256 -o /tmp/app.strace.txt -p <appPID>
• strace of mergerfs while app tried to do it's thing:
  • strace -fvTtt -s 256 -p <mergerfsPID> -o /tmp/mergerfs.strace.txt

Additional context

[trapexit]

I'd never run into this but this isn't a bug it appears. At least not one with mergerfs. mergerfs is receiving realtime signal 32 when umount -f is used on that bind. Same happens with sshfs and I'm guessing any other fuse mount.

I'm not sure if I can catch the signal. I'd need to check. But I'd be concerned about doing so as it seems to be a "die now" kind of thing. I would have to ask the FUSE maintainers about this specific situation to comment further.