Troubleshooting
Check the debug logsSometimes, the answers are fairly easy to find. Usually, when Caudium runs into problems, it will dump backtraces into the debug log (usually logs/debug/default.1). This file is always a good first place to look for answers.Thread DumpTo trigger a thread status dump (sort of like a backtrace for each running thread), you can perform the following:
Sending this signal to Caudium should cause the current thread state to be written to the default debug log (usually logs/debug/default.1). This is often very helpful for seeing what each thread is up to, and may provide clues to the problem.Attach GDB to the processProblems deeper down in the C level code may require the use of a debugger. GDB allows users to debug a running process.http://www.delorie.com/gnu/docs/gdb/gdb_23.htmlOf particular interest is the current call stack, which when observed over time, can provide details about many types of C level problems.Running a system call traceMost UNIX-like operating systems provide a facility for inspecting system calls made by a process in real time. This can often be useful in tracking down I/O related problems.
- Solaris users can use "truss" or "dtrace" (Solaris 10+)
- Darwin and OSX users can use "ktrace" or "dtrace" (OSX 10.5+)
- BSD users can use "ktrace"
- Linux users can use "strace"
Powered by PikeWiki2
|
|