[Debian-ha-maintainers] Bug#1148221: csync2: large transfers abort on a non-fatal GNUTLS_E_AGAIN

[Kévin DUCHESNE]

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,
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 01-retry-gnutls-again.patch
Type: text/x-patch
Size: 3274 bytes
Desc: not available
URL: <http://alioth-lists.debian.net/pipermail/debian-ha-maintainers/attachments/20260918/ae242979/attachment.bin>