Skip to content
New issue

Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? # to your account

Unclosed file descriptors on demonization #30

Closed
xaizek opened this issue Jul 9, 2023 · 10 comments
Closed

Unclosed file descriptors on demonization #30

xaizek opened this issue Jul 9, 2023 · 10 comments

Comments

@xaizek
Copy link

xaizek commented Jul 9, 2023

I think that this issue with using fuse-zip built against fuse-t is caused by fuse-t not closing stderr (and maybe other descriptors) during demonization. Vifm efectively waits for data on stderr from a zombie, so the likely explanation is that zombie's child keeps the descriptor open. So please verify how you demonize and fix it if my guess is right.

@alexfs
Copy link

alexfs commented Jul 10, 2023

Do you have instructions how to build vifm with fuse-t and provide configuration instructions so I can test ?

@xaizek
Copy link
Author

xaizek commented Jul 10, 2023

Vifm doesn't link against fuse-t. It just invokes fuse-zip and waits for it to finish by reading its error stream. The issue manifests with v0.13, earlier versions just appended somethinig like 2>/tmp/fuse.err to FUSE mount command.

Vifm's configuration file is either ~/.config/vifm/vifmrc if ~/.config exists (assuming $XDG_DATA_HOME isn't set) or in ~/.vifm/vifmrc. You only need one line (put it at the top):

filetype *.zip FUSE_MOUNT|fuse-zip %SOURCE_FILE %DESTINATION_DIR

Then run vifm --select path/to/some.zip and press Enter, this should invoke fuse-zip to mount the file and enter mount point on success or hang until you kill fuse-zip. Quit Vifm with :q<Enter>.

@slonopotamus
Copy link

Doesn't macFUSE behave the same way?

@xaizek
Copy link
Author

xaizek commented Jul 10, 2023

Doesn't macFUSE behave the same way?

Just built the same fuse-zip (dropping the top commit) against macFUSE and it works well, while fuse-t version hangs.

@slonopotamus
Copy link

slonopotamus commented Jul 10, 2023

@alexfs This hanging can be reproduced in a simpler way. Just try to run any FUSE mount with Golang exec.Command using CombinedOutput(). You'll observe that it hangs waiting on unclosed I/O streams. If you need, I can provide a complete repro code. And the issue is not specific to fuse-zip, I'm observing the same behaviour with bindfs.

@slonopotamus
Copy link

BTW, I confirm that this issue does NOT happen with macFUSE.

@macos-fuse-t
Copy link
Owner

If you have a sample code that would be great

@slonopotamus
Copy link

slonopotamus commented Jul 10, 2023

Assumes that you have bindfs in PATH. Build instructions: mpartel/bindfs#100 (comment)

But as I said, any other FUSE fs should also reproduce the issue.

Run as root (sudo is ok):

package main

import (
	"fmt"
	"os"
	"os/exec"
)

func main() {
	_ = os.Mkdir("a", 755)
	_ = os.Mkdir("b", 755)

	cmd := exec.Command("bindfs", "a", "b")
	out, err := cmd.CombinedOutput() // hangs with fuse-t reading from stdout/stderr, but exits normally with macFUSE
	if err != nil {
		fmt.Printf("%s: %v", string(out), err)
		panic(err)
	}
	println("done")
}

@slonopotamus
Copy link

Confirming this is fixed in 1.0.24.

@xaizek
Copy link
Author

xaizek commented Jul 13, 2023

Didn't notice there was a release. It is indeed fixed. Thanks.

@xaizek xaizek closed this as completed Jul 13, 2023
# for free to join this conversation on GitHub. Already have an account? # to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants