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.
-- To unsubscribe or change options: http://lists.samba.org/mailman/listinfo/rsync Before posting, read: http://www.catb.org/~esr/faqs/smart-questions.html
