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