I have a launchd job that runs a little shell bash script for some
rsync backup action. I'm running 10.4.9 with the latest Security
Update (and as far as I can tell, the extended attributes and ACLs
that I need are being copied properly, so 2007-005 did seem to fix
whatever 004 broke). The script
indeed this is what I reported back to the list as soon as 2007-05
came out.
backs up several AFP share points with a total of about 140GB of
data (300,000 files or so). The share is hosted on an Xserve G5
with 2GB of RAM.
The job ran like a champ for about 3 days (it's set to run every
few hours), and then last night it stopped running properly. It was
exiting with code 22 (Error allocating core memory buffers). I
added the verbose flag to the script this morning and ran it again
in the terminal and about 85% of the way through this started
popping up:
[...]
ERROR: out of memory in map_ptr
rsync error: error allocating core memory buffers (code 22) at /
SourceCache/rsync/rsync-24.1/rsync/util.c(120)
rsync: writefd_unbuffered failed to write 105 bytes: phase
"unknown" [generator]: Broken pipe (32)
rsync error: error in rsync protocol data stream (code 12) at /
SourceCache/rsync/rsync-24.1/rsync/io.c(909)
[...]
until rsync 3.0 (and its modifications to work with MacOS) you better
split your rsync jobs. I have no problems with about 100000 files at
a time (for only 13GB of data, but I do not think this should matter).
I suppose a dry run should tell you what is the limit. Actually, why
don't you see if with a dry run (-n) you hit the memory allocation
problem? Can you also tell us what rsync options you used?
Finally, why launchd instead of cron?
(sorry if I also copy you in the reply, but the list is pretty
sluggish these days)
g
