sFTP Publishing issues: Error in SSH Layer

Hi

For the last few days I’ve had publishing errors using sFTP.
The site details are fine as I’ve been using them since 2012 - and the first 200 or so files in upload work fine. But eventually I get messages similar to those below.

  • I’m using the most up to date version of Rapidweaver (8.2.1 Build 20758).
  • MacOS version is 10.14.5.
  • My hosting is through iPage who I’ve been using for a long while (not perfect but generally reliable)
  • My default Rapidweaver publishing is set to 4-Fast, but the the problem also still occurs even when I drop it down to 2-Slow.

There have been no recent updates to my system except some standard MacOS updates about two weeks ago … although this SSH problem only began a few days ago.

Has anyone else been experiencing problems recently (e.g if there’s been a recent RW or MacOS update) or maybe has had similar issues in the past? I’ve raised a ticket with my hosting support but thought I’d try this angle too.

Cheers
Andrew Mercer

Andrew,

Does your ~/.ssh/known_hosts look right?

Can you connect to the site’s (web) server with ssh from the command line?

1 Like

Thanks - yes.

Connectivity looks fine. Generally about 200 files (of 400 approx) get transferred successfully. I can upload if I break things into 2-3 batches. I can also upload if I export to a folder then manually upload using CyberDuck and sFTP.

It seems to be that using “4 - Fast” (which I assume is four channels): each channel opens a connection and logins, uploads a file, then disconnects, and repeats the process again with the next file.
I’m guessing (based on past experience in the database world) that maybe there’s a maximum number of connections - and that the closed connections aren’t fully closed (on either the Mac or the server end). Therefore, midway though publishing, RW’s publisher is reaching this maximum connection limit and is unable to open anything new. That’s just an educated guess though. And, if that is the problem, I don’t know if the culprit is RW, MacOS (there were a bunch of security updates recently from Apple) or my hosting. It’s easy just to blame the hosts … but there could be those other factors on my side, hence its good to see if anyone else has had problems.

If it helps, I got the following in RW’s Support logs:

2019-07-01 22:17:21.695 RapidWeaver 8[12135:12364053] RW 8.2.1 (20758) LAUNCHED (2019-07-01 12:17:21 +0000) macOS 10.14.5
2019-07-01 22:17:21.695 RapidWeaver 8[12135:12364053] Log files have been cleared
2019-07-01 22:17:24.293 RapidWeaver 8[12135:12364053] Starting Site Publish
2019-07-01 22:17:24.294 RapidWeaver 8[12135:12364053] Starting Project Save
. . . (lots of stuff) . . .
[15] Re-using existing connection! (#0) with host ftp.myhost.com
[15] Connected to ftp.myhost.com (61.97.142.163) port 2222 (#0)
[15] We are completely uploaded and fine
[15] Failed to close libssh2 file: -43 Error waiting for status message
[15] Sending quote commands
[15] rm command failed: Unknown error in libssh2
[15] Connection #0 to host ftp.myhost.com left intact
2019-07-01 23:20:02.123 RapidWeaver 8[12135:12420821] [13] Found bundle for host ftp.myhost.com: 0x600013f180c0 [serially]
[13] Re-using existing connection! (#0) with host ftp.myhost.com
[13] Connected to ftp.myhost.com (61.97.142.163) port 2222 (#0)
[13] We are completely uploaded and fine
[13] Failed to close libssh2 file: -43 Error waiting for status message
[13] Connection #0 to host ftp.myhost.com left intact
2019-07-01 23:20:02.581 RapidWeaver 8[12135:12420792] [14] Found bundle for host ftp.myhost.com0x600013f1abe0 [serially]
[14] Re-using existing connection! (#0) with host ftp.myhost.com
[14] Connected to ftp.myhost.com (61.97.142.163) port 2222 (#0)
[14] We are completely uploaded and fine
[14] Sending quote commands
[14] Connection #0 to host ftp.myhost.com left intact
2019-07-01 23:20:04.224 RapidWeaver 8[12135:12420932] [16] Found bundle for host ftp.myhost.com: 0x600013f2ee50 [serially]
[16] Re-using existing connection! (#0) with host ftp.myhost.com
[16] Connected to ftp.myhost.com (61.97.142.163) port 2222 (#0)
[16] Sending quote commands
[16] PWD
[16] 257 “/en/wildlife/birds/egret_files/” is current directory.
[16] Connection #0 to host ftp.myhost.com left intact
2019-07-01 23:20:04.236 RapidWeaver 8[12135:12364053] Starting Project Save
2019-07-01 23:20:04.237 RapidWeaver 8[12135:12420935] Saving project file to ‘file:///var/folders/tr/chqlkxgs1zd6dlx1cnyyt2hh0000gn/T/com.realmacsoftware.rapidweaver8/TemporaryItems/(A%20Document%20Being%20Saved%20By%20RapidWeaver%208)/Pantanal%20Escapes%20Redesign.rw8’ original contents url ‘file:///Users/andrew/Local%20Docs/Web%20Development/SItes/Pantanal%20Escapes%20Redesign.rw8/’
2019-07-01 23:20:08.080 RapidWeaver 8[12135:12364053] Finished Project Save error:(null)

Andrew,

There are a number of threads here and pages like this one which suggest trouble-shooting steps for publishing. Though I suspect you’ve tried all of that :slight_smile: .

I did use iPage once. Without casting aspersions, I wasn’t very impressed. It may be - as you say - that they are throttling your connections. In which case it should work with a setting of ‘1’, slow though that will be.

I have a feeling that your conclusions about failed closed connections may be spot on. I’d try leaning on iPage a bit more heavily - perhaps with those quite telling log lines:

libssh2 file: -43 Error waiting for status message

[15] rm command failed: Unknown error in libssh2

It does look as though you’re getting (unexpected) time outs. iPage ought to be able to tell you why. Good luck!

How annoying :frowning: .

1 Like

Thanks Mark.
That was really helpful. I’ll do some polite leaning on iPage support. Like most support teams these days they’re just going through a script … the more info I can give them the better.

Cheers

Andrew; good luck! Yes, you’re the customer. Maybe ask whether they do throttle, and would they consult their own logs. Do let us know how you get on :slight_smile: !

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