Summary
I have a remote machine which OS is not supported directly by CloudBees CD (CloudBees Flow) installation.
So, I configured proxy agent and connect it to that machine, but sometimes I would like to get debug log at that machine but it’s unavailable with default configuration of proxy agent.
How can I turn on this debug log?
Solution
In short, ECPROXY_DEBUGFILE should be enabled to turn on this debug log.
Pre-4.2, you’d set this variable in the agent’s runAgent.sh script (or runAgent.bat on Windows).
The value of the variable should be a file name prefix. For example, "ecproxy.log.".
When ecproxy runs, it will see that environment variable, take the current job step’s id, and append it to the file-name prefix.
That’s why the trailing period is useful — you end up with file names like ecproxy.log.1234 (for pre-5.0, where id’s were integers; in 5.0+ you will end up with a somewhat longer filename, but it’s still unique and that’s what matters).
As of 4.2 and the Java agent, the agent uses the Java Service Wrapper to start the Java agent, which in turn starts the C++ agent, etc.
In that setup, you need to modify the Java agent’s wrapper.conf to set the environment variable there like below:
set.ECPROXY_DEBUGFILE=ecproxy.log
at /opt/electriccloud/electriccommander/conf/agent/wrapper.conf
This configuration must be done on every agent that you’re proxying through (e.g. If you define a proxy resource that proxies commands through real agent host lin7 to reach target aix1, you must update the wrapper.conf for the agent running on lin7).
An alternative way to accomplish the same thing is to modify ecproxy.pl on those agent machines to set the environment variable near the top of the script (before any other part of the script tries to access it).
The benefit of that approach is that you don’t have to restart the agent service; the down-side is that technically you’re modifying code, not config in that case.
The ecproxy debug log file will be written in the workspace directory, same as regular step logs. With the job-step-id being included in the file name, you’re guaranteed to have a unique name that won’t collide with other steps in the build (which might also be running proxy steps with debug logging).
In short, ECPROXY_DEBUGFILE should be enabled to turn on this debug log.
Pre-4.2, you’d set this variable in the agent’s runAgent.sh script (or runAgent.bat on Windows).
The value of the variable should be a file name prefix. For example, "ecproxy.log.".
When ecproxy runs, it will see that environment variable, take the current job step’s id, and append it to the file-name prefix.
That’s why the trailing period is useful — you end up with file names like ecproxy.log.1234 (for pre-5.0, where id’s were integers; in 5.0+ you will end up with a somewhat longer filename, but it’s still unique and that’s what matters).
As of 4.2 and the Java agent, the agent uses the Java Service Wrapper to start the Java agent, which in turn starts the C++ agent, etc.
In that setup, you need to modify the Java agent’s wrapper.conf to set the environment variable there like below:
set.ECPROXY_DEBUGFILE=ecproxy.log
at /opt/electriccloud/electriccommander/conf/agent/wrapper.conf
This configuration must be done on every agent that you’re proxying through (e.g. If you define a proxy resource that proxies commands through real agent host lin7 to reach target aix1, you must update the wrapper.conf for the agent running on lin7).
An alternative way to accomplish the same thing is to modify ecproxy.pl on those agent machines to set the environment variable near the top of the script (before any other part of the script tries to access it).
The benefit of that approach is that you don’t have to restart the agent service; the down-side is that technically you’re modifying code, not config in that case.
The ecproxy debug log file will be written in the workspace directory, same as regular step logs. With the job-step-id being included in the file name, you’re guaranteed to have a unique name that won’t collide with other steps in the build (which might also be running proxy steps with debug logging).