[erlang-questions] exit status of run_erl

Tom O'Dowd <>
Thu Apr 20 10:12:55 CEST 2017


Oh. That’s an interesting idea. I will check that out. Thanks for the pointer.

Tom.

> On Apr 19, 2017, at 23:35, Graham Hay <> wrote:
> 
> You can use Type=notify for your service, and then inform systemd of the main pid later (like a forking daemon, with a pidfile, once was). That's how rabbitmq works:
> 
> https://github.com/binarin/rabbitmq-server/blob/master/src/rabbit.erl#L345 <https://github.com/binarin/rabbitmq-server/blob/master/src/rabbit.erl#L345>
> 
> On 19 April 2017 at 06:51, Tom O'Dowd < <mailto:>> wrote:
> I’m starting an application using systemd which uses run_erl in daemon mode. When I stop the application though by running init:stop(), run_erl seems to return an exit status of 1 rather than 0 so I always get a failed status for the service rather than an inactive status. I can set systemd SuccessExitStatus=1 to have it treat 1 as a success but then if for example the erlang node did die, it still gets marked as inactive rather than failed.
> 
> Note that if I tell systemd that the MainPID is the pid of the beam process rather than run_erl, systemd spits out a warning
>        Supervising process 96669 which is not our child. We'll most likely not notice when it exits.
> and sure enough, if you kill beam, systemd doesn’t notice.
> 
> Main issue sees to be that run_erl doesn’t return the exiting VM status back as its own status. Currently using 19.2 although will move to 19.3 shortly.
> 
> Any pointers? Been poking around on Google and this doesn’t seem like a common issue so maybe I am doing something wrong.
> 
> Thanks,
> 
> Tom.
> 
> _______________________________________________
> erlang-questions mailing list
>  <mailto:>
> http://erlang.org/mailman/listinfo/erlang-questions <http://erlang.org/mailman/listinfo/erlang-questions>
> 
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20170420/00e8580d/attachment.html>


More information about the erlang-questions mailing list