If I am reading this correctly, you are able to run
ectool getProjects from the command line on a Linux agent, but you are not able to run this same command from a Procedure-Command step in the UI. Is that correct?
If I assume it is correct, I have two places to start (1) workspaces and (2) ports.
The diagnostic activity I have done is to run a few tests on the agent. First -
echo "hello world" as a command step to establish basic communication. Next,
ectool getProjects with no impersonation to establish ectool behavior. Next, the impersonation. If the first (hello world) fails, then
When I have seen this type of problem before, where the jobstep just hangs and doesn't provide output, it was related to a workspace problem on the agent. In those cases, the agent is using a workspace that is not available to it - either permissions or the reference is wrong. One common example is if your agent does not have permission to access the workspace that is hosted on a server. It may be that your agent was configured to use a local workspace and that was turned off. Local workspaces are paths that are specific to the agent, usually a local drive, and the agent will serve-up log files and related as demanded.
If it is a port issue, it is typically because the port 7800 (default communication) was not setup to be bi-directional. ElectricCommander Server-Agent communication starts with the server sending instructions to the agent, and then disconnecting. Later, when the agent is complete, the agent initiates communication with the server and provides results. Many make the mistake of assuming the server only requires outbound and the agent only requires inbound because communication is kept open. This is not true. This requires port 7800 to allow both incoming and outgoing traffic on all participating machines (server and agents).
Please let us know if this information helps.