Plugins run on the Web Server as the Web Server user using the session ID of the user who is logged into Flow through the Web UI.
You want to see what is happening at the Web Server level when the SCM plugin does not work.
Or you are having an ectool connection problem and you want to know the details of communication to the server.
This article shows several debug techniques used for enhanced Flow debug.
If you place text "&debug=1" on the end of URL when on the "Admin->Source Control" page, additional information is provided in the browser output.
This is a one shot debug as the web server drops the debug unless it is entered by hand on the next URL.
Consider the following:
- Debug CGI messages are placed on the screen.
- Plugins use jobs to carry out some functionality. The job created by the CGI will not be automatically deleted so it can be inspected post CGI operation.
The normal access.log information show the total elapsed time of each Web Server request. Each request is made up of sub-requests for data.
By turning on traceRequests in config.php the apache error.log file will have an entry for each web server sub-request. These message sub-requests can be directly correlated to the commander.log request for data. The sub-requests can now be used to find out the operational time syncs.
Modify config.php to contain the following line:
After your tests, remove the traceRequests entry as there are voluminous messages placed in error.log which will eventually fill up the disk because error.log does not roll over.
Use "ecclientpreflight --debug" to create extra step log output that is useful for analyzing problems.
- Use "ectool --debug 1" to create extra output that is useful for analyzing problems. The information will include:
- the server communication messages
- You can change the ElectricCommander.pm package on an agent to have all ectool commands run in debug mode
- look for code of the form
- and just update it:
- run the test and then restore ElectricCommander.pm to it's original state.
- look for code of the form
- Use debug 1 when starting perl to create extra output that is useful for analyzing problems. The following perl code fragment will print to the screen perl debug messages.
my $ec =
my $xPath = $ec->getProperty(
- use the following modification to output the messages to a file:
my $ec =
, logFile =>
- when running ec-perl in a step the output file can be named as follows:
Get the property value using ectool with the explicit context of a known job or workflow. For example:
ectool setProperty /projects[testing]/job_steps --value
--workflowName workflow_1_201102011936 --projectName A --stateName Ystate
A Few Agent Debugging Tips
Each Command step runs on the agent in a separate shell instance - so Environment variables set in one Command step will not be effective in the following steps. Environment variables need to be set for each step they are needed in, or made in the startup scripts for the user used by the agent.
By default, the commands in a Command step are run as the user that the agent was installed as, unless Impersonation is used.
To determine why a step may run successfully on one agent and not another, the first thing to do is run a step to gather environment information, with commands such as "whoami", and "env". These are useful if you are getting an error indicating a program is not found in the path.
Running Multiple Commands in a single Flow Step
When running multiple shell commands within a single Flow Step, the return code will be for the final command in the list of commands. So if you have the following comands in your Flow Step:
If the first line fails, but the second line succeeds, there status on the step will be Success. The status is only reported on the last command that is run. Running each command in its own step, or creating a script with error checking is the best way to handle this if running multiple commands in a single Flow is important to your process.