☰

为什么 systemd 启动后立即停止服务？

tag-icon • tag-icon linux systemd
为什么 systemd 启动后立即停止服务？

我创建了一个 systemd 服务，它在启动或重启时应该调用一个 shell 脚本。

[Unit]
Description=Starts the DCCA index software

[Install]
WantedBy=multi-user.target

[Service]
ExecStart=/opt/insiteone/bin/indexControl start
ExecStop=/opt/insiteone/bin/indexControl stop

# Execute pre and post scripts as root
#PermissionsStartOnly=true
Restart=on-abort
TimeoutSec=600

最初，它在启动后就会不断无限循环地重新启动，但是当我添加该选项时，它会在服务第一次启动时立即TimeoutSec调用（启动，然后立即再次停止）。ExecStop

有任何线索吗？我哪里错了？

附言：indexControl是一个 shell 脚本，用于启动其他进程

答案1

你没有告诉 systemd 这是什么样的守护进程，以及对它的期望是什么（最重要的是，它需要知道守护进程何时最终开始）。

默认值为Type=simple，这意味着第一的进程被视为主服务进程。它启动时，整个服务被视为“活动（已启动）”；它退出时，整个服务停止。

另一种常见模式是Type=forking，初始进程预计至少分叉一次并退出，留下一个子进程“在后台”运行或“守护进程”，有些人这样称呼它。

但如果你使用“whateverctl”工具，你总是去看看需要的行为Type=forking，因为该工具本身将尝试“在后台”启动守护进程并自行退出。

答案2

以上以及类似的答案对我都不起作用。但是这个帖子最终做到了。

[Unit]
Description=Setup foo
#After=network.target

[Service]
Type=oneshot
ExecStart=/opt/foo/setup-foo.sh
RemainAfterExit=true
ExecStop=/opt/foo/teardown-foo.sh
StandardOutput=journal

[Install]
WantedBy=multi-user.target

诀窍是RemainAfterExit=true指令。那是因为我的脚本没有留下任何痕迹供systemd查看，所以下一步systemd总是调用ExecStop来停止“这个不留下守护进程的奇怪脚本”。虽然没有实际意义，但确实如此。

更新 20180316：好吧，systemd这几个月我完全忘记了有关服务的一切，所以我从头开始重新做所有工作。幸运的是，我隐约记得这个答案，花了半个小时寻找它，现在我又回到了这里。

我将尝试添加这次我重新学到的几件事：systemd脚本不能放在 中/etc/init，它们会留在更丑陋的/etc/systemd/system目录中，而且它们被称为.service，而不是.conf！

脚本位于正确目录中后，sudo systemctl daemon-reload可以使用，但不会使脚本名称出现在sudo service [TAB]自动完成列表中。不过，可以使用以下命令启动新服务：

sudo service myservice start

就是这样，现在服务正在执行已编写的程序。当然，调用的脚本不会，但这是另一个问题。

答案3

如果您的启动服务/应用程序正在维护任何 pid，请保留 Type=forking 并提供 pid 文件位置。

[单元]
描述=“启动时运行应用程序”
After=network.target syslog.target auditd.service

[服务]
类型=forking
PIDFile=/var/run/apache2/apache2.pid
ExecStart=/etc/init.d/apache2 start
ExecStop=/etc/init.d/apache2 stop
StandardOutput=syslog
StandardError=syslog
Restart=on-failure
SyslogIdentifier=webappslog

[安装]
WantedBy=multi-user.target
别名=webapps

相关内容