Octopus cannot connect to worker on SSH when the Runbook starts by trigger

Octopus cannot connect to worker on SSH when the Runbook starts by trigger.
The worker is Octopus Server itself.

I have some Runbook and it works when i run it manually by pressing “Run” button.
Unfortunately when i set Runbook trigger, it does not work.
Here is the error:

09:35:06 Fatal | The step failed: Activity compare_sha_latest on a Worker failed with error ‘Could not connect to SSH endpoint: Connection reset by peer
| Connection reset by peer’.

Attached file with the full log.

Thank you,
Andrey
ssh_connection_error (13.5 KB)

Hi Andrey,

Thanks for getting in touch! I’m sorry to see you’re hitting this unexpected behavior. I ran through a test locally setting a trigger in my project to kick off a runbook that runs on an SSH target, which was successful. If it’s okay, I’d like to gather some more information to hopefully work out a more accurate reproduction, specifically more details about your trigger, along with the runbook process JSON which you can download in the UI as shown below.

I look forward to hearing back and getting to the bottom of this one!

Best regards,

Kenny

Thank you for the reply @Kenneth_Bates ,

When i think about it now, we have couple of triggered runbooks that runs every 5 minutes on the same worker.
That means 3 or 4 runbooks triggered on the same time and do the same job(pull the latest image sha from ECR) but for the different repository.

I checked with one trigger and one runbook, it works as expected.
So i have question:
Can octopus worker execute more than one task at the same time?

Hi @andreybyhalenko!

Just jumping in for @Kenneth_Bates, as he’s offline as a member of our Australian-based team.

Octopus can run multiple tasks at once on a worker, so there’s no problems in that regard. Judging from the error though, it looks like something environmental that’s terminating the connection. I’ve seen things like fail2ban and other security software on the linux machine terminate multiple connection attempts in the past - is it possible that might be the scenario here? Another place to look is the sshd logs (usually sudo systemctl status ssh) on the machine, to see if anything is being logged there.

I hope this helps move your investigation forward, and please let us know if you have any further questions!