vscode + rust analyzer close rustc processes on exit

[jordy25519]

Quitting vscode leaves some running rustc/cargo jobs holding a lock on the build directory.
Requires a manual kill to stop them.

Environment:

Version: 1.46.1
Commit: cd9ea6488829f560dc949a8b2fb789f3cdc05f5d
Date: 2020-06-17T21:17:14.222Z
Electron: 7.3.1
Chrome: 78.0.3904.130
Node.js: 12.8.1
V8: 7.8.279.23-electron.0
OS: Darwin x64 17.7.0

Name: rust-analyzer
Id: matklad.rust-analyzer
Description: An alternative rust language server to the RLS
Version: 0.2.232

> ~/Library/Application\ Support/Code/User/globalStorage/matklad.rust-analyzer/rust-analyzer-mac --version
rust-analyzer 8b0983e

[bjorn3]

You have to be patient for rustc to finish compiling.

[matklad]

We do kill cargo on death: https://github.com/rust-analyzer/rust-analyzer/blob/41feb816c98894d48df97193eb085738e405a3c2/crates/flycheck/src/lib.rs#L312-L316

And Cargo has some special magic to clean the whole process-group. So, not sure what's going on here, needs investigation! But I think I've seen this myself.

The expected behavior is that we promptly cleanup all processes on normal shutdown (it's OK to leave processes hanging if we are sigkilled ourselves, as properly setting up cross-platform process groups is a pain).

[oeed]

This one definitely happens for me a lot. Not sure if it's something about my setup, but I frequently have to kill cargo processes before rust-analyzer starts working in VSCode; it just hangs waiting for the file lock otherwise. Would be great to resolve.

[jak-pan]

Same here. Happens a lot. Getting crazy from this. Happy to debug. I just killed like 20 hanging cargo commands that were spun up by rust-analyzer.

EDIT: Running on OSX. This happens on 2 different machines. One is Intel based and one is ARM based.

[oeed]

@lnicola could you possibly explain the unactionable tag?

[lnicola]

@oeed I marked it as unactionable because there's no way to reproduce it, and the code, as written, shouldn't leak cargo or rustc processes, at least on Unix platforms. Even if a compiler is left running, it should finish its job then close, just as if you had ran it from the terminal.

Personally, I've never seen this happen on Linux or Windows.

[MikailBag]

Looking at cargo source documentation, I see this (cargo::utils::job):

This currently works "by default" on Unix platforms because Ctrl-C actually sends a signal to the process group rather than the parent process, so everything will get torn down.

man 2 kill tells:

If pid is positive, then signal sig is sent to the process with the ID specified by pid.
If pid equals 0, then sig is sent to every process in the process group of the calling process.
If pid equals -1, then sig is sent to every process for which the calling process has permission to send signals, except for process 1 (init), but see below. If pid is less than -1, then sig is sent to every process in the process group whose ID is -pid.

Rust-analyzer uses Child::kill method to kill cargo process. Here is Unix implementation. You can see that positive value is being passed to kill syscall, which means rustcs will not receive SIGKILL and continue running.

[matklad]

Oh, right, if we just kill cargo, it wont necessary kill the processes spawned by the cargo.

@oconnor663, can I tap into your knowledge a bit here? You are the expert on the topic: https://github.com/oconnor663/duct.py/blob/master/gotchas.md#killing-grandchild-processes :-)

So the situation is that rust-analyzer is not spawned by the shell, it's spawned by the editor (GUI vscode, teminal VIM, etc). rust-analyzer itself spawns cargo, and cargo spawns rustc.

The shutdown process for rust-analyzer is cooperative -- the client sends us a "shutdown" message, we cancel in-progress jobs, wait for them to finish, and then exit outselves.

The problem is that one of the in-progress jobs might be cargo check. At the moment, we just kill Cargo. Re-reading https://github.com/rust-lang/cargo/blob/1243c378b9a637dc4beb9b2ad7b955af3affa47e/src/cargo/util/job.rs#L1-L16, I am not sure if that's enough -- rust-analyzer is not a shell, so we don't do anything specific about process groups.

Is there anything better we can do here? Should rust-analyzer play the role of the shell and try to setup process group here? Or should we escalate this further up and say that whoever spawned rust-analyzer should also clean dependent processes? That is, that they should setup a process group? Should we just 🤷 and mark this as a won't fix?

[jak-pan]

Don't know if it helps your decision but you can specify different process to run in vscode settings (it's cargo check by default but running cargo clippy is also possible)

[MikailBag]

IMHO the simplest solution is to use pid namespaces. Although this is a Linux-only feature, I think it should be a good fit for this case.
It should be used in such a way that the rust-analyzer main process is init process inside the namespace. That way when the rust-analyzer main process exits all its children (including proc-macro server, cargo, rustc, etc) are killed by the kernel automatically.

[lnicola]

Windows also has Job Objects for this. But it's not clear to me why this is actually a problem. Doesn't rustc finish by itself in a couple of seconds? Does it hang if cargo died?

[MikailBag]

Well, I think I suffer from this problem when my laptop's RAM is overloaded with firefox, vscode, rust-analyzer, and compilation. If one of the rustc processes links binary, it can take quite a lot of time (because of swapping). I haven't measured but sometimes rustc keeps running even after a few seconds.

[lnicola]

Ah, a few seconds should be fine. I interpreted the first post as "the remaining processes never close until killed".