Rust analyzer and nohup?

I can't say for sure there was a sighup sent by node, but I found an instance of rust-analyzer-linux running(D) as a direct descendant of systemd(1). This was not a zombie process, it readily accepted a sigterm and exited.

You can set sigterm to be sent on parent death prctl(PR_SET_PDEATHSIG, SIGTERM).

The expected behavior for rust-analyzer is to exit when either of these happens:

  • the client sends the exit request, as per LSP protocol
  • the stdin file descriptor is closed

I think this in theory should be enough (modulo bugs in our implementation).

the stdin file descriptor is closed
This happens automatically when a process exits(for any/all FDs). It's impossible for another or remote process to close a FD. If you mean something regarding the FD on the other end of a pipe attached to stdin... That's NOT sigpipe as you might assume.
I don't know how to tell when "a" writing end of a pipe has closed and I think it's folly to rely on that for an exit condition.

Sorry, I was sloppy with my wording, "the stdin file descriptor is closed" means "when read from stdin returns EOF", that is, when the other side is closed.

I don't know how to tell when "a" writing end of a pipe has closed and I think it's folly to rely on that for an exit condition.

I believe pipes follow the usual channel API, where a read from a pipe with no readers returns an EOF condition:

https://man7.org/linux/man-pages/man7/pipe.7.html

If all file descriptors referring to the write end of a pipe have been closed, then an attempt to read(2) from the pipe will see end- of-file (read(2) will return 0).

I think what's happening to me then is that read() isn't being called due to an oom or low mem condition. If rust-analyzer-linux is meant to rely on probing for determining when to exit, then the probes should be forced to occur on a regular basis. Could the following log be related?

In the one case where I found rust-analyzer-linux, it could have been being held up for several minuets. The terminal wasn't responsive during this time, taking about 12 seconds per command line... When/where I was able to repeatedly ps and pstree finding a disowned rust-analyzer-linux, that I was also able to kill.

[ERROR rust_analyzer::main_loop] overly long loop turn: 2.362940407s
[ERROR rust_analyzer::main_loop] overly long loop turn: 347.882928ms
[ERROR rust_analyzer::main_loop] overly long loop turn: 4.210308515s
[ERROR rust_analyzer::main_loop] overly long loop turn: 122.404753ms
[ERROR rust_analyzer::main_loop] overly long loop turn: 102.341225ms
[ERROR rust_analyzer::main_loop] overly long loop turn: 279.3014ms
[ERROR rust_analyzer::main_loop] overly long loop turn: 1.556707591s
[ERROR rust_analyzer::main_loop] overly long loop turn: 344.489318ms
[ERROR rust_analyzer::main_loop] overly long loop turn: 314.285546ms
[ERROR rust_analyzer::main_loop] overly long loop turn: 720.361331ms
[ERROR rust_analyzer::main_loop] overly long loop turn: 452.804049ms
[ERROR rust_analyzer::main_loop] overly long loop turn: 2.170068899s
[ERROR rust_analyzer::main_loop] overly long loop turn: 159.275621ms
[ERROR rust_analyzer::main_loop] overly long loop turn: 301.075022ms

This topic was automatically closed 90 days after the last reply. We invite you to open a new topic if you have further questions or comments.