Szetty
Processes linked to IEx are not killed when IEx exits
Hello,
So I have learnt a new thing recently, processes spawned in an IEx shell are not terminated after IEx exists, not even if they were started using link. The same obviously is not true for any two processes linked between them, and not even true for Erlang shells, so it is really about IEx only.
When inspecting the processes I can see that the link just disappears and the “child” process is still alive after IEx process (which was the “parent”) is long gone.
I have been researching this, but could not find any Elixir, Erlang or C code pointing in this direction.
Does anyone have any idea how and where this is implemented ?
Most Liked
jstimps
This was interesting, so I wanted to try to reproduce it, and it’s true. Please excuse the old versions.
jstimpson@myhost:~$ ./bin/myapp remote
Erlang/OTP 25 [erts-13.2.2.15] [source] [64-bit] [smp:2:2] [ds:2:2:10] [async-threads:1] [jit:ns]
Interactive Elixir (1.15.8) - press Ctrl+C to exit (type h() ENTER for help)
iex(myapp@myhost)1> spawn_link(fn -> :timer.sleep(100000000) end)
#PID<0.5573.0>
iex(myapp@myhost)2> :erlang.is_process_alive(pid(0, 5573, 0))
true
iex(myapp@myhost)3>
BREAK: (a)bort (A)bort with dump (c)ontinue (p)roc info (i)nfo
(l)oaded (v)ersion (k)ill (D)b-tables (d)istribution
a
jstimpson@myhost:~$ ./bin/myapp remote
Erlang/OTP 25 [erts-13.2.2.15] [source] [64-bit] [smp:2:2] [ds:2:2:10] [async-threads:1] [jit:ns]
Interactive Elixir (1.15.8) - press Ctrl+C to exit (type h() ENTER for help)
iex(myapp@myhost)1> :erlang.is_process_alive(pid(0, 5573, 0))
true
jstimps
The behavior in the remote shell case is surprising to me personally, since my background is mostly in Erlang, in which it’s different. To demonstrate:
Terminal A:
~ ❯❯❯ iex --sname server # or `erl -sname server`
Erlang/OTP 27 [erts-15.2.6] [source] [64-bit] [smp:10:10] [ds:10:10:10] [async-threads:1] [jit]
Interactive Elixir (1.18.3) - press Ctrl+C to exit (type h() ENTER for help)
iex(server@Mac)1>
Terminal B:
~ ❯❯❯ erl -remsh server
Erlang/OTP 27 [erts-15.2.6] [source] [64-bit] [smp:10:10] [ds:10:10:10] [async-threads:1] [jit]
Eshell V15.2.6 (press Ctrl+G to abort, type help(). for help)
(server@Mac)1> spawn_link(fun() -> timer:sleep(1000000000) end).
<0.127.0>
(server@Mac)2>
BREAK: (a)bort (A)bort with dump (c)ontinue (p)roc info (i)nfo
(l)oaded (v)ersion (k)ill (D)b-tables (d)istribution
a
~ ❯❯❯ erl -remsh server
Erlang/OTP 27 [erts-15.2.6] [source] [64-bit] [smp:10:10] [ds:10:10:10] [async-threads:1] [jit]
Eshell V15.2.6 (press Ctrl+G to abort, type help(). for help)
(server@Mac)1> is_process_alive(pid(0,127,0)).
false
(server@Mac)2>
Coming from Erlang, I had a natural expectation that halting an iex remote shell would trigger links on processes that were started in that shell. My expectation turned out to be wrong, but I can see how this would end up causing unexpected system behavior during debugging sessions. I will attempt a PR to the iex docs to explain the behavior, as I don’t see anything in there currently (although I might have missed it!)
Edit: doc change merged to elixir main ![]()
Szetty
Found the explanation while discussing with Claude LLM, and the answer is as simple as possible: when shutting down IEx with “Ctrl + C” and “a” the process exits normally, so the link is not triggered, because it is not a crash.
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









