Resolve the pid of a remote registered process?

garrison

Alright, the actual use-case here is far too cursed to explain, but I wanted to call Process.exit/2 on a remote registered name. For a local registered name I can use Process.whereis/1 to get the pid and then send it the exit signal, but there is no whereis({name, node}) function as far as I can tell.

The send/2 function accepts the pid or {name, node} tuple directly, which makes me think what actually happens is that Erlang sends the message directly to the node to be resolved in one round-trip, which makes sense. I assume that’s also why send({name, node}) cannot raise while send(name) raises for an unregistered name (which is inconsistent with the rest of OTP and kinda bizarre).

But then exit/2 does not accept {name, node} tuples, so there’s no way to send an exit signal across the network without a remote pid. But I can’t find any way to resolve a remote name to a pid!

GenServer.whereis({name, node}) literally just returns {name, node}, which again makes sense because why would you want to eat a round-trip resolving the name.

This seems like a bit of a weird hole in OTP. I guess sending exit signals to registered processes through distribution just never comes up in practice?

To be clear I am not really looking for a solution here, this is not a serious problem. I’m just wondering if anyone knows of a “blessed” way to kill a process on another node by name. You know, for science

4 comments

#processes #distributed

0 306 4

2025-07-22 20:39:26 UTC

Showing Posts 1 to 4

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

LostKobrakai

You could probably (e)rpc the job of sending the exit signal to the node.

Post #1

garrison

Oh yes definitely, there are of course a bunch of ways to do this through indirection. I was just wondering if there is anything in OTP which is elegantly transparent to distribution (like so much of OTP is) and was somewhat disappointed to be unable to find a good solution.

My use case here is super weird, I’m doing fault injection testing against distributed code and I have reimplemented a good chunk of OTP in Elixir in order to enforce deterministic execution. I’ll post more about it later, it’s way too much to get into.

But I just happened to have some code which worked quite elegantly in a local/distributed fashion right up until I introduced {name, node} tuples for some processes and then I couldn’t find any way to make it work.

I’ll just go with another approach

Post #2

ausimian

With some caveats, the canonical way to do this in a fully connected Erlang cluster is to use global, register your process with {global, <name>} and use global:whereis_name/1.

Post #3

garrison

They’re not quite the same, though. Maybe it’s a bit superstitious but I don’t trust :global at all, the docs don’t really explain its guarantees very well and it makes me uncomfortable. The behavior of {name, node} is extremely clear and easy to understand. Since the process is supervised and registered on a single node you can never have any weird network problems or races, plus I think bugs in the implementation are far less likely since registration is such a hot path for BEAM apps.

In my case the nodes in question actually form a VSR consensus cluster and I need everything to be as predictable and testable as possible, so this stuff actually does matter a lot. Registering a name on each node feels much safer in my case, though I’m sure there are many cases where :global is perfectly fine. It just terrifies me tbh.

But anyway, I just thought it was odd you can send({name, node}) but you can’t exit({name, node}) or even look up the pid. I guess it’s just something nobody ever does

Post #4

— All posts loaded —