Reliability and robustness problems

[John]

Wayne Davison wrote:

>On Mon, Jun 07, 2004 at 07:40:22PM -0700, Wayne Davison wrote:
>  
>
>>So, I'll assume (until shown otherwise) that this is a case of
>>the remote shell still hanging around.
>>    
>>
>
>There's one other possibility I thought of.  You mentioned that your
>kernel has gone around killing processes when memory is low.  If one
>rsync process is just sitting around waiting to be killed by its sibling
>rsync process, but that sibling process got killed before it had a
>chance to generate the "all done" signal, a do-nothing rsync process
>could be left hanging around indefinitely.  This is pretty rare, though,
>as most of the time rsync is actively interacting with the open socket
>and it notices when something goes wrong.
>
>..wayne..
>
>  
>
I don't know....

Kernels at both office and home have done this: most recently it was 
home, but by now I've destroyed the information needed to "know."

On the subject of signals, when rsync dies for any signal-related 
reason, it does not produce the stats.

Most recently this occurred this morning when I very carely chose to 
"kill -HUP" it.

It also misreported the signal as USR1 or INT. Whichever, it could have 
reported the stats.

A stat I don't see is how much memory was used. This would be very 
helpful in estimating what our memory requirements might be, especially 
as I don't see any guidelines elsewhere.

I might also add here that the stats I see seemed targeted at hackers. I 
find them next to incomprehensible and so mostly useless.

Numbers  I do understand include megabytes transfered (accuracy to the 
last byte is meaningless on my runs), transfer speed. Some of these 
numbers are beyond easy comprehension:
Total file size: 1850665035 bytes
Total transferred file size: 3064385 bytes
Literal data: 3065439 bytes

I prefer megabytes, and punctuation.