SIGINT can't terminate subprocess on OS X

[cissusnar]

$ ps -ef   
501 38117 24809   0  7:00下午 ttys001    0:00.01 cargo run
501 38118 38117   0  7:00下午 ttys001    0:00.08 target/debug/myproj

$ kill -SIGINT 38117

$ ps -ef 
501 38118     1   0  7:00下午 ttys001    0:00.08 target/debug/myproj

'cargo run' process is terminated, but it's subprocess is still running.

$ cargo --version
cargo 0.15.0-nightly (298a012 2016-12-20)

$ rustc --version
rustc 1.14.0 (e8a012324 2016-12-16)

$ uname -a
Darwin localhost.local 16.3.0 Darwin Kernel Version 16.3.0: Thu Nov 17 20:23:58 PST 2016; root:xnu-3789.31.2~1/RELEASE_X86_64 x86_64

CTRL+C can terminate cargo process and it's subprocess.

[KalitaAlexey]

@cissusnar, add that it terminates by pressing CTRL+C.

[alexcrichton]

Thanks for the report! This is currently expected behavior, as Cargo doesn't proxy signals to the child. This has changed recently on Unix where Cargo will exec the child, so signals are proxied automatically, however, so closing.

[KalitaAlexey]

@alexcrichton,
I don't understand.
Could you provide more details?
Why cargo run is terminated on Unix, but isn't on MacOS?

[alexcrichton]

@KalitaAlexey On Unix (including OSX) Cargo will use the exec syscall for cargo run. This means that the Cargo process itself is just replaced by the target executable. That was merged relatively recently, though, so it may not be in all releases of Rust.

If you find it's not terminated on OSX, I'd verify that you've got a recent version of Cargo with that PR in it. Otherwise you'll need to use the old (and more reliable) strategy of sending signals to the process group, not individual processes.

[KalitaAlexey]

@alexcrichton,
@cissusnar has cargo 0.15.0-nightly (298a012 2016-12-20).
It is recent, isn't it?
So if I understood right cargo run should terminate on OSX, but it doesn't.

[alexcrichton]

Yes that Cargo should include #2818. Are you using rustup perchance? If so you may be seeing rust-lang/rustup#806

[KalitaAlexey]

I can't understand how a problem with cargo run may be caused by rustup.
Can you explain it please?

[alexcrichton]

Can you confirm whether rustup is being used?

Rustup is a process wrapper that doesn't exec. The cargo run killed in the logs above could be rustup, not Cargo.

[KalitaAlexey]

You mean cargo to be a simlink to rustup, don't you?

[KalitaAlexey]

@alexcrichton,
I have got.
According to https://github.com/rust-lang-nursery/rustup.rs/#how-rustup-works
cargo is a proxy.

[KalitaAlexey]

@cissusnar,
Can you find cargo in rustup current toolchain and execute cargo run with cargo from the current toolchain?

[cissusnar]

@KalitaAlexey

$ rustup --version
rustup 1.0.0 (17b6d21 2016-12-15)

$ rustup show
Default host: x86_64-apple-darwin

stable-x86_64-apple-darwin (default)
rustc 1.14.0 (e8a012324 2016-12-16)

[KalitaAlexey]

@cissusnar,
You misunderstood me.
Open a terminal.
Execute in the terminal:

RUST_SYSROOT=$(rustc --print sys-root)

It should give you a path.
Execute in the terminal:

ls ${RUST_SYSROOT}/bin

There should be cargo.
Execute in the terminal:

cd <path/to/your/project>
${RUST_SYSROOT}/bin/cargo run

It should start running your project.
Try killing that with SIGINT.
Write your results.

[KalitaAlexey]

I checked it on Linux.
The problem happens with rustup.

[KalitaAlexey]

@cissusnar,
It is really the problem of rustup.