Plausible creating zombie process

[tvaril]

Hello I have plausible installed in docker. Caddy is installed on a host and is acting as reverse proxy for plausible web UI. Everything is running just find, don't see any errors, data are collected. But I noticed my VPS showing 1 zombie process each time after SSH into VPS. So I started digging into details and find out it is created by plausible. Everytime I stop the plausible containers all below process disappear. When I start it again it appears again. Is seems it does not have any effect to anything. The 284307 PID is parent of 285542. I am running all on Hetzner CAX31 Ampere aarch64 Cloud VPS with Ubuntu 24.04 LTS. Should I care? Should I ignore?

USER         PID %CPU %MEM    VSZ   RSS TTY      STAT START   TIME COMMAND
caddy     284307 30.4  2.7 1563972 440200 ?      Ssl  10:01   0:10 /app/erts-14.2.1/bin/beam.smp -- -root /app -bindir /app/erts-14.2.1/bin -progname erl -- -home /home/plausible -- -noshell -s elixir start_cli -mode embedded -setcookie TCEUJAMHIJBNHOLQMESR4MCUZNUUZBFQ6AKSALWRD5RU5SNWNFSA==== -sname plausible -config /app/releases/0.0.1/sys -boot /app/releases/0.0.1/start -boot_var RELEASE_LIB /app/lib -- -extra --no-halt
caddy     285542  0.0  0.0      0     0 ?        Zs   10:02   0:00 [epmd] <defunct>

[tvaril]

Nobody? @ruslandoga any idea?

[ruslandoga]

👋 @myazaki

It should be OK to ignore. You can read about epmd if you are curious.

[tvaril]

👋 @myazaki

It’s should be OK to ignore. You can read about epmd if you are curious.

Thanks, you have any link? I have been searching a lot a did not find anything I could relate to my findings.

[ruslandoga]

Sorry for a late reply.

Here're some links:

• https://www.erlang.org/doc/apps/erts/epmd_cmd.html
• https://www.erlang.org/doc/apps/erts/erl_dist_protocol.html#epmd-protocol

[ruslandoga]

In short, epmd is kind of like a service discovery mechanism for Erlang nodes that allows them to connect to each other.
In Plausible it is used to connect to the running app:

$ docker compose exec plausible bin/plausible remote

Here's what ChatGPT says about this command, it sounds about right.

When you run bin/app remote in an Elixir release, a series of steps are performed to establish a remote connection to a running Elixir node. Here’s a detailed, step-by-step explanation of what happens:

Step-by-Step Process:

1. Starting a New Erlang Node:

   • The bin/app remote script is executed, which starts a new Erlang node locally. This node will act as the remote shell client.
   • The node is started with a unique name, generated by combining the prefix rem- with a random string ($(rand)) and the value of $RELEASE_NODE. For example, it might be named something like rem-abc123@hostname.

2. Setting Up Node Configuration:

   • The script sets various environment variables and arguments to configure the node correctly:
     • --hidden: Starts the node in hidden mode, meaning it does not appear in the list of nodes in the cluster but can still communicate with them. This is useful for maintenance tasks that do not require the node to be visible.
     • --cookie "$RELEASE_COOKIE": Specifies the cookie used for authenticating communication between nodes. All nodes in an Erlang/Elixir cluster must have the same cookie to communicate securely.

3. Booting with the Correct Script and VM Arguments:

   • The script uses --boot "$REL_VSN_DIR/$RELEASE_BOOT_SCRIPT_CLEAN" to specify the boot script to initialize the Erlang runtime.
   • --boot-var RELEASE_LIB "$RELEASE_ROOT/lib" defines where the release libraries are located.
   • --vm-args "$RELEASE_REMOTE_VM_ARGS" sets additional VM arguments that are needed to configure the node, such as memory settings, garbage collection, and other runtime parameters.

4. Looking Up the Target Node:

   • The newly started node attempts to resolve the hostname and look up the target node ($RELEASE_NODE) it wants to connect to.
   • The Erlang Port Mapper Daemon (EPMD) is used to discover the node. EPMD is a small daemon that runs on every host participating in an Erlang/Elixir cluster, helping nodes find each other by registering node names and their corresponding ports.

5. Establishing a Remote Shell Connection:

   • The node attempts to connect to the target node specified by --remsh "$RELEASE_NODE". This flag indicates that the newly started node is a shell client that should connect to the specified node.
   • The connection is made using Erlang's distribution protocol over TCP/IP. Authentication is handled using the cookie set earlier.

6. Providing Remote Access to the Running Node:

   • Once the connection is established, the shell started by the bin/app remote command is now connected to the target node.
   • You can execute commands, evaluate expressions, and inspect the state of the target node directly from this remote shell.

Summary:

• Start Local Node: A new Erlang node starts with a unique name and hidden mode.
• Configure Authentication: The cookie and VM arguments are set up for communication.
• Look Up Target Node: The script uses EPMD to find the target node.
• Establish Connection: Connect to the target node using a remote shell.
• Remote Access: You gain interactive access to the running node for debugging and management tasks.

By following these steps, the bin/app remote script enables seamless interaction with a running Elixir node, making it a powerful tool for administration and debugging in distributed Elixir systems.