SFTP connection lost while uploading package

Legacy Execution
1

Hello!

I’m attempting to do the first deploying with Octopus, to a SSH target.
What I want, for now, is simple: just copy, using sftp, the package from Octopus built-in repo to my CentOS 7 machine and unzip it in a specific directory.
I decided to run with self-contained Calamari and ran into some trouble at first: needed to install libunwind and set the System.Globalization.Invariant to true.
Now the deployment is stopping because of: SFPT connection lost while “Acquire Packages”.

tempsnip
tempsnip.png1358×523 34.1 KB

I tried to set on the target machine the following ssh options:
TCPKeepAlive no
ClientAliveInterval 30
ClientAliveMaxCount 240
with no effect.

The exception in the full log is:

tempsnip2
tempsnip2.png1590×251 16.5 KB

What can I do to fix the problem, cause I ran out of ideas.

Thank you,
Victor Stanescu

2

Hi Victor,

Can you check your the SSH target’s system and sshd logs for any clues as to why the connection was close? Did the process crash? A firewall rule kick in?

Also are there any message between those yellow retry message if you switch on verbose?

Does this always happen?
What happens if you use a smaller package?
Do you have other SSH deployments that work?

If you are able, could you direct message (click on my name) a raw log?

Which version of Octopus are you using?

3

Hi Robert,

  1. I checked my SSH logs on the target system and didn’t see anything that could help.
    Here is the log:

    image
    image.png1038×481 24.6 KB

  2. If by process you mean the sshd process on target machine, no it didn’t crash.

  3. I doubt the firewall kicked in, the target machine is a minimal clean install of CentOS 7. From my workstation, that also hosts the target machine with bridge network enabled, I was able to transfer the same archive via sftp.

  4. The verbose messages between the yellow retry messages are the .NET stack trace from the exception I posted in the first place.

  5. Yes it happens everytime I try.

  6. Looks like it works with a way smaller package (119 B).

  7. I do not.

  8. I will send you the raw log.

  9. 2018.2.6

4

Hi Victor,

From the logs I can see that the connection is closed every time after about 20 seconds. Very regular. I have tried to reproduce this error using a CentOS VM in Azure, but it works fine for me.

Could you try setting the ClientAliveInterval to say 10 and TCPKeepAlive to yes. Also try setting the ServerAliveInterval to 10.

Also try just a script step (no package) but doing an operation that takes longer than 20 seconds, does it still close the connection?

Chances are it’s something to do with the bridge network, the HyperV one on Windows 10 is notorious for being flakey.

5

It worked by setting the ClientAliveInterval to 10 and TCPKeepAlive to yes.
It may be the cause that the package takes a long time to come from one country to another. Won’t be the case in production, it should be much faster.

Note: I’m not using HyperV, but VirtualBox.

It worked now as a proof of concept and it’s clear to me it wasn’t something wrong with Octopus setup.
Thanks a lot Robert!

1 Like
6

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.