Hermanverschooten
Ctrl-g q in dev and GenServer termination
Hi,
This has probably been asked a gazilion times…
Is there a reilable way to trap the stop of a GenServer in development, that means when you either stop using ctrl-g q or ctrl-c ctrl-c?
What I have tried:
Process.flag(:trap_exit,true)ininit/1, withterminate/2Process.monitoring frominit/1andhandle_info/2- Spawning a process that monitors with
receive
None of them worked.
On start of the GenServer I am registering with an external site and I want to unregister on stop.
This is only for development.
Most Liked
rvirding
From the very beginning processes did not have built parent-child relationships. It did keep processes very simple and it allowed us to work on how to build systems. The ideas of how to structure systems developed as our understanding of the problem grew and what was needed to build reliable systems that could handle errors in the right way.
We were working together with another group in Ericsson who were looking at designing a new architecture and used Erlang for experimenting. As they were very knowledgeable about such systems they came back with comments and ideas about how they thought they should look and work and what Erlang needed. Out this grew error handling and what later became supervisors. They also actually developed the first system Ericsson using Erlang!
Note that these ideas evolved before OTP was built and most of the ideas that became formalised and described in OTP came from these ideas. For examples we had of course servers before we got OTP gen_server and we were managing processes and restarting them when necessary before we had supervisors.
One very good thing with OTP is that they “packaged” these things and bought order into the whole library and system structure. This is an ENORMOUS benefit when building systems. You cannot overate it.
rvirding
From iex you can do :erlang.exit(pid(0,0,0), :kill) which will unconditionally terminate the system but generate a crash dunp in the file erl_crash.dump. Don’t ask
![]()
rvirding
The init module is preloaded into the BEAM and is the module that is automatically run by the BEAM when it starts its first process, the one that is <0.0.0>, calling the function init:boot(BootArgs) and the first thing it does is to register itself under the name init. It then traps exits. Note that although it a “special” process in how it is started and the module it runs it is actually just a normal Erlang process which is why you can kill it by sending it kill signal which is untrappable.
Actually all ALL processes in Erlang are equal and there are no special processes in any sense. Erlang is a very egalitarian in system in the sense that there are no special process and no special modules. All processes are equal and all modules are equal. You can kill or delete anything.
![]()
Popular in Questions
Other popular topics
Categories:
Sub Categories:
Forums
Popular Tags
- #ecto
- #liveview
- #troubleshooting
- #learning-elixir
- #deployment
- #library
- #erlang
- #testing
- #genserver
- #mix
- #absinthe
- #remote-other
- #otp
- #plug
- #how-to-question
- #macros
- #postgres
- #channels
- #elixirconf
- #exunit
- #discussion
- #code-sync
- #javascript
- #podcasts
- #onsite
- #dialyzer
- #docker
- #authentication
- #umbrella
- #full-time-contract
- #podcasts-by-brainlid
- #ecto-query
- #elixir-ls
- #phoenix_html
- #iex
- #blog-post
- #graphql
- #genstage
- #ai
- #websockets
- #supervisor
- #advent-of-code
- #elixirconf-us
- #distillery
- #processes
- #forms
- #api
- #metaprogramming
- #security
- #performance









