分叉服务一启动就重新启动?
Forked Service getting restarted as soon as it starts?
我有如下的 systemd 脚本
[Unit]
Description= TaskParticipant Service
[Service]
Type=forking
RemainAfterExit=no
ExecStart=/bin/bash bin/start-participant.sh
ExecStop=/bin/bash bin/stop-participant.sh
Restart=on-failure
WorkingDirectory=/opt/taskparticipant
User=javauser
Group=javauser
PrivateTmp=true
TimeoutSec=90
SuccessExitStatus=1
[Install]
WantedBy=multi-user.target
完成 systemctl start tp
之后
我收到以下错误
[centos@mmanthena bin]$ sudo systemctl status tp.service
● tp.service - TaskParticipant
Loaded: loaded (/etc/systemd/system/tp.service; enabled; vendor preset: disabled)
Active: inactive (dead) since Tue 2019-08-06 07:20:19 GMT; 2s ago
Process: 6635 ExecStop=/bin/bash bin/stop-participant.sh (code=exited, status=1/FAILURE)
Process: 6504 ExecStart=/bin/bash bin/start-participant.sh (code=exited, status=0/SUCCESS)
Main PID: 6577 (code=exited, status=1/FAILURE)
Aug 06 07:20:17 manthena systemd[1]: Starting TaskParticipant...
Aug 06 07:20:17 manthena bash[6504]: **************************************
Aug 06 07:20:17 manthena bash[6504]: Starting TaskParticipant
Aug 06 07:20:17 manthena bash[6504]: **************************************
Aug 06 07:20:18 manthena systemd[1]: Started - TaskParticipant.
Aug 06 07:20:19 manthena bash[6635]: Stopping Participant
#!/bin/bash
# JVM ARGUMENTS
jvm_min_heap_size="128m"
jvm_min_heap="-Xms${jvm_min_heap_size}"
jvm_max_heap_size="256m"
jvm_max_heap="-Xmx${jvm_max_heap_size}"
# GC Configuration
jvm_gc_options="-XX:+UseG1GC -XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=/acds/var"
jvm_gc_log_option="-XX:+PrintGCDetails -XX:+PrintGCDateStamps -XX:+PrintTenuringDistribution -Xloggc:${logs_dir}/task-participant-gc.log"
jvm_arg_line="${jvm_min_heap} ${jvm_max_heap} ${jvm_gc_options} ${jvm_gc_log_option} -Dlog4j.configuration=task_participant_log4j.conf"
config_file_option="-cf ${conf_dir}/acds_taskmanager.conf"
host_name_option="-H ${HOSTNAME}"
java_arg_line="${config_file_option} ${host_name_option}"
# Run java
main_class=io.manoj.acds.taskparticipant.TaskParticipant
cmdline="java -cp ${cp} ${jvm_arg_line} ${main_class} ${java_arg_line} $*"
cd $root_dir
nohup $cmdline &
tp_pid=$(jps -l | grep io.manoj.acds.taskparticipant.TaskParticipant | awk '{print }')
echo ${tp_pid} > ${tp_pid_file}
我的期望是该进程应该启动并且 运行 在后台,因为父级是 bin/start-participant.sh 并且它启动了一个 java 进程,但我看到该进程从 systemctl
开始重新启动
手动启动时它按预期工作(即 运行 脚本直接工作正常)
我认为问题出在工作目录上。
如果您在 bash_profiles
或 bashrc
中定义了 systemd 单元未使用的变量。
您可以为此使用 EnvironmentFile=
部分。
很可能 $root_dir
变量为空,因此 cd $root_dir
将工作目录从 systemd 单元定义的 ( WorkingDirectory=/opt/taskparticipant
) 更改为 javauser 主目录。我认为这不是预期的行为。
如果您将行 cd $root_dir
更改为 cd ${root_dir:?}
可以验证这一点,如果 $root_dir
变量为空,脚本将退出并出错。
我有如下的 systemd 脚本
[Unit]
Description= TaskParticipant Service
[Service]
Type=forking
RemainAfterExit=no
ExecStart=/bin/bash bin/start-participant.sh
ExecStop=/bin/bash bin/stop-participant.sh
Restart=on-failure
WorkingDirectory=/opt/taskparticipant
User=javauser
Group=javauser
PrivateTmp=true
TimeoutSec=90
SuccessExitStatus=1
[Install]
WantedBy=multi-user.target
完成 systemctl start tp
我收到以下错误
[centos@mmanthena bin]$ sudo systemctl status tp.service
● tp.service - TaskParticipant
Loaded: loaded (/etc/systemd/system/tp.service; enabled; vendor preset: disabled)
Active: inactive (dead) since Tue 2019-08-06 07:20:19 GMT; 2s ago
Process: 6635 ExecStop=/bin/bash bin/stop-participant.sh (code=exited, status=1/FAILURE)
Process: 6504 ExecStart=/bin/bash bin/start-participant.sh (code=exited, status=0/SUCCESS)
Main PID: 6577 (code=exited, status=1/FAILURE)
Aug 06 07:20:17 manthena systemd[1]: Starting TaskParticipant...
Aug 06 07:20:17 manthena bash[6504]: **************************************
Aug 06 07:20:17 manthena bash[6504]: Starting TaskParticipant
Aug 06 07:20:17 manthena bash[6504]: **************************************
Aug 06 07:20:18 manthena systemd[1]: Started - TaskParticipant.
Aug 06 07:20:19 manthena bash[6635]: Stopping Participant
#!/bin/bash
# JVM ARGUMENTS
jvm_min_heap_size="128m"
jvm_min_heap="-Xms${jvm_min_heap_size}"
jvm_max_heap_size="256m"
jvm_max_heap="-Xmx${jvm_max_heap_size}"
# GC Configuration
jvm_gc_options="-XX:+UseG1GC -XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=/acds/var"
jvm_gc_log_option="-XX:+PrintGCDetails -XX:+PrintGCDateStamps -XX:+PrintTenuringDistribution -Xloggc:${logs_dir}/task-participant-gc.log"
jvm_arg_line="${jvm_min_heap} ${jvm_max_heap} ${jvm_gc_options} ${jvm_gc_log_option} -Dlog4j.configuration=task_participant_log4j.conf"
config_file_option="-cf ${conf_dir}/acds_taskmanager.conf"
host_name_option="-H ${HOSTNAME}"
java_arg_line="${config_file_option} ${host_name_option}"
# Run java
main_class=io.manoj.acds.taskparticipant.TaskParticipant
cmdline="java -cp ${cp} ${jvm_arg_line} ${main_class} ${java_arg_line} $*"
cd $root_dir
nohup $cmdline &
tp_pid=$(jps -l | grep io.manoj.acds.taskparticipant.TaskParticipant | awk '{print }')
echo ${tp_pid} > ${tp_pid_file}
我的期望是该进程应该启动并且 运行 在后台,因为父级是 bin/start-participant.sh 并且它启动了一个 java 进程,但我看到该进程从 systemctl
开始重新启动手动启动时它按预期工作(即 运行 脚本直接工作正常)
我认为问题出在工作目录上。
如果您在 bash_profiles
或 bashrc
中定义了 systemd 单元未使用的变量。
您可以为此使用 EnvironmentFile=
部分。
很可能 $root_dir
变量为空,因此 cd $root_dir
将工作目录从 systemd 单元定义的 ( WorkingDirectory=/opt/taskparticipant
) 更改为 javauser 主目录。我认为这不是预期的行为。
如果您将行 cd $root_dir
更改为 cd ${root_dir:?}
可以验证这一点,如果 $root_dir
变量为空,脚本将退出并出错。