随着我们在Linux上开发一套复杂的服务，我们开发了一个能够逐一启动的工具。 创build这样一个工具的许多考虑因素之一就是可以启动项目的顺序，而且也是确保守护进程死亡时守护进程自动重新启动的一种方法。 还有服务器范围的所有服务之间共享的参数。
不过，现在我有一个问题，closures这样一个系统需要时间。 closures一切可能需要多达10秒的时间。
我想知道的是：在/etc/init.d/...下定义的脚本能够closures它正在控制的守护进程多长时间？
虽然我会想象如果我们打破所有这些守护进程在单独的包（因为启动脚本现在可以包括一个依赖列表…），我们会碰到同样的问题。 所以在这一点上，我们宁愿保持事物的方式…
是否有一个明确的/已知的时间关机最多只能对所有守护进程优雅？
是否有一个明确的/已知的停机时间最多必须花费的时间？
没有。
正如我现在testing了在systemd上运行的系统上的各种守护进程的closures，我可以certificate每个守护进程都明确定义了超时。
从我所知道的情况来看，这也适用于仍然使用SysV脚本启动/停止的守护进程。 当Cassandra仍在处理文件时，执行systemctl restart cassandra将无法按预期工作。 对于这样的服务，你可能想要做一个systemctl stop cassandra ，一旦你可以确定它停止，做systemctl start cassandra 。
所以…您可以在每个守护进程的基础上定义/更改TimeoutStopSec参数。 这可以让你获得更好的粒度！
[Unit] ... TimeoutStopSec=120
您可能会更改系统默认值： DefaultTimeoutStartSec （可能不build议…）
还有一个重要的时机，就是重启function（显示在最后一个链接中）。这是非常重要的，因为systemd想要在100ms内重启一个进程默认情况下！ 所以如果你的守护进程需要2分钟的时间才能closures，那么它就不能正常工作。