Work at SourceForge, help us to make it a better place! We have an immediate need for a Support Technician in our San Francisco or Denver office.



Tony Asleson

As plug-ins execute in a separate process space as basically a daemon (stdout/stderr closed) with an IPC mechanism, debugging isn't straight forward. To ease the process of squashing bugs the following things are available.

Basic suggestions (language agnostic)

  • Log to syslog for debugging. Not exactly the best method, but for simple quick debugging it may be all you need. Error messages in the library are logged here.

  • Do print statements to a file. Just make sure to disable it before pushing out to others to use.

Python plug-ins

  • If your plug-in is written in python you can execute the plug-in with the same command line parameters as lsmcli. The same python code is used in the command line and the plug-in container. Please note that you should still test your plug-in with lsmcli to make sure that your returned types are correct. Sometimes subtle type mismatches can cause the serialization process in the IPC to fail. Documentation updates and possible code to catch this type of thing earlier are being considered.

C plug-ins

  • If your plug-in is written utilizing the C plug-in library, your debugging options are more limiting. At this point in time you cannot run the plug-in standalone like you can with python. If you want to do source level debugging, compile a debug version of your plug-in and use the environmental variable LSM_DEBUG_PLUGIN. If this is set, lsmcli will pause so that you can connect a debugger to the plug-in process and then continue the operation. This is a little clumsy, but works well.


Wiki: DevelopLibstorageMgmt