1

What is the maximum allowable startup time for a daemon startup script?

I do have a tomcat server that takes a lot of time to start and I could include logic inside the startup script to check if the service successfully started or not.

Still, I have some concerns regarding a potential endless loop for the daemon startup, which could impact even the startup of the system if this is configured to run at boot time.

Still, I do want to return a proper exit message (success/fail).

I could implement some timeout logic but I have no idea what would be considered an acceptable or unacceptable startup time for a daemon script.

Also, it doesn't make too much sense to stop initialization of other services while this service is still initializing.

2 Answers 2

1

There is no "maximum allowable startup time" for a system startup script. However, for long running scripting, what happens is that the startup script will usually spin off the program that takes a long time as a background process or even an "at" process. Thus this prevents a slow running process from taking a long time before the system is "ready" to run.

1
  • Based on this I decided to alter the star logic in the daemon script. When run in interactive mode it will wait for the service to start, displaying more information. But, when run in non-interactive mode it will just start the daemon without waiting for it to be fully up. This would prevent other failures while providing more information for the sysadmin when he is trying to debug it or do other maintenence.
    – sorin
    Jun 3, 2013 at 10:18
1

As has been said, there is no maximum or configurable startup time for a daemon. If you think the daemon is causing other daemons to be started, you can change its startup sequence at the end.

To debug the problem, I can think of three ways now.

1) Obvious step would be to enable debug logs for the application. I mostly work with RHEL and /etc/sysconfig/<daemon-name> is where the log level can be set.

2) When you manually start the daemon, start it with strace.

strace -ffttTo /tmp/daemon.out /etc/init.d/daemon start

Now in the daemon.out file, observe the time printed at the end of each syscall. That is in microseconds. Figure out the call which consumes most of the time.

When you find that out, again start the daemon and this time with ltrace. Now that you know the offending syscall, figure out at which library it is getting stuck.

3) Write a systemtap script. This one is not so easy unless the user has some experience in writing/debugging with stap.

probe syscall.*
{
( (pid) == target() )
printf("%s\n",name)
}

This will show all the syscalls that the target pid will throw.

NOTE - Don't go for stap in first place. I just mentioned it because it's an awesome debugging tool for kernel and I haven't seen reference of it in the site (or maybe overlooked). You need to get kernel-debuginfo, kernel-debuginfo-common, kernel-devel, systemtap packages installed. Then run the script as

stap <script_name.stp> -x pid

We can further instrument the syscall in question.

http://sourceware.org/systemtap/documentation.html

0

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .