☰

进一步阅读

tag-icon • tag-icon systemctl
进一步阅读

昨天我不得不更改我的 Haproxy 配置，我注意到我无法使用 systemctl 重新启动它。我必须手动启动它。

今天我不得不重新启动 Docker，同样的事情发生了。

journalctl -xe之后systemctl restart haproxy：

-- Unit haproxy.service has begun starting up.
Aug 06 11:19:30 ns3038251 systemd[1]: haproxy.service: Control process exited, code=dumped status=7
Aug 06 11:19:30 ns3038251 systemd[1]: haproxy.service: Failed with result 'core-dump'.
Aug 06 11:19:30 ns3038251 systemd[1]: Failed to start HAProxy Load Balancer.
-- Subject: Unit haproxy.service has failed

对于 Docker 来说：

-- The start-up result is RESULT.
Aug 06 11:19:08 ns3038251 systemd[1]: containerd.service: Main process exited, code=dumped, status=7/BUS
Aug 06 11:19:08 ns3038251 systemd[1]: containerd.service: Failed with result 'core-dump'.

我知道这不是配置文件问题，因为当我在控制台中运行它们时，haproxy和containerd（然后）都可以工作。dockerd

问题是互联网没有提供太多信息，我不知道我可以尝试调试什么，这是在远程服务器上，我不想重新启动，以防它在启动时根本无法启动。顺便说一句，我最近没有做任何事情，比如更新

感谢您能给我的任何建议

编辑：自从发布问题以来我一直很忙，几分钟前我重新登录到服务器。从那以后我什么也没做，然后又回到了同一个tmux窗口。

现在也没有问题systemctl restart haproxy了systemctl restart docker。我不明白这里发生了什么...

答案1

尝试获取正在运行的进程ps aux | grep 'haproxy'，然后获取该进程PID，然后使用 终止它kill -9 PID。然后尝试再次启动。

答案2

如果 systemctl 无法启动它，很可能是以下几种情况之一：

  1. 由于某些旧的 PID 文件或编写错误的启动脚本，Systemctl 认为它正在运行。 Systemctl 不会运行配置为仅运行一份副本的内容的两个副本。
  2. Systemctl 的新安全功能会导致原本有效的启动脚本失败。最近（去年）许多供应商在 systemctl 中添加了符号链接保护，如果您在某些文件中进行符号链接，systemctl 将不会遵循符号链接。这听起来很奇怪，但它可以防止您的系统被“符号链接劫持”。
  3. 您可以使用 su 或 sudo 启动该服务。这曾经是有效的，但这种方法也会带来安全问题，因此许多 Linux 供应商已经更改了 systemctl，以更喜欢“runas”作为用户转移程序。 Runas 不会遭受 su 或 sudo 允许的攻击的弱点。

当然，也可能是完全不同的东西。但是，如果您的服务文件、pid 文件或服务文件启动的 exec 脚本中有任何这些项目，那么您可能已经更新了软件并发现以前工作的服务现在出现了问题。这可能是因为以前工作的服务被配置为以不太理想的方式启动，并且配置需要更新。

答案3

我不知道我可以尝试调试什么

您的日志告诉您某个地方有核心转储。找到他们，看看他们告诉你什么，就像其他人在其他地方所做的那样。

如果有必要，请去找该程序的人员，或者如果您无法理解核心转储的内容，请去找他们的支持人员。至少有调试器的输出（针对核心转储运行）systemctl show unitnamebt在手里。如果您不告诉他们您如何配置服务管理以及您的计算机做了什么，他们不会心灵感应，并且无法知道您的服务单元配置文件中有哪些相关内容，也不知道在程序中的何处查找。

进一步阅读

相关内容