Also, if it helps, I use this overlay to generate (via distillary) a systemd service file using this PID library:

[Unit]
Description=<%= description %>
After=network.target

[Service]<% full_dir = Path.absname(output_dir)%>
Type=forking
User=<%= deploy_user %>
Group=<%= deploy_group %>
WorkingDirectory=<%= full_dir %>
ExecStart=<%= full_dir %>/bin/<%= p_name %> start
ExecReload=<%= full_dir %>/bin/<%= p_name %> reload_config
ExecStop=<%= full_dir %>/bin/<%= p_name %> stop
PIDFile=<%= full_dir %>/<%= p_name %>.prod.pid
Restart=always
RestartSec=5
Environment=PORT=3000
Environment=LANG=en_US.UTF-8
SyslogIdentifier=<%= p_name %>

[Install]
WantedBy=multi-user.target

Been using it in production ever since migrated the server from Windows 2008 to redhat, so a couple weeks now without issue. This follows the proper systemd model using a PID file with proper restarts (tested it by manually telling the server to stop, killing it, kill -9’ing it, comes back up in 5 seconds every time).

Well first of all that should not be there. That means ‘pretend everything stays working even when the application closes’. Why do you have that there?! o.O

Probably it is worth mentioning in this thread that it is common to supervise the VM via the built-in heart mechanism: heart — OTP 29.0.2 (kernel 11.0.2)

It works by starting a separate process called heart that not only checks if the beam process is still alive but also sends heartbeat messages to it (hence the name).

Of course if you use heart other restart mechanisms should not be in place. Also if you want to manually kill the VM you need to kill the heart process first, then the VM. Better option to stop the VM would be to call init:stop() from a remote node as described here for example: [erlang-questions] How to stop a detached OTP app?

The main advantage of the heart method is that it is OS independent.