Trapping Exits / Gracefully shutting down GenServers

larshei

I am currently scratching my head, because I am already trapping exits at one point, but I am not able to get it to work at another point.

Working Setup

In a project, I have the following setup:

DynamicSupervisor :my_supervisor as part of the applications Supervision Tree
A GenServer module MyServer.

:my_process is started using MyServer.start(), which looks like this:

  def start(name) do
    Logger.debug "#{__MODULE__} - #{name} starting"

    DynamicSupervisor.start_child(
      :my_supervisor,
      {
        __MODULE__,
        name
      }
    )
  end

so the Process should be attached to the Supervisor.
Then, in the MyServer.init(), exits are trapped:

  ...
  Process.flag(:trap_exit, true)
  ...

and a handle_info for handle :EXIT signals:

  def handle_info({:EXIT, _pid, reason}, state) do
    Logger.warn("#{state.fleet_name} - Stopped with reason #{inspect reason}")
    {:stop, reason, state}
  end

This all works as expected. If I run e.g. :init.stop(), the Logger warning is printed.

Non-working Setup

The setup is almost the same:

DynamicSupervisor :tracker_supervisor as part of the applications Supervision Tree
A GenServer module TrackerServer in a separate library

In the library:

defmodule MyLibrary.TrackerServer do
  def start_link(args) do
    GenServer.start_link(
      __MODULE__,
      args,
      name: args[:name] || __MODULE__
    )
  end

  def init(args) do
    ...
    Process.flag(:trap_exit, true)
    ...
    {:ok, initial_state}
  end

  def handle_info({:EXIT, _from, reason}, state) do
    Logger.warn("Tracking #{state.name} - Stopped with reason #{inspect reason}")
  end
end

In my project, i wrapped the GenServer.start_link() in a start() function:

  def start(name) do
    Logger.debug "#{name} - Starting Tracking"

    result = DynamicSupervisor.start_child(
      :tracker_supervisor,
      {
        MyLibrary.TrackerServer,
        [
          name: {:via, Registry, {MyRegistry, name}},
          ...
        ]
      }
    )
  end

The two examples are not unrelated.

The first example MyServer is running in my application and in its init function, the TrackerServer Process is also started. MyServer forwards some data to TrackerServer, but there is no real dependency between those two, e.g. when the TrackingServer crashes and does not exist, it is not a problem. It should be restarted by the supervisor and things should go back to normal afterwards. Tracking is mostly for statistics and missing some information here is not critical.

However, I would like to persist the state on :EXIT of the TrackerServer to actually keep what was tracked so far. But it seems the Process :EXIT handle info is never called.

I do not understand why one version works and the other does not What am I missing here?

2 comments

#processes #genserver #lifecycle

0 6653 2

2022-02-22 14:45:02 UTC

Marked As Solved

Show Best Posts
Show All (oldest first)
Show All (newest first)

lud

Is your process linked to another process that is not the supervisor ?

If you save the following code to an .exs file and execute it you will see that the handle_info/2 function is not called, because exit messages from the parent (in that case, the supervisor) are handled by the GenServer module itself, and not your code. But GenServer will call your terminate/2 callback.

defmodule Child do
  require Logger
  use GenServer

  def start_link(arg) do
    GenServer.start_link(__MODULE__, arg)
  end

  def init(arg) do
    Process.flag(:trap_exit, true)
    {:ok, arg}
  end

  def handle_info({:EXIT, _pid, reason}, state) do
    Logger.warn("#{inspect(reason)} in handle_info")
    {:stop, reason, state}
  end

  def terminate(reason, _state) do
    Logger.warn("#{inspect(reason)} in terminate")
  end
end

{:ok, sup} = DynamicSupervisor.start_link(strategy: :one_for_one)

{:ok, _pid} = DynamicSupervisor.start_child(sup, {Child, "a"})

Supervisor.stop(sup)

So, when :init.stop() is called, is it possible that the exit message that you receive is from another worker or something?

Post #1

Also Liked

larshei

Oh you are right!

I can see that I once knew this, because the working implementation actually has the terminate callback implemented (which calls the same functions as the :EXIT handle_info) but I forgot about this