I’ve just used it for mix release. It recreated the xxx.pid file, but systemd didn’t restart the process. Pid wasn’t changed either. Not sure if that’s the information you are asking for.
DiodonHystrix
lessless
@DiodonHystrix Do you mean that bin/my_app restart restart the application and systemd somehow detected that and recreated pid file?
The part where pid doesn’t change is a bit weird - did new application process had a same pid again after restart? Or it was an error on the systemd side? Why then it recreated pid file?
Was systemd able to pickup application output after restart? I.e. were logs accessible through journalctl?
0
DiodonHystrix
The library :pid_file recreated the file after the restart.
PID belongs to beam.smp, which is not restarted it seems.
I don’t have syslog connected to app (which is run as daemon), so there is nothing in journalctl. But I do have new logs in erlang.log.1 after the app was restarted.
1
OvermindDL1
This sums it up when you do a beam restart, it just reloads all the code and restarts the system so the pid file gets overwritten with the same pid, so no change. 
1
lessless
@OvermindDL1 did you ever bother with allowing to shutdown application through Distillery scripts?
I thought that using proper Restart= option may help to instruct Systemd to not restart application that was shutdown through ./bin/my_app stop but setting on-failure doesn’t seem to work :\
0
OvermindDL1
lessless
@OvermindDL1 can’t recover the context now, but I do have another issue - epmd process is still running after I stopped the app through systemctl
$systemctl stop sidecar
$ps aux | grep epm
xxxx 2715 0.0 0.0 3916 1592 ? S May16 0:04 /srv/sidecar/erts-11.2/bin/epmd -daemon
My unit file
[Unit]
Description=sidecar service
After=network.target
[Service]
Type=forking
User=xxx
Group=xxx
WorkingDirectory= /srv/sidecar
ExecStart=authbind --deep /srv/sidecar/bin/sidecar start
ExecReload=/srv/sidecar/bin/sidecar reload_config
ExecStop=/srv/sidecar/bin/sidecar stop
PIDFile=/srv/sidecar/sidecar.prod.pid
Restart=always
RestartSec=5
EnvironmentFile=/etc/default/sidecar.env
SyslogIdentifier=sidecar
LimitNOFILE=65535
[Install]
WantedBy=multi-user.target
0
OvermindDL1
Yep, epmd forks as its own daemon. If you want to control it via systemctl then you need to give it its own service and have the other BEAM based services (erlang/elixir/etc) depend on it so they start after it.
0
hauleth
Actually it must be managed externally, as systemd by default starts process in the namespace group so if the process goes down, then all other spawned processes should go down with it.
@lessless check out if there is systemctl status epmd (if you have installed Erlang via system package manager, then there should be the EPMD systemd service created).
1
OvermindDL1
As I recall it doesn’t fork epmd from itself, but actually calls it from init, so I’m more unsure if it would work directly like that? Might have to give a specific systemd option to enforce that in the service file?
0