Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Too many znapzend destinations cause SSH error #582

Open
nahall opened this issue Aug 5, 2022 · 0 comments
Open

Too many znapzend destinations cause SSH error #582

nahall opened this issue Aug 5, 2022 · 0 comments
Labels

Comments

@nahall
Copy link
Contributor

nahall commented Aug 5, 2022

I've been using znapzend for many years and have 17 backup plans, each going to 2 destinations on the same server, so 34 connections to the same server. I recently added "--mailErrorSummaryTo=root" to my config and found that several times per day I was getting errors on random plans. But many times it completed successfully.

The znapzend debug log contained

kex_exchange_identification: read: Connection reset by peer
Connection reset by 10.20.0.33 port 22

I checked the server's auth.log for the same time and found when this happened:

sshd[4301]: error: beginning MaxStartups throttling
sshd[4301]: drop connection #10 from xxxxx on xxxxx past MaxStartups

The default MaxStartups for sshd is 10:30:100, so if more than 10 connections are attempted to be established simultaneously, it drops additional ones with a 30% probability. So that is why it was working in some cases but not others.

I have subsequently modified the server's /etc/ssh/sshd_config to contain:

MaxStartups 40:30:100

This seems to have fixed the problem, however, it is not the ideal solution to have to modify a server's sshd_config that isn't even running znapzend. It seems like it would be better to modify znapzend so it doesn't attempt to open every ssh connection simultaneously.

Before I added --mailErrorSummaryTo it appears as though this happened several times every day, but I just didn't notice because the backup would then usually be successful within an hour or two, due to the randomness of MaxStartups. But adding that error notification has brought this issue to light.

@oetiker oetiker added the bug label Aug 8, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

2 participants