[英]Erlang: rebar3 release, start beam first?
我試圖通過每個問題在19.3中使用一項新功能: Erlang:應用程序行為是否會捕獲SIGTERM?
我的理解是,現在將SIGTERM發送到BEAM會觸發Erlang 19.3+中的正常關機
我使用ENTRYPOINT在Docker中啟動我的應用程序./_build/default/rel/myapp/bin/myapp
其中./_build/default/rel/myapp/bin/myapp
是從rebar3 release
生成的
當我在Docker中執行此操作時, myapp
將獲得PID1,而BEAM似乎將獲得另一個PID。
我可以運行一組不同的命令,以便BEAM獲取PID1並從那里加載myapp嗎? 就像是
./start_beam; ./start_my_app_via_beam
./start_beam; ./start_my_app_via_beam
?
我需要這個,因為docker stop
將SIGTERM發送到PID1。 我需要成為BEAM。 使用上述入口點,容器中將發生以下情況:“ 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
當前,為了解決這個問題,我有一個可怕的野獸:
#!/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"]`
該野獸成為PID 1,並在此之后找到要殺死的正確東西。
我試圖擺脫這個腳本。
聲明:本站的技術帖子網頁,遵循CC BY-SA 4.0協議,如果您需要轉載,請注明本站網址或者原文地址。任何問題請咨詢:yoyou2525@163.com.