As we all know, when working with HP SM, get debug trace is one of the most important method to have a detail view of the problem / issue. Enable the parameters to generate debug log will give us the clearly flow about how the system running from behind, then from that, we can check and find the rootcause of the issue easily.
This post will list several options to get the debug trace. Depend on each situation of the cases, you can choose the relevant option to get the log. Lets start !
Option 1: add the parameters to sm.ini
We can call this option is basically option , all we need to do is: adding the debug parameters to sm.ini, then take the restart of sm service before logging in to the system to reproduce the issue
Note: from the RTE version 9.32 and later, you don’t need to restart the sm.ini after added the parameters
- Open sm.ini (RUN/sm.ini) with text editor ( I prefer Notepad++)
- Add the following parameters:
- Save changes (restart sm.ini if required)
- Login to SM and reproduce the issue. If need, you need to clear the content of sm.log before replicate the issue.
- Get the sm.log (logs folder) and start investigating
This way I often use in a single system, TEST machine or in a case that the issue is intermittent. Because all the trace will be written in sm.log and it may cause the performance issue or consume high storage.
Option 2: add the debug servlet to sm.cfg
This way I usually use when working on integration case , load balancing system,..
This method will write the trace into one dedicated log from dedicated port (servlet) so that it will not have any impact to system’s performance or configuration
- open sm.cfg (RUN/sm.cfg)
- add the following command: sm -httpPort:12345 -httpsPort:12346 -RTM:3 -debugdbquery:999 -debugnode:1 -log:12345.log
- save the file, we have to restart the sm service after that.
- Login to system with port 12345, start reproducing the issue.
The above command will create the new servlet ( aka: port) number 12345. The parameter debugnode:1 will keep this port secretly (dedicated port), that means it will not be shared in LoadBalancing system. This option actually is very good to generate the trace without getting more unuseful information from the log
Option 3: run the debug servlet from command prompt (cmd)
This is the most common way we always use to get the log when working on customer’s case. No need to restart the sm service, no need to add anything in the configure file. That’s the advantage of this option.
- open the CMD ( with administration mode if needed)
- CD ( redirect to RUN folder of SM), then type MANUALLY the command: sm -httpPort:12345 -httpsPort:12346 -RTM:3 -debugdbquery:999 -debugnode:1 -log:12345.log
- Wait for about 10-20 seconds, connect to SM with port 12345 then replicate the error
Note: using this way, we need to type manually the command to avoid any typo if we copy and paste it into cmd windows.
Option 4: enable the rtm trace in system status ( applicable from App 9.31 and later)
The last and the interesting steps is enabling the debug inside Service Manager. This is the steps that I learnt while I was working with one of the RnD engineer in my cases.
The good idea of this option is we can inject the debug to the currently logged in session , from system status window. so no need to type any command line, and the trace will got wrote in sm.log
- Just login to SM with admin user (falcon of course)
- go to system status ( you can type status on command or just double click on menu System Status.
- Look at the user that you need to generate the trace at the window that displaying
4. Type “s” and click Execute Commands. The send message window will showing up. Just click at Send Debug Msg button
5. Here you can set the RTM option , debugdbquery (sqldebug, debughttp,.. if needed), its more easier than typing the command or restart the sm service