replication of discovery servers

Hello, I use syncthing for about two years, very happy with the overal result, never bumped into a hard stop bug not solvable by restart of service. You rock compared to many other softwares…but

My setup is rather complicated, I have three locations behind different NATs different providers… We have a VPN and one single machine with fixed IP there, so we have to use discovery and global discovery would be useless without relay… We have disco server(s) to solve the mess using private IPs. Since I upgraded from v12 to 14 yesterday, I should be able to have more than one disco server to ensure syncing inside one of the places and the rest even when internet glitches.

While everything went better after the upgrade (most of the time all machines see each other), I bumped into hard stop when it comes to replication of disco servers. I have a windows server based P2P VPN inside the “big” openvpn. This connections allows me to have fixed IPs on both W servers for their communication. It handles domain sync and every other communication I ever wanted from it, just not disco replication. Problem persist even with both firewalls down.

I get these two messages, always one on one end and other on other…

Replication write: write tcp> wsasend: An established connection was aborted by the software in your host machine. Supervisor main: main: Failed service ‘replicationSender(“”)’ (1.000000 failures of 5.000000), restarting: true, error: "{replicationSender (“”) replicationSender(“”)} returned unexpectedly", stacktrace: [unknown stack trace]

Replication read size: read tcp> i/ o timeout

Command lines to start those:


stdiscosrv v0.14.48 (go1.10.3 windows-amd64) link???edit 2018-05-14 06:53:06 UTC Server device ID is TW7PEJB-XZQ6NAL-PMSZNXD-BE4WIFL-Y56BC63-JZMYR7W-RWXEIWT-7VA5FAA


stdiscosrv v0.14.48 (go1.10.3 windows-amd64) link???edit 2018-05-14 06:53:06 UTC Server device ID is BD2CHVY-TKEBOEX-ZXECI5V-UGGGRJL-JEQQ2AF-TZDTTSN-Q435QBS-Y3DFJAU

I made those lines using the guide on syncthing pages and did not find similar trouble using google in this or any other forum - so I suppose I misunderstood something.

Why do you need discovery replication?

Regardless of that, the error is simply that there is no data to replicate. Replication was built for the public servers. Not reading a replication record in one minute is interpreted as a failure and the replication connection is restarted. This won’t work well with low volume servers.

You could patch it to increase or remove the timeout to solve the complaints.

1 Like

Audrius) I dont know whether I really need it, in fact, it works as a charm even with this issue. I use two because (a) I need to have everything in one site synced even if internet line is down (b) I need everything ontside this site synced even if that site’s internet is down. Well, I am geek, there is a safe looking option, I try it :slight_smile:

calmh) I dont know whether there is anything to replicate, both servers are configured in all (up to 7) nodes, so theoretically both should have complete set, just with some differencies in IPs due to complicated NATing thru the VPN. Building it is behind my abilities. I happy to know that it is not a connection problem.

Just to make sure I understand you: in the minute there was no update on the side that was read gives this message. If I have more than one minute without this message, it means that there were some updates going thru.

Thans for extra fast response to both of you

Correct. When replication is on, any announcement from a device is also sent to the replication peer, so sometimes you’ll have a few records replicated.

This is used in the public setup to have multiple servers with load balancing, who can all handle announces and answer queries equally, without the clients needing to repeat their announce or query.

1 Like

Thanks a lot, I will ignore the message.

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