Archive for April, 2010

Debugging Components

April 5, 2010

It can be tricky to debug any program, and doubly so for a program that is started within the purview of a framework (like browser plugins for example) since it can be hard to use “printfs” when there is no clear console output, and it can be hard to connect a debugger. OpenSAF components are no exception.

ARRG! It reboots!

The number one first thing to do it remove that pesky reboot! Edit the file:
and comment out the /sbin/shutdwon and /sbin/reboot lines.


The first thing to remember is that the stdout and stderr of your programs ARE going somewhere — you just have to figure out where that is!
The default “distribution” of OpenSAF logs to three places:

/var/log/messages — this is where you would look for errors relating to the OpenSAF system itself. I recommend running “tail -f /var/log/messages” in a separate xterm.

/var/lib/opensaf/stdouts — this directory contains the console printouts of each OpenSAF program and the programs that OpenSAF spawns. Note that this is not the place for YOUR program’s output because OpenSAF actually starts a helper script which then starts your program.

/var/opt/ — Your program’s output. The default helper script sticks your program’s logs here. However, note that this destination is very easy to modify so it may be different in your system.

This command will search all of these areas for any logs relating to your component. Of course you must replace YourCompName with the name of your component (as defined in the imm.xml file).
grep -i “YourCompName” /var/lib/opensaf/stdouts/* /var/log/messages /var/opt/*

Debugging startup issues

There are 3 possible locations for the problem:
1. AMF may not be starting your program. For example, the executable in the imm.xml file may not exist.
2. Your program’s startup script.
3. The initialization code for your program itself.

Run outside OpenSAF AMF

Another option is to run your program outside of the OpenSAF AMF high availability framework. As long as OpenSAF is running, a program that is linked with the appropriate libraries can be run on the command line and still utilise all the SAF services except AMF. This is very convenient during the development phase because it means that you can run your program under GDB using normal development/debug methodologies.

To do this, you need to rip out all the saAmf* calls, the active/standby callback handlers, etc and just start your stuff going from the “main” routine. In fact, it might make more sense to make “fake” calls to your active/standby handlers directly from the “main” routine (or another thread) rather than rip all this out!