Running code when a script exits

Alternatively, we could move System.stop() to the callback:

defmodule QuitScript do
  @behaviour :gen_event

  def init(_), do: {:ok, nil}
  def handle_event(:sigquit, _state), do: System.stop()
  def handle_event(signal, state), do: :erl_signal_handler.handle_event(signal, state)
  def handle_call(_, state), do: {:ok, :ok, state}

  def terminate(_reason, _state) do
    IO.puts("My exit code")
  end
end

:gen_event.swap_handler(:erl_signal_server, {:erl_signal_handler, []}, {QuitScript, []})

Looks more natural to me this way, though in the previous example the order in which the custom code runs is more obvious.

I have investigated a bit the solution with the signal handler.

Erlang executes :init.stop() on SIGTERM by default. That means that a simple kill PID shuts the thing down orderly.

However, you need to figure out the PID of the process, and open a different terminal to execute the command. Besides, custom code passed to System.at_exit/1 is not invoked by the event handler.

Ctrl-C sends SIGINT. The only shortcut that I’ve seen sends a different signal is Ctrl-\, which sends SIGQUIT. So, I am using this event handler:

defmodule QuitScript do
  @behaviour :gen_event

  def init(_), do: {:ok, nil}
  def handle_event(:sigquit, _state), do: :remove_handler
  def handle_event(signal, state), do: :erl_signal_handler.handle_event(signal, state)
  def handle_call(_, state), do: {:ok, :ok, state}

  def terminate(_reason, _state) do
    IO.puts("My exit code")
    System.stop()
  end
end

:gen_event.swap_handler(:erl_signal_server, {:erl_signal_handler, []}, {QuitScript, []})

Notice that the terminate/2 callback allows you to run custom code on exit.

If you throw that to a script and execute it for example like this

mix run --no-halt foo.exs

Ctrl-C still behaves as always, and additionally Ctrl-\ shuts the thing down orderly (you only see ^\ echoed in the terminal, not too bad).

Another trick you could do is System.at_exit(fn int -> your_code(); System.stop(int) end).

Could put the logic you want to execute on exit in a terminate/2 callback of a process in your app’s sup tree?

We could execute at_exit for System.stop as well… but we do have an issue in that they would be executed way too late in the termination process, when almost everything would be shut down, so it is likely not useful. That’s why System.at_exit is about the script exiting normally.

@josevalim ah, re terminate/2, what I said was that if you remove System.stop/1 and let the script finish by itself, then System.at_exit/1 is called, but terminate/2 callbacks are not invoked (meaning that is an observable property that suggests to me the application is not being shutdown, there’s just the VM halting.)

Thanks @josevalim!

However, System.stop/1 has three problems:

1. It does not invoke System.at_exit/1, that is why my “halter” solution above needs to get passed a function.
2. The script ends printing the noisy “exit” traces I quoted above. Maybe that is cosmetic, but a user does not know if “no process: the process is not alive or…” is a normal message or something to worry about, and in any case the output is not clean as you’d expect from running a program that finishes normally.
3. The programmer needs to do this by hand. I am touching a file to finish the script! Alternatively, I could write a signal handler, but all this seems boilerplate for something mix run should have builtin in my view.

The question is: mix run starts the application by default, why does not provide a builtin way to cleanly stop the application too?

There are two questions here:

1. How to shut the system down cleanly

2. How to handle certain signals (interrupt)

To answer 1, System.stop/1 is the answer. If terminate/2 callbacks are not invoked, make sure those processes are trapping exits.

To answer 2, since Erlang/OTP 20, there is OS signal handling: http://erlang.org/doc/man/kernel_app.html#os-signal-event-handler

It is a bit of a long answer. In a nutshell, you need to implement a gen_event handler and react to the callbacks you are interested. There is a more detailed guide here: https://medium.com/@ellispritchard/graceful-shutdown-on-kubernetes-with-signals-erlang-otp-20-a22325e8ae98

BTW, if you do not call System.stop/1 and let run/1 and the script finish by itself, then System.at_exit/1 gets invoked, but the application is apparently not stopped. At least, I do not see terminate/2 callbacks being invoked.

Temporary hack

Thanks @rvirding! That makes sense. Since Ctrl-G does not trigger a signal, I guess someone needs to be monitoring standard input to do something about it.

By now, I am moving on with a dirty solution, which is to monitor a file:

defmodule Halter do
  @halter "halt"

  def run(on_halt) do
    if File.exists?(@halter) do
      File.rm(@halter)
      on_halt.()
      System.stop()
    else
      Process.sleep(1000)
      run(on_halt)
    end
  end
end

Halter.run(fn -> IO.puts("done") end)

You leave the script running, and touch halt whenever you want it to stop. Enough for my purposes right now.

That solution prints these noisy traces, so it is definitely not clean:

** (exit) exited in: GenServer.call(Mix.ProjectStack, {:get_stack, #Function<10.12591541/1 in Mix.ProjectStack.peek/0>}, :infinity)
    ** (EXIT) no process: the process is not alive or there's no process currently associated with the given name, possibly because its application isn't started
    (elixir 1.10.3) lib/gen_server.ex:1013: GenServer.call/3

System.at_exit/1 is not invoked (that is why run/1 above receives a callback), I do not know why.

Is this a missing feature?

Not being able to do this easily surprises to me. It is a fundamental aspect of Erlang/OTP that you start applications and, symmetrically, shut them down orderly.

So, given that mix run starts the application by default, you’d expect that there would be interface to shut it down too, no? @josevalim is there a technical reason this is not in place? Or is it something that could be contributed?

A thing to realise here is that the handling of Ctrl-G and its commands only work when you are running a shell. Without a shell this interface is not generally not started. You can see this if you look in the elixir shell script and see that when an iex shell is not start then there is a -noshell argument to the resultant erl command. Doing elixir foo.exs does not start a shell and, hence, no handling of Ctrl-G and q.