Consistently getting "No such file or directory" on OSX #136
Comments
|
Interesting. On which system (Windows, Linux, Mac OS…)? |
|
As the title suggests it’s on Mac, I haven’t tried the java version yet. Note to make is this is on the latest official release not source distrib. The DNS is an in-house company DNS so the device can connect to our internal network. I tested the setup on Windows and it was able to access fine, this issue seems to be restricted to Mac. I started the service on each of the android devices then started the relay service on the Mac which crashes consistently. Also starting it from the autorun produces the same results or only starts on one device, any attempt to connect more crashes it. |
Sorry, I missed it. 😉
The issue is probably not related to the DNS itself. According to the backtrace, I think it might be related to the Rust/mio backend for MacOS (otherwise, I think it would have happen on other platforms too). Could you try the latest versoin of Rust/mio, calling: from And also test the java version. Thank you. |
No worries! I haven't been able to test the rust update yet, but can confirm that the Java version is working as expected so I suspect it's isolated to Rust. |
|
I run into the same issue today. I switched from the rust version to the java version. This works for me 👍 |
|
Did you test v2.2.1 (released for MacOS) or v2.3 (compiled manually because not released for MacOS)? Since it seems to occur only on MacOS, I suspect a problem with the kqueue backend of Rust mio. Maybe a wrong assumption in gnirehtet which happens to be false on MacOS, or maybe a bug in mio. Anyway, if you can reproduce easily, I'm interested in the results on current master (and even results after upgrading mio to the latest version). |
|
I used the 2.2.1 version (rust) and 2.3 (java) |
|
I'm experiencing this same issue on OSX. I downloaded the gnirehtet source, rust and did a cargo update from relay-rust. After this I ran cargo run run and the problem persisted. The updated version of mio is v0.6.16 |
|
If you can reproduce, could you post the whole connection session (the output of gnirehtet) before this crash, please? |
The failure does not occur until I attempt to use the browser ion my device. |
|
Thanks. Could you apply this patch to get more info about registering/deregistering, and paste the output again, please: diff --git a/relay-rust/src/relay/tcp_connection.rs b/relay-rust/src/relay/tcp_connection.rs
index 91af24a..3533ed7 100644
--- a/relay-rust/src/relay/tcp_connection.rs
+++ b/relay-rust/src/relay/tcp_connection.rs
@@ -139,7 +139,7 @@ impl TcpConnection {
ipv4_header: Ipv4Header,
transport_header: TransportHeader,
) -> io::Result<Rc<RefCell<Self>>> {
- cx_info!(target: TAG, id, "Open");
+ cx_info!(target: TAG, &id, "Open");
let stream = Self::create_stream(&id)?;
let tcp_header = Self::tcp_header_of_transport(transport_header);
@@ -166,7 +166,7 @@ impl TcpConnection {
let interests = Ready::writable();
let rc = Rc::new(RefCell::new(Self {
self_weak: Weak::new(),
- id,
+ id: id.clone(),
client,
stream,
interests,
@@ -190,6 +190,7 @@ impl TcpConnection {
move |selector: &mut Selector, event| rc2.borrow_mut().on_ready(selector, event);
let token =
selector.register(&self_ref.stream, handler, interests, PollOpt::level())?;
+ cx_info!(target: TAG, &id, "registered {:?}", token);
self_ref.token = token;
}
Ok(rc)
@@ -783,8 +784,9 @@ impl Connection for TcpConnection {
}
fn close(&mut self, selector: &mut Selector) {
- cx_info!(target: TAG, self.id, "Close");
+ cx_info!(target: TAG, &self.id, "Close");
self.closed = true;
+ cx_info!(target: TAG, &self.id, "deregistering {:?}", self.token);
selector.deregister(&self.stream, self.token).unwrap();
// socket will be closed by RAII
} |
|
I removed some repeating lines to shorten the output: |
|
Could you try with this additional patch, as suggested here, please? diff --git a/relay-rust/src/relay/tcp_connection.rs b/relay-rust/src/relay/tcp_connection.rs
index 3533ed7..75b8b9d 100644
--- a/relay-rust/src/relay/tcp_connection.rs
+++ b/relay-rust/src/relay/tcp_connection.rs
@@ -785,6 +785,7 @@ impl Connection for TcpConnection {
fn close(&mut self, selector: &mut Selector) {
cx_info!(target: TAG, &self.id, "Close");
+ assert!(!self.closed);
self.closed = true;
cx_info!(target: TAG, &self.id, "deregistering {:?}", self.token);
selector.deregister(&self.stream, self.token).unwrap(); |
|
|
I'm getting this too. Until this gets resolved a VERY hacky work around is to just create a script to restart on failure. I was getting disconnected every few minutes which was just unbearably annoying. With this simple script running it's not even noticeable when it crashes. #!/bin/bash
until ./gnirehtet run; do
echo "gnirehtet crashed with exit code $?. Respawning.." >&2
sleep 1
doneHope this is patched soon, but in the meantime this unblocked me. Hope it can help someone else too. |
|
The bug has been confirmed in mio: tokio-rs/mio#911 |
|
The mio issue has been closed for quite a while, and I tried updating mio, but this still happens. Maybe you should reopen that issue if it's still relevant. |
|
Mio removed things used by gnirehtet: tokio-rs/mio#928
It has not been closed. |
Hmmm... gnirehtet currently uses mio 0.6, and the latest published version is 0.6.19, which should be compatible.
tokio-rs/mio#911 is closed isn't it? |
(sorry, I thought you were talking about this issue (#136)) Yes, it is closed due to the changes mio did in tokio-rs/mio#928.
I don't know which version contain their changes (maybe it's only on their |
That seems to be a breaking change, so they are required to release a minor version bump in this case, which means 0.7, which is not published yet. And I see that the PR closes tokio-rs/mio#911 is not part of 0.6.19 as well, so yeah :/ |
|
A simple workaround in gnirehtet would be to ignore the error instead of panic, there would be no consequences, since the connection is already "closed" in that case. |
rom1v
added a commit
that referenced
this issue
Sep 7, 2019
A call to selector.deregister() may (unexpectedly) fail with Rust/MIO: <#136>
|
I just did that on |
|
Thanks! |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Howdy,
I'm constantly getting a RUST error when running the relay or autorun with a DNS configuration (-d). Appears to be originating from relaylib::relay::connection::Connection::close
Logs are below:
The text was updated successfully, but these errors were encountered: