Jenkins 与 Publish over SSH 插件，-1 退出状态

Question

我使用 Jenkins 进行构建，并使用插件将我的工件部署到服务器。部署文件后，我通过在插件中调用 eec 来停止服务

sudo service myservice stop

我收到来自通过 SSH 发布的答案：

SSH: EXEC: channel open
SSH: EXEC: STDOUT/STDERR from command [sudo service myservice stop]...
SSH: EXEC: connected
Stopping script myservice
SSH: EXEC: completed after 200 ms
SSH: Disconnecting configuration [172.29.19.2] ...
ERROR: Exception when publishing, exception message [Exec exit status not zero. Status [-1]]
Build step 'Send build artifacts over SSH' changed build result to UNSTABLE
Finished: UNSTABLE

生成失败，但服务已停止。

My/etc/init.d/myservice

#! /bin/sh
# /etc/init.d/myservice
#
# Some things that run always
# touch /var/lock/myservice
# Carry out specific functions when asked to by the system
case "$1" in
  start)
      echo "Starting myservice"
      setsid /opt/myservice/bin/myservice --spring.config.location=/etc/ezd/application.properties --server.port=8082 >> /opt/myservice/app.log &
  ;;
  stop)
      echo "Stopping script myservice"
      pkill -f myservice 
      #
  ;;
  *)
      echo "Usage: /etc/init.d/myservice {start|stop}"
      exit 1
  ;;
esac
exit 0

请告诉我为什么我会得到 -1 退出状态？

Answer 1

好吧，该脚本称为 /etc/init.d/myservice ，因此它与提供给pkill -f的myservice模式相匹配。而且因为脚本正在等待pkill完成，所以它仍然活着并被杀死并因此返回 -1（等待的结果中也有终止信号，但 Jenkins 奴隶守护进程没有打印它）。

也：

• 为pkill想出更具体的模式，
• 使用正确的 pid 文件或
• 切换到 systemd，它可以可靠地准确地杀死它启动的进程。

在这个时代，我推荐最后一个选项。Systemd 比 init 脚本可靠得多。

Answer 2

是的，Jan Hudec是对的。我在通过SSH插件发布中调用ps ax | grep myservice：

 83469 pts/5    Ss+    0:00 bash -c ps ax | grep myservice service myservice stop  

因此pkill -f myservice将影响 PID 83469 的进程，PID 83469 是 pkill 的父级。据我了解，这是-1状态原因。

我pkill -f myservice改为pkill -f "java.*myservice"，这解决了我的问题。