Closed mh-cbon closed 2 years ago
FTR, while looking again, I noticed too, i had left an undesired context.Background()
in my code.
In torln, err := torSocket(context.Background(), config.Tor)
,
passing the ctx
variable, like in torln, err := torSocket(ctx, config.Tor)
did not change the behavior.
Maybe it is related to github.com/ipsn/go-libtor
? no idea sorry..
Hurrah... I should have tested before w/t libtor
... It is the culprit.
Though, when I tried the embedded process, it failed with cgo
error.
[mh-cbon@Host-001 bootstrap]$ go run .
# github.com/cretz/bine/process/embedded/tor-0.3.5
../../.gvm/pkgsets/go1.19/global/pkg/mod/github.com/cretz/bine@v0.2.0/process/embedded/tor-0.3.5/process.go:35:10: fatal error: tor_api.h: No such file or directory
35 | #include <tor_api.h>
| ^~~~~~~~~~~
compilation terminated.
I guess I am missing the header files, no such tor-devel
package found... that's all unfortunate.
Only when using the non embedded process it all worked fine and smoothly.
Hi,
A small issue here regarding the signal capture and exit sequence.
Upon receiving the interrupt signal, i can see the Tor process handles it (there is a log line, and the onion respond with 0xF2). But the Go program, it is not notified, an additional signal is required to get it done.
I also tried to wait, in the hope some timeout would occur, but no luck.
I am a bit concerned by this behavior in the perspective of a service setup (but maybe I should not).
Some logs and data, stripped for clarity.
System
The Program output
In that log i waited like 5 minutes before giving up.
My code is super boring, I have a small func, which mostly copy paste your examples, with a small wrapper, and some calling code relying on the stdlib to capture the signal and a context to wait on.
The caller code is like