Package: csync2
Version: 2.0-42-g83b3644-3
Severity: important
Tags: patch upstream
Hi,
Following up on our mail exchange here is the report you asked for.
On a GnuTLS build, a large synchronisation never finishes in one run. It aborts
after roughly 7.4 GiB moved over a single connection, with
Read-error while receiving data. # receiving node
Write-error while sending data. # sending node
and resumes where it stopped on the next run. Pushing ~31 GB / 56k files to two
peers took seven runs of csync2 to converge.
What ruled out a flaky link is that the abort point is deterministic: 8.0 GB,
then 15.4 GB, then 22.9 GB transferred, the same figures on two different peers
and again after rebuilding the package from source.
I patched READ() and WRITE() in conn.c to log what GnuTLS actually returns
before csync2 gives up. Both ends report the same thing:
sender: rc=-28 (Resource temporarily unavailable, try again.) count=512
receiver: rc=-28 (Resource temporarily unavailable, try again.) fatal=0
count=512
-28 is GNUTLS_E_AGAIN, and gnutls_error_is_fatal() returns 0 for it. csync2
passes the negative return up the stack anyway: conn_read() turns it into a
short read and csync_recv_file() calls csync_fatal(), while on the other side
csync_send_file() sees rc != chunk and does the same.
Worth noting because it cost me a test run: patching only the sending side
changes nothing at all, same seven runs, same thresholds, because the receive
path then aborts on the identical condition. Both need fixing.
With both patched, the same 31.66 GB to two peers goes through in a single run,
1938 s, no aborts. I verified the result each time by comparing an md5 digest
of the whole tree on all three nodes.
The patch is attached (DEP-3 header included). It applies to the packaging
source as-is, and to current upstream master (253bfc48) with offsets of +3 and
-4 lines.
Reported upstream as https://github.com/LINBIT/csync2/issues/45. Another user
has since confirmed there that the bug matches long-standing trouble they had
with large files, and that building with the patch fixes it for them.
Also worth mentioning while you are looking at the package: the security
tracker still lists trixie as open for CVE-2026-41051, fixed from -6 onwards.
Happy to test anything else, I still have the three-node setup.
Regards,
w4zu <[email protected]>
