Would a connect() sa_family=AF_UNIX on mergerfs give a ECONNREFUSED?

[James Read]

Hey, I'm trying to use Git Annex on top of mergerfs. Git Annex is having issues when it tries to sync (merely just a git pull / git push), because the control sockets it's using are on mergerfs.

I've just strace'd it, using strace -f git annex sync, and it looks like the problem is here;

[pid 2547901] connect(4, {sa_family=AF_UNIX, sun_path=".git/annex/ssh/xconspirisist@mindstorm"}, 110 <unfinished ...>
[pid 2547904] close(5 <unfinished ...>
[pid 2547703] <... read resumed>"\1\0\0\0\0\0\0\0", 8) = 8
[pid 2547904] <... close resumed>)      = 0
[pid 2547901] <... connect resumed>)    = -1 ECONNREFUSED (Connection refused)

I'm just checking if that is expected, as I cannot see it in the mergerfs docs - it seems I can create unix sockets and FIFOs on mergerfs, but can you just confirm (or not) for me that it is mergerfs (or fuse) that is responsible for the ECONNREFUSED on the connect() call? Thanks!

[trapexit]

connect isn't a call that exists in FUSE so I'm not sure. I've not really ever messed with uds or fifos with FUSE. an strace of mergerfs would help.

[James Read]

Hey @trapexit , I did try to strace --attach to all the mergerfs pids, but I cannot understand why strace is listing lots of newfstatat()'s for irrelevant paths... Maybe something is running and indexing in the background, and strace is picking that up.

connect() is a syscall - not one that would probably show up in fuse I'd bet. I have actually managed to test using nc, and things seem to work fine with a unix domain socket on mergerfs;

shell1:

user@host: cd /mnt/myMergerfs/
user@host: nc -lU foo.sock

shell2:

user@host: cd /mnt/myMergerfs/
user@host: date | nc -U foo.sock

So, this might be something else wrong with git-annex.