Administer > Status and notifications > Dynamic debugging of user sessions or schedulers

Dynamic debugging of user sessions or schedulers

The dynamic debugging feature enables administrators to enable or disable the debugging or tracing information for a user/scheduler session, without the need to restart the server. When enabled, relevant debugging information of that session/scheduler will be written to the server log (sm.log). Once you have finished troubleshooting, you can then disable some debugging information for that user session or scheduler, using dynamic debugging; however some debugging information cannot be disabled using dynamic debugging, and in this case the user needs to reconnect to the server or an administrator needs to manually stop and then restart the scheduler, to disable such debugging information.

Caution If multiple sessions exist for one user account or scheduler (for example, one user logs in simultaneously from different clients or multiple instances of one scheduler have been started), the dynamic debugging settings specified for one of these sessions will take effect for all of the sessions of this user account or scheduler.

Dynamic debugging supported parameters

The following table lists the debugging parameters that can be enabled and disabled or can only be enabled in dynamic debugging.

Parameters can be enabled and disabled in dynamic debugging Parameters can be enabled but cannot be disabled in dynamic debugging
dbmonitorfiles: [file1],[file2]… dbtriggertrace
debugca:n dbstats
debughttp debugattachments
debugdiagnostics debugjni
debugscauto debugjavascript
debugvmmap debugadhocsql
debuglk debugfileio
debugstartup debugshutdown
debugrs debugprocesses
ir_trace debugdbtypes
rtm debugdbquery
sqldebug  

Note Once you have completed debugging of a user session or scheduler using any of those parameters that cannot be disabled in dynamic debugging, you are recommended to re-connect the session or restart the scheduler to disable the parameters.

Set debugging parameters using dynamic debugging

Applies to User roles: System Administrator

Note Some debugging parameters can be enabled and disabled using the dynamic debugging feature, while some can be enabled but cannot be disabled using this feature. For more information about these parameters, see Dynamic debugging of user sessions or schedulers.

To set debugging parameters for a user session or scheduler, follow these steps:

  1. Click System Status. The system status form opens.
  2. Type the following command in the Command field for the user session or scheduler:
    s
  3. Click Execute Commands.

    The Operator Status Display form (operator.status.g) opens.

  4. Click Send Debug Msg. The Send Debug Message form opens.
  5. Set debugging parameters as needed. The following figure shows an example.

  6. Click Send Debug Message. A message is displayed: Message sent to all users specified.

  7. Click End to exit.

  8. Check the server log file for relevant debugging information of the session or scheduler.

  9. Once you have completed troubleshooting, you are recommended to disable the debugging parameters for the user session or scheduler. To do this, repeat the steps above and disable the parameters.

    Note Some parameters cannot be disabled using dynamic debugging. To disable such debugging information, disconnect the user session or manually restart the scheduler.

Alternatively, you can send the dynamic debugging message using Service Manager JavaScript. To do this, follow these steps:

  1. Click Tailoring > Script Library.
  2. Add a new debugging JavaScript using the following format:

    var debugmsg="<parameter> log:<directory and log file name>";
    var rc=system.functions.rtecall("setdebug",vars.$L_rc, debugmsg );
    

    You can specify one or more space-delimited parameters in debugmsg. In addition, you can also customize the output directory and the log file name for the debugging messages. If log:<directory and log file name> is omitted, the system outputs the debugging messages to the default server log file (sm.log).

    In the following example, the system writes debug messages about RDBMS connections of the current session and prints this information to the mysm.log file:

    var debugmsg="sqldebug:1 log:../logs/mysm.log";
    var rc=system.functions.rtecall("setdebug",vars.$L_rc, debugmsg );
    print(rc)
    

    In the following example, the system writes debug messages about RDBMS connections and Response Time Monitor (RTM) performance statistics of the current session and prints this information to the sm.log file.

    var debugmsg="sqldebug:1 rtm:3";
    var rc=system.functions.rtecall("setdebug",vars.$L_rc, debugmsg );
    print(rc)
    
  3. Click Execute, and then click OK to exit.

    Note Your changes affect the current session only. The debugging process starts immediately after you executed the JavaScript.

  4. Check the log file for relevant debugging information of the session or scheduler.