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