[英]Erlang: rebar3 release, start beam first?
I am trying to utilize a new feature in 19.3 per this question: Erlang: does the application behavior trap SIGTERM? 我试图通过每个问题在19.3中使用一项新功能: Erlang:应用程序行为是否会捕获SIGTERM?
My understanding is that sending SIGTERM to BEAM now triggers a graceful shutdown in Erlang 19.3+ 我的理解是,现在将SIGTERM发送到BEAM会触发Erlang 19.3+中的正常关机
I start my application in Docker using the ENTRYPOINT ./_build/default/rel/myapp/bin/myapp
where ./_build/default/rel/myapp/bin/myapp
is generated from rebar3 release
我使用ENTRYPOINT在Docker中启动我的应用程序./_build/default/rel/myapp/bin/myapp
其中./_build/default/rel/myapp/bin/myapp
是从rebar3 release
生成的
When I do this in Docker, myapp
gets PID1 and BEAM seems to gets another PID. 当我在Docker中执行此操作时, myapp
将获得PID1,而BEAM似乎将获得另一个PID。
Is there a different set of commands I can run such that BEAM gets PID1 and myapp gets loaded from there? 我可以运行一组不同的命令,以便BEAM获取PID1并从那里加载myapp吗? Something like 就像是
./start_beam; ./start_my_app_via_beam
./start_beam; ./start_my_app_via_beam
? ./start_beam; ./start_my_app_via_beam
?
I need this because docker stop
sends SIGTERM to the PID1. 我需要这个,因为docker stop
将SIGTERM发送到PID1。 I need that to be BEAM. 我需要成为BEAM。 Using the above entrypoint, here is what happens in the container": top PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 1 root 20 0 4340 644 556 S 0.0 0.0 0:00.01 myapp 14 root 20 0 3751188 50812 6660 S 0.0 0.6 0:00.48 beam.smp 18 root 20 0 11492 116 0 S 0.0 0.0 0:00.00 epmd 31 root 20 0 4220 680 604 S 0.0 0.0 0:00.10 erl_child_setup 53 root 20 0 11456 944 840 S 0.0 0.0 0:00.00 inet_gethost 54 root 20 0 17764 1660 1504 S 0.0 0.0 0:00.00 inet_gethost 55 root 20 0 20252 3208 2720 S 0.0 0.0 0:00.02 bash 61 root 20 0 21956 2468 2052 R 0.0 0.0 0:00.00 top
使用上述入口点,容器中将发生以下情况:“ top PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 1 root 20 0 4340 644 556 S 0.0 0.0 0:00.01 myapp 14 root 20 0 3751188 50812 6660 S 0.0 0.6 0:00.48 beam.smp 18 root 20 0 11492 116 0 S 0.0 0.0 0:00.00 epmd 31 root 20 0 4220 680 604 S 0.0 0.0 0:00.10 erl_child_setup 53 root 20 0 11456 944 840 S 0.0 0.0 0:00.00 inet_gethost 54 root 20 0 17764 1660 1504 S 0.0 0.0 0:00.00 inet_gethost 55 root 20 0 20252 3208 2720 S 0.0 0.0 0:00.02 bash 61 root 20 0 21956 2468 2052 R 0.0 0.0 0:00.00 top
Currently, to get around this, I have this horrendous beast: 当前,为了解决这个问题,我有一个可怕的野兽:
#!/usr/bin/env bash
echo "if testing locally send SIGTERM to $$"
term_handler() {
echo "Stopping the Erlang VM gracefully"
#/usr/local/Cellar/erlang/19.1/lib/erlang/lib/erl_interface-
3.9.1/bin/erl_call -c myapp -s -a 'init stop' -n 'myapp@localhost'
/usr/local/lib/erlang/lib/erl_interface-3.9.2/bin/erl_call -c myapp -s -a 'init stop' -n 'myapp@localhost'
echo "Erlang VM Stopped"
}
trap term_handler SIGQUIT SIGINT SIGTERM
./_build/default/rel/myapp/bin/myapp &
PID=$!
echo "Erlang VM Started"
#wait $PID
while kill -0 $PID ; do wait $PID ; EXIT_STATUS=$? ; done
echo "Exiting Wrapper."
exit $EXIT_STATUS
```
And then I do `ENTRYPOINT : ["./thisscript"]`
This beast becomes PID 1, and it finds the correct thing to kill after that. 该野兽成为PID 1,并在此之后找到要杀死的正确东西。
I'm trying to get rid of this script. 我试图摆脱这个脚本。
声明:本站的技术帖子网页,遵循CC BY-SA 4.0协议,如果您需要转载,请注明本站网址或者原文地址。任何问题请咨询:yoyou2525@163.com.