R: [Csync2] Write-error while sending data

[Giampaolo Tomassoni]

Not a word from authors and developers?

Is this patch valid? Should the do ... while() be applied to the "clean" side of WRITE()? Is any testing undergoing with it?

Regards,

giampaolo


> Dears,
> 
> I have a couple of machines loosely connected through an IPSEC 
> channel (racoon) by a couple of ADSL lines.
> 
> These machines actually run linux-2.6.16 from Gentoo.
> 
> I'm using csync2-1.32 to keep the web contents of these two 
> servers in sync and, being my channel well authenticated and 
> encripted by IPSEC, I'm using csync in 'clean' channel mode.
> 
> That said, I sometimes experience a 'Write-error while sending data'.
> 
> I see there was a previous report about this error from Vic 
> Berdin, who started a thread about it on Oct. 25, 2005. That 
> thread seems not have came to find the cause of this trouble, so 
> I tried to dig it my own.
> 
> My findings are that this error is not triggered by a crash of 
> the csync2 peer (how suggested at first by Clifford Wolf in the 
> afore-mentioned thread), instead it is due to a SIGALRM signal 
> interrupting a blocking write on the connection channel.
> 
> -- Begin excerpt from debug logs --
> Local> 
> \252\252\252\252\002\252\252\252\250\n\252\252\252\240*\252\341\32
> 5Of3\\235\037\022B\201\017\253\370\205\355\036\367\314\262\r\207\0
> 26\324\335t\025U~cf\262\367\256\327\323\353:C\002d\006\207R\361\02
> 1O6\215\243\322\313\230\355\307\036\321\217\326\347\352<\243!5}\26
> 4h\033f\000\rK'#2,\022\244\260\\311\221\240\320\303E0\026\364F)\22
> 4\231\265,\333\0334\221\020\307\340\354\0052\001u\214IM\250B7\200\
> 344\324\023T\314\300\016\265N\243\242\311>\337K\321\000\353\023\34
> 6x\204\214\235q\232.\223#G\225\220\271\021\345}\211\364\303\0074K\
> 305\236\244\036\346\343|\203C\270\361r\006\335aN\252f\307\003P1\24
> 2\010\262x>\014\242\351\3138\334-\3461\267\2670\260\363\323\036\24
> 4\256\205\3434]\341\220\300\330<<\321\345\273x\345\210\305\323\017
> U\223\247:\037\223\271\213\234\240\013dA\357a\374G\036AR\024\316^\
> 217\017Sds\342?W\304\022v\307\236X\315\202\372\2757\343\021\231\25
> 1\215\276\327\332\301\324\220.&\303\361\236\220\0018\363\344\351\2
> 17\224\376N\221\226\212\352?\016\226!q\363\007\207\207\326\227\342
> \023\224\255\337\323\305\326\216(\375\357\337C\255\007\221OTd$,?\0
> 37\322\3761\031\212\311\241\361}|9\273\304\265X\313\251\341+\337\3
> 24~\033<Z\307\314\036\016\037i^,}gi=p\234rpm\334\231\201UV\225U\02
> 0UUUU\001UUUT\005UUUP\025UC\022\016\214\220\200\252\253\3158\274\2
> 23\213\350\3126\34184\313B\252\257\235(\261f<=\222\306\343,kRb\205
> U\}Y\016Psx\206\3166\0167<\021\245\231d*\252\347\276%\231H:\0302q\
> 333\237l\332\316\354\025UE\212s%\277L 
> \342\014\366\331}\344*\251\267\236S%\306d\275\207\014|\021\350G
> Database idle in transaction. Forcing COMMIT.
> SQL: COMMIT TRANSACTION
> Write-error while sending data.
> -- End excerpt from debug logs --
> 
> 
> The expiring alarm seems somehow related to committing an active 
> SQL transaction, and it seems to happen more or less 2 secs after 
> the file transfer begins. This means that if you have a fast 
> connection to your peer you may probably never see this error 
> since either your files takes less than 2 seconds to tranfer or 
> the write() enters and leaves the blocking state fast enought to 
> keep low the chance of being interrupted.
> 
> You'll find a small patch attached to this post which seems to 
> fix the problem. It is made with respect to csync2-1.33.
> 
> Note, however, that I'm using a clean connection, so I didn't 
> test it with an ssl one nor I'm that much used to coding with 
> SSL_ calls: I don't know if my patch may even have any meaning in 
> case of SSL channels. So, please, take this patch just as a 
> reference an have a check at it.
> 
> Also note that I don't have an idea of the complete csync2 
> dataflow, so that I can't say whether or not the signal may 
> interrupt even read()s in the code. It seems to work to me, but 
> probably the best thing to do is rework read() and write() code a 
> bit to avoid to be interrupted by signals.
> 
> Regards,
> 
> -----------------------------------
> Giampaolo Tomassoni - IT Consultant
> Piazza VIII Aprile 1948, 4
> I-53044 Chiusi (SI) - Italy
> Ph: +39-0578-21100
>