Job run errors - Did not receive port from client process

PowerShell Universal Universal Automation
1 
Product: PowerShell Universal
Version: 2.3.1

I’ve seen multiple instances of this error in forum lookup, but it doesn’t seem to show any resolution to this problem in most of these cases. I am starting jobs via API call, and the main script will also start up some subscripts. Some jobs are failing with the error “Error executing job: Did not receive port from client process”. There does not seem to be any rhyme or reason to the errors, meaning that if I run my test to start a batch of jobs I can have all success except for one run, or the majority of the script runs will fail out on another run.

Per what I saw in one of the other threads, I enabled job debugging and did my best to capture the section of code after one job erroring to another job starting. Hopefully this will be of help for finding the problem.

2

I’ve seem this most frequently when many jobs are started at once. I was working with another user that was starting 100s of jobs from an external process and via the API.

What’s happening is that the system is quickly creating new PowerShell processes and as that happens it starts to bog down and they don’t respond in time. The default timeout for job processes is 10 seconds and is configurable in appsettings.json under the UniversalAutomation section.

You can try to increase that timeout to avoid this but it it’s a bit finicky to get right.

What I would recommend is that if you are starting many jobs at once is to lower the Concurrent Job Limit setting in General \ Settings. Once it hits the limit, it will begin queueing jobs. This won’t start a bunch of PS processes all at once and will allow for jobs to process at a reasonable pace.

3

i’ve actually got the concurrent jobs sitting at 3 for both the main script and the 2 sub scripts that it calls. Funny enough, UA’s concurrent job functionality is why i’m moving this process off from Azure Automation runbooks.

So at any given point in time only 6 would be running. I think what I may do in my particular instance is just insert a pause of 500ms between each api call and see how that behaves. my test is also not accurate of what production will be, as right now my subscripts are just spitting output data without actually performing any actions, which would normally take a few minutes at least to run through.