mitsuhiko / systemfd

Development helper utility for helping with auto reloading for projects supporting systemd socket activation
Apache License 2.0
468 stars 17 forks source link

What I'v found on an error "fd 3 is not a socket" #4

Closed liuchong closed 1 year ago

liuchong commented 5 years ago

when I run a command with my very simple tool cargo-x "cargo x reload", which reload was set to

systemfd --no-pid -s http::3000 -- cargo watch -x "run --bin server_dev"

I found an error

thread 'main' panicked at 'called `Result::unwrap()` on an `Err` value: Custom { kind: InvalidInput, error: StringError("fd 3 is not a socket") }', libcore/result.rs:1009:5
note: Run with `RUST_BACKTRACE=1` for a backtrace.

I've made a test, create a shell script systemfd.sh with commands and chmod +x

#!/bin/bash
cd $(dirname $(readlink -f $0))
systemfd --no-pid -s http::3000 -- cargo watch -x "run --bin server_dev"

then run command

cd ~/.cargo/bin && ln -s path/to/my-project/systemfd.sh cargo-systemfd.sh

after this, run two command

#1 
cargo-systemfd.sh
#2 
cargo systemfd.sh

the first command run successfully, while the second one failed with the same error message I've found in the beginning.

Above is what I've found, could you please help me to check if something wrong I made? Thanks a lot!

nothingnesses commented 5 years ago

I can confirm that I also encounter this issue.

Reproduction

$ cargo new --bin foo

then edit the Cargo.toml and main.rs (the latter of which is the example from https://github.com/mitsuhiko/systemfd/blob/692f6fddd54d1bae2beb4b3bc25755e4dc93971c/README.md):

Cargo.toml (click to expand) ``` toml [package] name = "foo" version = "0.1.0" authors = ["VoidNoire "] edition = "2018" [dependencies] actix-web = "0.7" listenfd = "0.3" ```
main.rs (click to expand) ``` rust use listenfd::ListenFd; use actix_web::{server, App, Path}; fn index(info: Path<(String, u32)>) -> String { format!("Hello {}! id:{}", info.0, info.1) } fn main() { let mut listenfd = ListenFd::from_env(); let mut server = server::new( || App::new() .resource("/{name}/{id}/index.html", |r| r.with(index))); server = if let Some(listener) = listenfd.take_tcp_listener(0).unwrap() { server.listen(listener) } else { server.bind("127.0.0.1:3000").unwrap() }; server.run(); } ```
$ cd foo
$ export RUST_BACKTRACE=1 && systemfd --no-pid -s http::3000 -- cargo watch -x "run"

Output

(Click to expand) ``` ~> socket http://127.0.0.1:3000/ [Running 'cargo run'] Finished dev [unoptimized + debuginfo] target(s) in 0.68s Running `target/debug/foo` thread 'main' panicked at 'called `Result::unwrap()` on an `Err` value: Custom { kind: InvalidInput, error: StringError("fd 3 is not a socket") }', src/libcore/result.rs:997:5 stack backtrace: 0: std::sys::unix::backtrace::tracing::imp::unwind_backtrace at src/libstd/sys/unix/backtrace/tracing/gcc_s.rs:39 1: std::sys_common::backtrace::_print at src/libstd/sys_common/backtrace.rs:70 2: std::panicking::default_hook::{{closure}} at src/libstd/sys_common/backtrace.rs:58 at src/libstd/panicking.rs:200 3: std::panicking::default_hook at src/libstd/panicking.rs:215 4: std::panicking::rust_panic_with_hook at src/libstd/panicking.rs:478 5: std::panicking::continue_panic_fmt at src/libstd/panicking.rs:385 6: rust_begin_unwind at src/libstd/panicking.rs:312 7: core::panicking::panic_fmt at src/libcore/panicking.rs:85 8: core::result::unwrap_failed at /rustc/fc50f328b0353b285421b8ff5d4100966387a997/src/libcore/macros.rs:17 9: >::unwrap at /rustc/fc50f328b0353b285421b8ff5d4100966387a997/src/libcore/result.rs:798 10: foo::main at src/main.rs:13 11: std::rt::lang_start::{{closure}} at /rustc/fc50f328b0353b285421b8ff5d4100966387a997/src/libstd/rt.rs:64 12: std::panicking::try::do_call at src/libstd/rt.rs:49 at src/libstd/panicking.rs:297 13: __rust_maybe_catch_panic at src/libpanic_unwind/lib.rs:87 14: std::rt::lang_start_internal at src/libstd/panicking.rs:276 at src/libstd/panic.rs:388 at src/libstd/rt.rs:48 15: std::rt::lang_start at /rustc/fc50f328b0353b285421b8ff5d4100966387a997/src/libstd/rt.rs:64 16: main 17: __libc_start_main at ../csu/libc-start.c:308 18: _start at ../sysdeps/x86_64/start.S:120 [Finished running. Exit status: 101] ```

System information

(Click to expand) ``` $ uname --all Linux a 4.19.36_1 #1 SMP PREEMPT Sat Apr 20 19:49:40 UTC 2019 x86_64 GNU/Linux $ rustc --version rustc 1.34.1 (fc50f328b 2019-04-24) $ systemfd --version systemfd 0.3.0 ```

Other information

I get pretty much the same output when I use the example from https://github.com/actix/actix-website/blob/a52fa2fd2a892776d7c1e08360e032b7fc3f6fa6/content/docs/autoreload.md:

main.rs (click to expand) ``` rust extern crate actix_web; extern crate listenfd; use listenfd::ListenFd; use actix_web::{server, App, HttpRequest, Responder}; fn index(_req: &HttpRequest) -> impl Responder { "Hello World!" } fn main() { let mut listenfd = ListenFd::from_env(); let mut server = server::new(|| { App::new() .resource("/", |r| r.f(index)) }); server = if let Some(l) = listenfd.take_tcp_listener(0).unwrap() { server.listen(l) } else { server.bind("127.0.0.1:3000").unwrap() }; server.run(); } ```
output (click to expand) ``` $ export RUST_BACKTRACE=1 && systemfd --no-pid -s http::3000 -- cargo watch -x "run" ~> socket http://127.0.0.1:3000/ [Running 'cargo run'] Finished dev [unoptimized + debuginfo] target(s) in 0.63s Running `target/debug/foo` thread 'main' panicked at 'called `Result::unwrap()` on an `Err` value: Custom { kind: InvalidInput, error: StringError("fd 3 is not a socket") }', src/libcore/result.rs:997:5 stack backtrace: 0: std::sys::unix::backtrace::tracing::imp::unwind_backtrace at src/libstd/sys/unix/backtrace/tracing/gcc_s.rs:39 1: std::sys_common::backtrace::_print at src/libstd/sys_common/backtrace.rs:70 2: std::panicking::default_hook::{{closure}} at src/libstd/sys_common/backtrace.rs:58 at src/libstd/panicking.rs:200 3: std::panicking::default_hook at src/libstd/panicking.rs:215 4: std::panicking::rust_panic_with_hook at src/libstd/panicking.rs:478 5: std::panicking::continue_panic_fmt at src/libstd/panicking.rs:385 6: rust_begin_unwind at src/libstd/panicking.rs:312 7: core::panicking::panic_fmt at src/libcore/panicking.rs:85 8: core::result::unwrap_failed at /rustc/fc50f328b0353b285421b8ff5d4100966387a997/src/libcore/macros.rs:17 9: >::unwrap at /rustc/fc50f328b0353b285421b8ff5d4100966387a997/src/libcore/result.rs:798 10: foo::main at src/main.rs:18 11: std::rt::lang_start::{{closure}} at /rustc/fc50f328b0353b285421b8ff5d4100966387a997/src/libstd/rt.rs:64 12: std::panicking::try::do_call at src/libstd/rt.rs:49 at src/libstd/panicking.rs:297 13: __rust_maybe_catch_panic at src/libpanic_unwind/lib.rs:87 14: std::rt::lang_start_internal at src/libstd/panicking.rs:276 at src/libstd/panic.rs:388 at src/libstd/rt.rs:48 15: std::rt::lang_start at /rustc/fc50f328b0353b285421b8ff5d4100966387a997/src/libstd/rt.rs:64 16: main 17: __libc_start_main at ../csu/libc-start.c:308 18: _start at ../sysdeps/x86_64/start.S:120 [Finished running. Exit status: 101] ```

On the other hand, successful compilation occurs when systemfd is not used (this is also true with the example from https://github.com/mitsuhiko/systemfd/blob/692f6fddd54d1bae2beb4b3bc25755e4dc93971c/README.md):

output (click to expand) ``` $ export RUST_BACKTRACE=1 && cargo watch -x "run" [Running 'cargo run'] Finished dev [unoptimized + debuginfo] target(s) in 0.63s Running `target/debug/foo` ```
hronro commented 4 years ago

Got same error here, using macOS.

And I finally fixed this by add the sudo:

sudo systemfd --no-pid -s 'http::3000' -- cargo watch -x run

Hope that helps.

PS: Does this has to be runned with the root permission?

hcgaron commented 3 years ago

I want to say I've also been experiencing this issue. I'm on Ubuntu 18.04. In fact, I've been using this for my dev setup for months and it was working great.

Recently I set up my vscode debugger and now this error has been happening.

What's even more odd... it only happens in the VSCode integrated terminal. If I use my normal terminal, everything works fine. And it started out of the blue... rendering my integrated terminal useless now.

joprice commented 3 years ago

I see this issue when I try to use two sockets. Using a single socket works fine.

tv42 commented 3 years ago

I don't see anywhere in systemfd where it would actually arrange the socket fds to start from SD_LISTEN_FDS_START=3. On some runs, it gets

socket(AF_INET, SOCK_STREAM, IPPROTO_IP) = 3

and works, on some runs it gets

socket(AF_INET, SOCK_STREAM, IPPROTO_IP) = 6

and then fd 3 is whatever random junk it is.