Re: Always exitcode 256 under Cygwin with rsync 2.6.4

2005-04-04 Thread Paul Haas
On Sun, 3 Apr 2005, Wayne Davison wrote:
On Mon, Apr 04, 2005 at 07:28:02AM +0200, Joost van den Broek wrote:
When you just give an empty rsync command, it should also exit with an
exit code (1). But the errorlevel gets set to no. 256 instead.
As mentioned in the other message that brought this up, I assume that
this is something wrong with the cygwin version (perhaps in how it was
compiled?).  Rsync is exiting with all the right codes under Linux.
If I understand the problem, it looks like it is fixed in Cygwin 1.5.14-1, 
which was released sometime on Saturday.

http://cygwin.com/ml/cygwin/2005-04/msg00073.html
The Cygwin 1.5.14-1 announcement includes this change:
 - cgf: Right shift exit code by eight when process is not started in a
   cygwin environment.
Which sounds like the fix to your problem, although it is hard to tell, 
since you didn't say what Cygwin version you were running.
--
Paul Haas
[EMAIL PROTECTED]
--
To unsubscribe or change options: https://lists.samba.org/mailman/listinfo/rsync
Before posting, read: http://www.catb.org/~esr/faqs/smart-questions.html


Re: Ownership

2004-09-09 Thread Paul Haas
On Wed, 8 Sep 2004, Wayne Davison wrote:
On Wed, Sep 08, 2004 at 04:52:51PM -0400, Paul Haas wrote:
I can think of 4 usefull modes:
1The default, don't try to chown().
2 --ownerIf rsync thinks it is root, then try to chown()
3 --owner-whiningAlways try to chown() and whine if it doesn't work.
4 --owner-no-whining Always try to chown(), don't whine if it doesn't work.

Here's a patch that adds mode 3 to the two existing modes (leaving mode
4 unimplemented for now).  It forces the user to specify -oo to perform
chowing even when not root (-ao is not enough), and to specify -gg to
try to preserve all groups when not root (even if the group wasn't
returned by the getgroups() call).  For example:

   rsync -avoogg /src/ host:/dest

This only works if both sides have this patch applied (otherwise the
normal -o and -g behavior would apply).

Thoughts?
It looks good to me.
You might want to add something like:
--- options.c   2004-09-09 09:20:20.0 -0400
+++ options.c.new   2004-09-09 09:17:17.0 -0400
@@ -250,7 +250,9 @@
   rprintf(F, -H, --hard-linkspreserve hard links\n);
   rprintf(F, -p, --perms preserve permissions\n);
   rprintf(F, -o, --owner preserve owner (root only)\n);
+  rprintf(F, -oo attempt to preserve owner (even if not 
root)\n);
   rprintf(F, -g, --group preserve group\n);
+  rprintf(F, -gg attempt to preserve group (even if not 
root)\n);
   rprintf(F, -D, --devices   preserve devices (root only)\n);
   rprintf(F, -t, --times preserve times\n);
   rprintf(F, -S, --sparsehandle sparse files efficiently\n);
Note: In a contrived test, rsync didn't do a chmod() after a chown() 
failed.  So those files were left with the mode of the temporary file.  I 
can't think of a real world situation where that matters.

Now the stage is set for someone to create a filesystem with semantics 
that are designed for rsync.  rsync wouldn't need to run as root on the 
system that holds the backups.  FUSE, filesystem in userspace, is a good 
place to start. See http://lwn.net/Articles/68104 for a description. 
Note that an early version of FUSE had a bug such that any user could 
chown.  Just call it a feature.

.. wayne..
--
Paul Haas
[EMAIL PROTECTED]
--
To unsubscribe or change options: http://lists.samba.org/mailman/listinfo/rsync
Before posting, read: http://www.catb.org/~esr/faqs/smart-questions.html


Re: rsync crashing Redhat RHEL3.0 server

2004-08-31 Thread Paul Haas
On Tue, 31 Aug 2004, Paul Slootman wrote:
Sounds like you're running out of memory (and swap as well).
I'd suggest adding memory (adding more swap doesn't make it faster...)
Adding swap space lets you figure out how much memory to buy, or ...
or rsyncing smaller bits at a time if possible
how much more you need to subdivide backups ...
(if there are many
hardlinks across directory trees it may not be feasible to do parts
separately as those hardlinks will be lost, for example).
if possible.  If none of those options work, you can use ulimit -v to 
limit the process size of the rsync jobs, so they die before damaging the 
rest of the system.

To add swap, I use
  mkdir /fullpathhere
  dd if=/dev/zero of=/fullpathhere/swap1 bs=1M count=1024
  swapon /fullpathhere/swap1
repeat for swap2, swap3, etc...  The add them all to /etc/fstab.
The command top shows how much memory and swap is in use.  Top has a 
batch mode, so you can do things like tell it to check once a minute for 
24 hours with a command line like:

 top -b -d 60 -n 1440  /fullpathhere/top.`date +%F`.log
Put that in a cron job that fires off at midnight.  After something goes 
wrong, look at the logfile and see what was going on.  Maybe there is 
another process that sometimes uses lots of memory.

Notes, add another cron job to clean up the top logfiles. See man top 
for all the spiffy options to get it to log more of what you want to see.
--
To unsubscribe or change options: http://lists.samba.org/mailman/listinfo/rsync
Before posting, read: http://www.catb.org/~esr/faqs/smart-questions.html


Re: Bug reporting

2004-06-01 Thread Paul Haas
On Tue, 1 Jun 2004, John wrote:

 That may be so, but I don't think this is one of them. rsyncx is bound to have
 all rsync's bugs. Qute possibly some will be fixed first there, and it may be
 they will add valuable new features. One that I think would be nice is an
 automatic retry: I keep getting timeouts transferring between two ADSL accounts
 and I've not decide whether to blame Arachnet (the ISP at both ends) or rsync
 or even to suppose I'm expecting too much.

That used to happen to me.  Upgrading the firmware in my network hardware
fixed the problem.

 wget has an option to automatically retry after timeouts, and it would
 certainly be useful to me if rsync did too.

 I may well decide to implement that myself: if I do, it would probably be in
 rsyncx if I decide that is where it would best suit me.

The ideal place would be in ssh.

 Enough. I'm typing on a remote machine over an overtaxed dialup line:-(

 heers
 John


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


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


Re: Feature Request - Load Throttling

2004-02-18 Thread Paul Haas
On Tue, 17 Feb 2004, Marc Perkel wrote:

 jw schultz wrote:

 On Tue, Feb 17, 2004 at 06:47:19PM -0800, Marc Perkel wrote:

 Actually - the problem is disk IO. And the disk IO is what makes the
 load levels go up.

If the disk IO is correlated with transfer IO, then --bwlimit will solve
your problem.  If there are lots of files in common, then rsync doesn't
actually need to copy them, and the disk IO can climb while the transfer
IO is tiny.  Then you need something else.

 The load level is something that's readable can can
 be used to have rsync slow itself down. Nice doesn't do the trick. Nice
 helps - but even at nice +19 it still slows the system to a crawl when
 backing up from one drive to another.

 So - if rsync could watch the load levels and pause every now and then
 to put a little space between disk access at high load levels it would
 make it a lot friendlier to the system. The reason nice doesn't work is
 that once the system call is made to access the disk - nice doesn't apply.

 This is what process and i/o schedulers are for.

There are some experimental i/o scheduler patches for Linux 2.6, but
I don't think there is anything you would want to run in production.

 What happens is that the server is cooking along just fine serving about
 2 million hits a day. Load level - according to top is running around
 0.6 to 2.3 or so - and then rsync kicks in doing a backup between the
 drives and even though I'm running at nice +19 the load kicks up to
 around 50 and several services almost stop. That's why I'm asking for
 this feature.

 I'd rather get a response from real develpers than nay sayers telling me
 things that don't work. Its a real issue and it requires changes in
 rsync to make it work correctly.

It's a real issue, and it isn't specific to rsync.  You've got a webserver
that runs well on your hardware, assuming reasonable disk caching and/or
disk I/O rates.  rsync comes along and reads lots of files, thus clearing
your cache, and it walks the directory tree, doing reads spread all over
the disk.  The reads spread over the disk means the disk heads are
spending lots of time seeking back and forth in the famous elevator
algorithm.  Your processes end up spending a lot of time waiting for that
elevator.

I don't think it requires changes to rsync, certainly nothing significant.
I think you want a separate process to implement your policy.  Something
only a little more complex than this untested perl script:

===cut here

#!/usr/bin/perl -w
$tooHigh = 4;  # Max acceptable load average
$checkTime = 10; # Seconds between checking load average
$restTime = 60;  # Seconds to pause disk hog process when load average high
@rsyncPids = @ARGV;
while (1) {  # fix this, script should end when the pids exit.
  if ( LoadAvg()  $tooHigh ) {
PausePids(@rsyncPids);
sleep(60);
ResumePids(@rsyncPids);
  }
  sleep(10);
}
sub LoadAvg {
  $upString = `uptime`;
  ($loadAvg) = ($upString =~ m/load average: (\d+\.\d+)/);
  return $loadAvg;
}

sub PausePids {
  $SigStop = 19;
  kill $SigStop, @_;
}
sub ResumePids {
  $SigCont = 18;
  kill $SigCont, @_;
}

===cut here

If the load average climbs too high, it pauses rsync, or whatever pids you
asked to pause.

I don't think rsync needs to be changed at all, provided you avoid
anything involving timeouts.

There are certainly situations where rsync would be the important task,
and it would be the other disk hog process that should pause.

It's debatable whether I count as a real developer.
--
Paul Haas [EMAIL PROTECTED]


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


Re: Server crashed using rsync

2004-01-28 Thread Paul Haas
On Wed, 28 Jan 2004, Eugen Luca wrote:

 I'm trying to make a backup using this command

 rsync -auvH /home/ /bak --delete --bwlimit=1000 --status

 server load has been increased so much and the server crashed, as well
 has gone out of memory
 My Server is a Dual Xeon 2.0 GHz with 2GB of Memory + 1GB Swap.

In addition to using the new improved CVS version of rsync as others have
suggested, you should also make it so your system won't die just because
there is a large process.  If you add some more swapspace, the system will
slow down when you run big programes.  This is painfull, but far less
painfull than whatever happens when it runs out of memory.

As long as you've got disk space you can add more swap easily on almost
any modern OS.  On Linux, the commands are:

  dd if=/dev/zero of=swapfile bs=1M count=2K
  swapon swapfile

You can add the swap area to /etc/fstab so it will be used on every
reboot.  It is much easier to debug a slow system than to debug a crashed
system.  If the swapfile is on a slow disk, you can make it low priority,
so it is used last.  Many Linux versions limit you to 2Gbytes per
swapfile, but you can use several at the same time.

You should use rsync's -exclude option so you don't back up the swapfile.

I haven't run a system out of memory in a while.  When I've done it in the
past, bad things happened, but the system didn't crash, I just wished it
had.

 Could be that there are too many files, about 5.000.000, to be backed up
 ?
 The way the files are structured make very difficult to create several
 backup with less files.
 Is there any one else facing issues like this ? Is there any workaround
 on this ?


 Thank you,
 Eugen Luca

--
Paul Haas
[EMAIL PROTECTED]

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


Re: rsync security advisory

2003-12-04 Thread Paul Haas
On Thu, 4 Dec 2003, Paul Slootman wrote:

 Date: Thu, 4 Dec 2003 11:34:44 +0100
 From: Paul Slootman [EMAIL PROTECTED]
 To: [EMAIL PROTECTED]
 Subject: Re: rsync security advisory

 On Thu 04 Dec 2003, Martin Pool wrote:
 
   - rsync version 2.5.6 contains a heap overflow vulnerability that can
 be used to remotely run arbitrary code.

 Is this specific to 2.5.6, or are earlier versions also vulnerable?
 Important detail, as it makes the difference between needing to upgrade
 older rsync's as well, or only those that are 2.5.6...  As Debian
 provides security patches for the stable release (which contains rsync
 2.5.5), I'm wondering whether an update for that is necessary.

Sure looks necessary to me.

I downloaded the Debian Stable rsync from
http://ftp.us.debian.org/debian/pool/main/r/rsync/rsync_2.5.5.orig.tar.gz
with the debian patch
http://ftp.us.debian.org/debian/pool/main/r/rsync/rsync_2.5.5-0.1.diff.gz
to get what I hope is the source for 2.5.5-0.1.

I then got the patch
http://rsync.samba.org/ftp/rsync/rsync-2.5.6-2.5.7.diff.gz
It mostly applied to 2.5.5-0.1.  It succeeds on all of the .c files
except for cleanup.c.  It fails on all the non-.c files, mostly because
those changes update the string 2.5.6 to 2.5.7, which fails.

If I understand the attack, it looks like the parts of the
rsync-2.5.6-2.5.7.diff which apply to the Debian Stable rsync-2.5.5-0.1
are sufficient to block such attacks.

The change to cleanup.c fails because the function being changed doesn't
exist in 2.5.5.

That change is
-void close_all()
+void close_all(void)

I don't understand what that changes in the context of a buffer overflow
attack.  On the assumption it does make a difference, you could change
log.c like so
-void log_open()
+void log_open(void)
and
-void log_close()
+void log_close(void)
which fixes the two places in 2.5.5-0.1 where there are empty parameter
lists in a function prototype.

--
Paul Haas [EMAIL PROTECTED]

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


Re: rsync in-place (was Re: rsync 1tb+ each day)

2003-02-05 Thread Paul Haas
On Wed, 5 Feb 2003, Craig Barratt wrote:

 Of course, a major issue with --inplace is that the file will be
 in an intermediate state if rsync is killed mid-transfer.  Rsync
 currently ensures that every file is either the original or new.

I hate silent corruption.  Much better to have things either work, or fail
in an obvious way.

I don't have a need for --inplace.  So someone who does have a need,
should say if my reasoning makes sense in the real world.

For databases, I'd want the --inplace option to rename the file before it
starts changing it, and then rename it back.  With that mode, rsync would
ensure that every file is in one of three states:

1. original
2. new
3. gone (but not forgotten, since the intermediate state file
 would still be there, just with a temporary name)

You wouldn't want the rename in a bunch of situations:
  on systems where renames are expensive
  where it doesn't hurt to have a mixture of old and new contents in a file
  for raw devices, unless you know how /dev really works on your system

This means, that there should either be two --inplace  options, like
 --inplace-rename and --inplace-norename or maybe, --inplace-dangerous and
 --inplace-more-dangerous or a modifier option.  In many cases, writing
the documentation, is more work than writing the code.

--
Paul Haas [EMAIL PROTECTED]


-- 
To unsubscribe or change options: http://lists.samba.org/mailman/listinfo/rsync
Before posting, read: http://www.tuxedo.org/~esr/faqs/smart-questions.html



Re: rsync problem behind a router

2002-12-18 Thread Paul Haas
On Tue, 17 Dec 2002, Chad Moss wrote:

 I have used rsync on many systems, and never had a problem.  I am
 stumped on what to do with this.
 I have a box behind a LinkSys router and I can not push or pull data
 to or from it from anywhere.

Does it work for very small transfers?

Does it work with --bwlimit set low enough so you never saturate your
link?

I can not rsync large amounts of data through my LinkSys without using the
--bwlimit option.  My LinkSys is doing NAT.  I think it loses track of the
address translation for the ssh connection under load.  Then the ssh
session just stops.  I use --bwlimit=100, which is a third of the
available bandwidth on the far end, and it just works.

It's not a problem particular to rsync, other ssh sessions sometimes hang
too.  I just have more problems with rsync because I move more data that
way.  I always use screen for interactive sessions.

 When I try, it logs into the remote server, gets the file list and just
 stops.

Could be a different problem, mine would often transfer quite a few files
before stopping.

 The remote server shows a process running until I control-c out of
 it.when I do that, I get:

 rsync error: received SIGUSR1 or SIGINT (code 20) at rsync.c(229)
 rsync error: received SIGUSR1 or SIGINT (code 20) at main.c(785)

 The command I am using is:
 rsync -avz -e ssh [EMAIL PROTECTED]:/home
 mailto:[EMAIL PROTECTED]:/home%20/home/backup/servername/
 /home/backup/servername/

 I have forwarded ports 22 and 873 to that machine, and I have tried
 putting it in the DMZ.
 The results do not seem to change.

 Thanks.

--
Paulh


-- 
To unsubscribe or change options: http://lists.samba.org/mailman/listinfo/rsync
Before posting, read: http://www.tuxedo.org/~esr/faqs/smart-questions.html



Re: rsync 2.5.5 segmentation fault on Linux x86.

2002-10-01 Thread Paul Haas

On 1 Oct 2002, Erik Enge wrote:

 Hi all.

 I have a script which I call from cron.  It basically does some stopping
 of a few services, rsyncs all files to a remote server and then starts
 the services again.  However, rsync segfaults:

   /share/bin/cron.root.backup.sh: line 28: 18453 Segmentation fault  rsync -acx 
--delete ${_backup_dirs} backup-server::backup-client

 If I run rsync from the command-line everything works as expected and no
 segmentation fault.

This isn't specific to rsync.  When I've had cron jobs that fail, but wrk
interactively, I add something like this to the script:


  echo this is try 1 of cron.root.backup.sh on  /tmp/backup.sh.$$.debug
  date  /tmp/backup.sh.$$.debug
  printenv  /tmp/backup.sh.$$.debug
  ulimit -a  /tmp/backup.sh.$$.debug
  echo the rsync I'll get is  /tmp/backup.sh.$$.debug
  type rsync  /tmp/backup.sh.$$.debug
  whoami  /tmp/backup.sh.$$.debug

Then I run it once interactively and once through cron and compare stuff.

Usually it's pretty obvious which environment variable is the problem.


 I'm really lost where to start debugging this problem, has anybody else
 seen this before and would be able to give me a hint?

 It's rsync 2.5.5 compiled from source with gcc 2.96 on RedHat Linux 7.2.

 Thanks for any pointers,

 Erik Enge.
 --
 To unsubscribe or change options: http://lists.samba.org/mailman/listinfo/rsync
 Before posting, read: http://www.tuxedo.org/~esr/faqs/smart-questions.html


-- 
To unsubscribe or change options: http://lists.samba.org/mailman/listinfo/rsync
Before posting, read: http://www.tuxedo.org/~esr/faqs/smart-questions.html



Re: rsync 2.5.5, HPUX, getting unexplained error at main.c(578)

2002-05-30 Thread Paul Haas

On Wed, 29 May 2002, Allen D. Winter wrote:

 I finally found that in the wait_process() function in main.c, the status
 value returned from WEXITSTATUS() was apparently returning
 the pid of the child instead of the exit status of the child... or something
 like that.

Or something not like that, since the manpage for waitpid() says the
value of status is undefined if waitpd() returns  (pid_t)-1.

Here's the current version of the function, note how it isn't checking for
-1:

void wait_process(pid_t pid, int *status)
{
while (waitpid(pid, status, WNOHANG) == 0) {
msleep(20);
io_flush();
}

/* TODO: If the child exited on a signal, then log an
 * appropriate error message.  Perhaps we should also accept a
 * message describing the purpose of the child.  Also indicate
 * this to the caller so that thhey know something went
 * wrong.  */
*status = WEXITSTATUS(*status);
}

Elsewhere in the HP UX manpage for waitpid() it says that
WEXITSTATUS(*status) is only valid if WIFEXITED(*status) is nonzero.

So an HP-UX user could try the following code and see what lands in
standard error.

void wait_process(pid_t pid, int *status)
{
int notdone = 1;
int waitPidRet;
while ( notdone ) {
waitPidRet = waitpid(pid, status, WNOHANG);
if ( waitPidRet == 0 ||
( waitPidRet == (pid_t)-1  errno == EINTR ) ) {
msleep(20);
io_flush();
if ( waitPidRet == (pid_t)-1 ) {
 fprintf(stderr,
  A mysterious failure averted.\n);
}
} else if ( waitPidRet == (pid_t) -1 ) {
perror(waitpid() did something I don't understand.);
exit(1);
}
if ( WIFEXITED(*status) ){
*status = WEXITSTATUS(*status);
notdone = 0;
} else {
fprintf(stderr,Now what should I do?\n);
exit(2);
}
}
}

The EINTR case doesn't make sense with WNOHANG, but HP-UX doesn't always
do things that make sense.  If you get the Now what should I do?
message, then add code to check WIFSIGNALED(), WIFSTOPPED() and
WIFCONTINUED() and do something appropriate.  If you reach the perror(),
hopefully the text there will offer some clues.

I don't have an HP-UX 11.11 system, I'm looking at the manpages on
an HP-UX 11.00 system.

--
Paul Haas
Just because I sometimes use HP-UX, doesn't mean I like it.


-- 
To unsubscribe or change options: http://lists.samba.org/mailman/listinfo/rsync
Before posting, read: http://www.tuxedo.org/~esr/faqs/smart-questions.html



Re: rsync 2.5.5, HPUX, getting unexplained error at main.c(578)

2002-05-30 Thread Paul Haas


Since the process didn't exit, it must still be in the process table.
When you get to this state have your process do something like:
  fprintf(stderr, The weird process is pid %d\n,pid);
  fflush(stderr);
  sleep(1000);

Then see what ps says about that process.  If that doesn't offer any
hints, attach to the process with gdb, vdb, wdb, dde or some other
debugger.

My HP-UX system doesn't have a signal 64, either.

On Thu, 30 May 2002, Charles F. Fisher wrote:

 On Thu, May 30, 2002 at 11:53:34AM -0400, Paul Haas wrote:

 Much stuff snipped..

  The EINTR case doesn't make sense with WNOHANG, but HP-UX doesn't always
  do things that make sense.  If you get the Now what should I do?
  message, then add code to check WIFSIGNALED(), WIFSTOPPED() and
  WIFCONTINUED() and do something appropriate.  If you reach the perror(),
  hopefully the text there will offer some clues.
 
  I don't have an HP-UX 11.11 system, I'm looking at the manpages on
  an HP-UX 11.00 system.
 
 Thank you for the code snippit - checking WIFSIGNALED() showed a non-zero
 result, WTERMSIG() returned 64, which isn't in /usr/include/sys/signal.h.
 In any case WIFEXITED() was returning 0, so WEXITSTATUS was returning garbage.
 Any idea was signal 64 would be?  It's being returned consistently; if it's
 a normal termination signal I'll fix the routine to treat it as such.



-- 
To unsubscribe or change options: http://lists.samba.org/mailman/listinfo/rsync
Before posting, read: http://www.tuxedo.org/~esr/faqs/smart-questions.html



Re: [PATCH] rsync kills all user processes on fork failure

2002-05-09 Thread Paul Haas

On Thu, 9 May 2002, Dave Dykstra wrote:

 On Wed, May 08, 2002 at 09:44:25PM -0700, Jos Backus wrote:
  On Wed, May 08, 2002 at 11:31:18PM -0400, Bob Byrnes wrote:
   http://rsync.samba.org/cgi-bin/rsync/incoming?id=2762;user=guest;selectid=2762

  Fwiw, the patch looks good to me. rsync doesn't seem to handle -1 == fork()
  here, leading to the problem described.

 What's the best fix against the current CVS?  Should we back out the
 previous fix because that one only solved half the problem?  Somebody
 please provide an updated patch.

My patch inspired version 1.109 of rsync/util.c,
http://cvs.samba.org/cgi-bin/cvsweb/rsync/util.c.diff?r1=1.108r2=1.109f=h
but there's other stuff there too, so you don't want to just undo it.

I'm off to a meeting now.  If no one else gets around to it, I can
repackage Bob's patch sometime late tomorrow. The context has changed a
bit, so the original won't apply without a few minor tweaks.

In addition to the kill -1 stuff, Bob also had a few lines of code to
prevent going off the end of the all_pids[] array.

 - Dave Dykstra





-- 
To unsubscribe or change options: http://lists.samba.org/mailman/listinfo/rsync
Before posting, read: http://www.tuxedo.org/~esr/faqs/smart-questions.html



Re: rsync io

2002-03-21 Thread Paul Haas

On Thu, 21 Mar 2002, Jie Gao wrote:

 One problem I have using rsync is that if you have a large dataset,
 rsync will use almost all io, leaving almost none for other processes.

Yup, that's particularly annoying when you use rsync for backups where it
just doesn't matter if it takes one hour or twelve hours.

 I wonder if something can be built into rsync to make it more
 io-friendly so that rsync can coexist with other processes?

I don't think we need to change rsync at all.  Use the --rsh parameter
to move the data through a program that limits the bandwidth.  If you're
transferring data between systems, then the bandwidth limiting program can
in turn run the real ssh (or even rsh).  For local transfers, it can run
rsync in daemon mode.

If you're running between Linux systems, and you control the kernel, and
you know more than I do, then you can use QOS, to control bandwidth.  Run
a second ssh server on a nonstandard port, call this the slow-ssh port.
Use QOS to limit the bandwidth used by traffic on that port.  This will
let you limit rsync to say 50% of your bandwidth, even when you've got
more than one rsync process running.

I have not yet configured QOS on my kernel, so I don't know the details.

--
Paul Haas [EMAIL PROTECTED]


-- 
To unsubscribe or change options: http://lists.samba.org/mailman/listinfo/rsync
Before posting, read: http://www.tuxedo.org/~esr/faqs/smart-questions.html



Re: Bug in compile of rsync 2.5.4 on Tru64 UNIX V5.1a using cc

2002-03-21 Thread Paul Haas

On Thu, 21 Mar 2002, Eckert, Robert D wrote:

 Greetings, here is the output of the 'configure' step and
 the compile step (using the Compaq cc compiler that comes
 with Tru64 V5.1A. The configure reported success and most of
 the compile steps cam through error/warning free except for
 the one that stumbled. Can someone help me out here? I am willing
 to provide a binary for Tru64 V5.1A if we can swat this bug.
 We depend greatly on Rsync to keep a fresh backup of our
 70gb storage system that is the backend of http://www.indiana.edu/,
 Indiana University's main web site to the Internet. We're also big
 fans and soon to be BIG adopters of Samba 2.2.3a.

 Anyway here is the sequence that was encountered:
 cc -I. -I. -g -DHAVE_CONFIG_H -I./popt -c batch.c -o batch.o
 cc: Error: batch.c, line 408: In this statement, a common type could not be
 determined for the 2nd and 3rd operands (s-count and int_zero) of a
 conditional operator. (badcondit)
 write_batch_csums_file(s ? s-count : int_zero, sizeof(int));
 ---^
 *** Exit 1

Line 406 says:

  /* FIXME: This will break if s-count is ever not exactly an int. */

  s-count is a size_t, which is 64 bits on your compiler.

Here's how I would fix it:

===
RCS file: RCS/batch.c,v
retrieving revision 1.1
diff -u -r1.1 batch.c
--- batch.c 2002/03/21 21:31:52 1.1
+++ batch.c 2002/03/21 21:44:11
 -396,16 +396,17 
   struct sum_struct *s)
 {
size_t i;
-   unsigned int int_zero = 0;
+   unsigned int int_count;
extern int csum_length;

fdb_open = 1;

/* Write csum info to batch file */

-   /* FIXME: This will break if s-count is ever not exactly an int. */
+   /* FIXME: This will break if s-count is ever greater than 2^32 -1 */
write_batch_csums_file(flist_entry, sizeof(int));
-   write_batch_csums_file(s ? s-count : int_zero, sizeof(int));
+   int_count = s ? (unsigned int) s-count : 0;
+   write_batch_csums_file(int_count, sizeof(int_count));

if (s) {
for (i = 0; i  s-count; i++) {



-- 
To unsubscribe or change options: http://lists.samba.org/mailman/listinfo/rsync
Before posting, read: http://www.tuxedo.org/~esr/faqs/smart-questions.html



[PATCH] rsync kills all user processes on fork failure

2002-03-19 Thread Paul Haas

I filed this as bug 4150 http://rsync.samba.org/cgi-bin/rsync/

We had a few hundred hung processes and reached the limit for max user
processes (see the ulimit command).   rsync did not handle this very
well.  It passed -1 as a PID to kill().  When kill() gets -1, it kills all
of the processes owned by that user, or if run by root, all processes.

I attached a one line fix.  Let me know if I used the wrong format for a
patch.  If the result of fork is -1 don't put it in the list of pids to
kill.

Reviewing the mailing list, I saw that this happened to at least one other
person, see http://lists.samba.org/pipermail/rsync/2001-April/004158.html
Back in April of 2001, Randy Kramer wrote:

 The rsync server often quit for me when I used the -c option,
 generally because something on the server end decided to kill rsync.

I duplicated the problem with version 2.5.4 on a Linux system.  I used
another user ID, notme, so that when rsync killed all the processes, it
wouldn't kill my shell.  ulimit -u 5 sets the max number of user
processes to 5.  I used the sleep command as my victim processes, it's
annoying to have something usefull killed when duplicating a bug.

bash$ su notme
Password:
bash$ ulimit -u 5
bash$ sleep 100  sleep 100  sleep 100 
[1] 16234
[2] 16235
[3] 16236
bash$ # There are now 4 processes running as notme, bash and 3 sleeps.
bash$ whoami
notme
bash$ ./rsync -e /usr/bin/rsh -a ~/a bandit:b
fork: Resource temporarily unavailable
rsync error: error in IPC code (code 14) at util.c(137)
bash$ whoami
me
bash$ # all of the notme processes were killed.


None of this has anything to do with the bug in our scripts that lead to
hundreds of hung processes.


===
RCS file: RCS/util.c,v
retrieving revision 1.1
diff -u -r1.1 util.c
--- util.c  2002/03/19 15:01:28 1.1
+++ util.c  2002/03/19 15:29:32
@@ -483,7 +483,7 @@
 {
pid_t newpid = fork();

-   if (newpid) {
+   if (newpid  0) {
all_pids[num_pids++] = newpid;
}
return newpid;

--
Paul Haas, [EMAIL PROTECTED] http://hamjudo.com


-- 
To unsubscribe or change options: http://lists.samba.org/mailman/listinfo/rsync
Before posting, read: http://www.tuxedo.org/~esr/faqs/smart-questions.html