【问题标题】:unit falling into a failed state (status=143) when stopping service [closed]停止服务时单元进入故障状态(状态=143)[关闭]
【发布时间】:2018-02-07 18:29:26
【问题描述】:

这是我的问题。我有 CentOS 和 java 进程在它上面运行。 Java 进程由启动/停止脚本操作。它也会创建一个 java 实例的 .pid 文件。

我的单元文件看起来像:

[Unit]
After=syslog.target network.target
Description=Someservice

[Service]
User=xxxuser
Type=forking
WorkingDirectory=/srv/apps/someservice
ExecStart=/srv/apps/someservice/server.sh start
ExecStop=/srv/apps/someservice/server.sh stop
PIDFile=/srv/apps/someservice/application.pid
TimeoutStartSec=0

[Install]
WantedBy=multi-user.target

当我调用stop 函数时,脚本以SIGTERM 终止java 进程并返回0 代码:

kill $OPT_FORCEKILL `cat $PID_FILE`
<...>
return 0

之后,如果我检查我的单位的状态,我会得到类似的东西 (status=143):

● someservice.service - Someservice
   Loaded: loaded (/usr/lib/systemd/system/someservice.service; enabled; vendor preset: disabled)
   Active: failed (Result: exit-code) since Wed 2017-08-30 09:17:40 EEST; 4s ago
  Process: 48365 ExecStop=/srv/apps/someservice/server.sh stop (code=exited, status=0/SUCCESS)
 Main PID: 46115 (code=exited, status=143)

Aug 29 17:10:02 whatever.domain.com systemd[1]: Starting Someservice...
Aug 29 17:10:02 whatever.domain.com systemd[1]: PID file /srv/apps/someservice/application.pid not readable (yet?) after start.
Aug 29 17:10:04 whatever.domain.com systemd[1]: Started Someservice.
Aug 30 09:17:39 whatever.domain.com systemd[1]: Stopping Someservice...
Aug 30 09:17:39 whatever.domain.com server.sh[48365]: Stopping someservice - PID [46115]
Aug 30 09:17:40 whatever.domain.com systemd[1]: someservice.service: main process exited, code=exited, status=143/n/a
Aug 30 09:17:40 whatever.domain.com systemd[1]: Stopped Someservice.
Aug 30 09:17:40 whatever.domain.com systemd[1]: Unit someservice.service entered failed state.
Aug 30 09:17:40 whatever.domain.com systemd[1]: someservice.service failed.

当我的启动/停止脚本中没有return 值时,它的行为完全一样。
在单元文件中添加如下内容:

[Service]
SuccessExitStatus=143

对我来说不是个好主意。为什么systemctl 如此行事,却没有向我显示正常的服务状态?

当我尝试修改我的启动/停止脚本而不是 return 0 我输入 return 10 时,它的作用相同,但我可以看到 exit 10 已通过。
这是一个例子:

● someservice.service - Someservice
   Loaded: loaded (/usr/lib/systemd/system/someservice.service; enabled; vendor preset: disabled)
   Active: failed (Result: exit-code) since Wed 2017-08-30 09:36:22 EEST; 5s ago
  Process: 48460 ExecStop=/srv/apps/someservice/server.sh stop (code=exited, status=10)
  Process: 48424 ExecStart=/srv/apps/someservice/server.sh start (code=exited, status=0/SUCCESS)
 Main PID: 48430 (code=exited, status=143)

Aug 30 09:36:11 whatever.domain.com systemd[1]: Starting Someservice...
Aug 30 09:36:11 whatever.domain.com systemd[1]: PID file /srv/apps/someservice/application.pid not readable (yet?) after start.
Aug 30 09:36:13 whatever.domain.com systemd[1]: Started Someservice.
Aug 30 09:36:17 whatever.domain.com systemd[1]: Stopping Someservice...
Aug 30 09:36:17 whatever.domain.com server.sh[48460]: Stopping someservice - PID [48430]
Aug 30 09:36:21 whatever.domain.com systemd[1]: someservice.service: main process exited, code=exited, status=143/n/a
Aug 30 09:36:22 whatever.domain.com systemd[1]: someservice.service: control process exited, code=exited status=10
Aug 30 09:36:22 whatever.domain.com systemd[1]: Stopped Someservice.
Aug 30 09:36:22 whatever.domain.com systemd[1]: Unit someservice.service entered failed state.
Aug 30 09:36:22 whatever.domain.com systemd[1]: someservice.service failed.

journalctl 日志我可以看到systemctl 首先返回状态=143,然后返回值10。所以我猜我的错误是在启动/停止脚本的某个地方(因为错误代码143 被传递在函数返回 0) 之前?

【问题讨论】:

  • java 应用程序本身返回 143。也许让它不分叉并包装在一个返回 0 的脚本中?
  • 但是我用 SIGTERM(或 KILL)信号杀死了这个应用程序.. 并且 bash 返回我 0 退出代码,为什么 systemctl 像 143 一样解释它。
  • 杀死的脚本返回0(嗯,启动的脚本也返回0)。但申请是一个完全不同的过程。
  • 143 看起来像 synthetic exit status,由 shell 计算为 128 + 信号编号。在您的情况下,信号编号​​为 143 - 128 = 15,对应于 SIGTERM。
  • 注意:类似的问题已经贴在这里:serverfault.com/questions/695849/…

标签: linux systemd systemctl


【解决方案1】:

您应该能够通过将退出代码添加到单元文件中作为“成功”退出状态来抑制这种情况:

[Service]
SuccessExitStatus=143

source

【讨论】:

  • 可以否决选民解释方式?问题的答案取决于Linux Admin Information。你认为每个 java 开发者都应该是 Linux Admin 吗?
猜你喜欢
  • 2010-09-23
  • 1970-01-01
  • 2011-04-02
  • 2013-03-23
  • 2012-01-28
  • 2014-06-27
  • 2015-07-06
  • 1970-01-01
  • 2019-12-01
相关资源
最近更新 更多