守护进程启动脚本的最大允许启动时间是多少？
我确实有一个需要花费大量时间才能启动的 tomcat 服务器，我可以在启动脚本中包含逻辑来检查服务是否成功启动。
不过，我还是担心守护进程启动时可能会出现无限循环，如果将其配置为在启动时运行，这甚至可能会影响系统的启动。
不过，我确实想返回正确的退出消息（成功/失败）。
我可以实现一些超时逻辑，但我不知道守护进程脚本的启动时间是可接受的还是不可接受的。
此外，当该服务仍在初始化时，停止其他服务的初始化也没有太大意义。
答案1
系统启动脚本没有“最大允许启动时间”。但是，对于长时间运行的脚本，启动脚本通常会将运行时间较长的程序作为后台进程甚至“at”进程来运行。这样可以防止运行缓慢的进程在系统“准备就绪”之前花费很长时间。
答案2
如上所述，守护进程没有最大或可配置的启动时间。如果您认为守护进程导致其他守护进程启动，您可以在最后更改其启动顺序。
为了调试这个问题，我现在能想到三种方法。
1) 显而易见的步骤是启用应用程序的调试日志。我主要使用 RHEL，并且/etc/sysconfig/<daemon-name>可以在其中设置日志级别。
2）当您手动启动守护进程时，使用 strace 启动它。
strace -ffttTo /tmp/daemon.out /etc/init.d/daemon start
现在在 daemon.out 文件中，观察每个系统调用结束时打印的时间。以微秒为单位。找出耗时最多的调用。
找到后，再次启动守护进程，这次使用 ltrace。现在您知道了有问题的系统调用，找出它在哪个库上卡住了。
3) 编写一个 systemtap 脚本。除非用户有使用 stap 编写/调试的经验，否则这个脚本并不容易。
probe syscall.*
{
( (pid) == target() )
printf("%s\n",name)
}
这将显示目标 pid 将抛出的所有系统调用。
注意 - 首先不要选择 stap。我之所以提到它，是因为它是一个很棒的内核调试工具，但我没有在网站上看到它的参考资料（或者可能被忽略了）。您需要安装 kernel-debuginfo、kernel-debuginfo-common、kernel-devel、systemtap 软件包。然后按如下方式运行脚本
stap <script_name.stp> -x pid
我们可以进一步检测有问题的系统调用。