-
Notifications
You must be signed in to change notification settings - Fork 7
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Unclosed file descriptors on demonization #30
Comments
Do you have instructions how to build vifm with fuse-t and provide configuration instructions so I can test ? |
Vifm doesn't link against Vifm's configuration file is either
Then run |
Doesn't macFUSE behave the same way? |
Just built the same |
@alexfs This hanging can be reproduced in a simpler way. Just try to run any FUSE mount with Golang |
BTW, I confirm that this issue does NOT happen with macFUSE. |
If you have a sample code that would be great |
Assumes that you have But as I said, any other FUSE fs should also reproduce the issue. Run as root ( 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")
} |
Confirming this is fixed in 1.0.24. |
Didn't notice there was a release. It is indeed fixed. Thanks. |
I think that this issue with using
fuse-zip
built againstfuse-t
is caused byfuse-t
not closingstderr
(and maybe other descriptors) during demonization. Vifm efectively waits for data onstderr
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.The text was updated successfully, but these errors were encountered: