Processes spawned by `mix cmd` aren't terminated on abort

[digitalcora]

Environment

• Erlang 20.3.2 + Elixir 1.6.4
• Observed on Mac OS 10.13.3 and Alpine Linux 3.7

Current behavior

When using mix cmd --app <name> mix run --no-halt within an umbrella project, the mix run command seems to keep running in the background indefinitely, even after the mix cmd command has been terminated by Ctrl-C.

The best example I have at hand is Phoenix, since its generator produces an umbrella project complete with apps, and phx.server uses the --no-halt option. Minimal demo:

$ mix archive.install https://github.com/phoenixframework/archives/raw/master/phx_new.ez
$ mix phx.new hello --umbrella
$ cd hello_umbrella

$ mix cmd --app hello_web mix phx.server
==> hello_web
[info] Running HelloWeb.Endpoint with Cowboy using http://0.0.0.0:4000
^C
BREAK: (a)bort (c)ontinue (p)roc info (i)nfo (l)oaded
       (v)ersion (k)ill (D)b-tables (d)istribution
^C

$ ps -x | grep phx.server
11416 ??         0:01.82 /usr/local/Cellar/erlang/20.3.2/lib/erlang/erts-9.3/bin/beam.smp -- -root /usr/local/Cellar/erlang/20.3.2/lib/erlang -progname erl -- -home /Users/alex -- -pa /usr/local/Cellar/elixir/1.6.4/bin/../lib/eex/ebin /usr/local/Cellar/elixir/1.6.4/bin/../lib/elixir/ebin /usr/local/Cellar/elixir/1.6.4/bin/../lib/ex_unit/ebin /usr/local/Cellar/elixir/1.6.4/bin/../lib/iex/ebin /usr/local/Cellar/elixir/1.6.4/bin/../lib/logger/ebin /usr/local/Cellar/elixir/1.6.4/bin/../lib/mix/ebin -noshell -s elixir start_cli -extra /usr/local/bin/mix phx.server

Expected behavior

Naïvely I'd expect aborting a mix cmd command to abort any sub-command it spawned, and not leave it running in the background.

[josevalim]

I am not sure how we can solve this as Mix can't simply read the stdin as the underlying task may want to use it. For example, if mix automatically hijacks the stdin, iex -S mix would stop working.

The best I can think right now is to add a flag called --watch-stdin to mix phx.server but then this should be a feature request to the Phoenix team.

[digitalcora]

I am not sure how we can solve this as Mix can't simply read the stdin as the underlying task may want to use it.

I'm probably missing some context, but isn't the issue here that mix cmd is reading stdin? I'd think this because the Ctrl-C seems to be received by the mix cmd process, which terminates and leaves the real process running in the background.

The best I can think right now is to add a flag called --watch-stdin to mix phx.server but then this should be a feature request to the Phoenix team.

This may be encountered with any process, so I don't know if a Phoenix-specific solution would be adequate. For example:

$ mix cmd --app hello_web yes

yes is a process that runs until the user terminates it. If you press Ctrl-C here, it goes to mix cmd rather than yes. If you then abort (Ctrl-C again), this only terminates mix cmd, leaving yes running in the background until manually killed.

[josevalim]

@Grantovich it is the job of the child process to terminate itself once it notices that stdin has been closed. That's because the parent process may just terminate abruptly (due to an error or even segmentation fault).

Maybe cmd could attempt to terminate them but it wouldn't provide a guarantee. Under some circumstances, yes would still leak and continue running. AFAIK the VM does not allow us to simply forward our stdin to the underlying process.

I guess the other issue is that mix cmd was created for running multiple tasks in an umbrella, so those tasks always had to terminate. Using it for a single app means the task could run forever and we are now running into those issues. The minimum we could do is to document this.

[digitalcora]

I think I see what you mean — it seems like a tricky problem.

My primary interest in mix cmd is as a way to run other mix commands within the context of a specific app in an umbrella project, so if I'm missing a better-supported way to accomplish this (short of pushd apps/my_app && mix run some_task && popd), I'd happily switch to it.

[adamwight]

A minor update: for unknown reasons the "yes" utility correctly stops now, but the issue can still be demonstrated with a command like "sleep":

mix cmd sleep 60

No action is required on this task, I'm just looking into the general problem and its historical breadcrumbs.