Re: --no-detach option?
On Wed, Nov 21, 2001 at 12:23:29PM -, Max Bowsher wrote: I did the same, for cygwin, but I called the option --debug-daemon. --no-detach is probably a better name. Heres my patch. - Original Message - From: Jos Backus [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Tuesday, November 20, 2001 11:05 PM Subject: --no-detach option? How about adding a --no-detach option (to be used in combination with --daemon) to rsync so it can be run under Dan Bernstein's daemontools' supervise? If there's interest I'll provide a patch. Rsync will already not detach if stdin is not a socket. Is that sufficient? - Dave Dykstra
Re: --no-detach option?
Not in daemon mode. = # ps -ef |grep rsync # rsync --daemon # ps -ef |grep rsync root 23716 1 0 07:42:58 ?0:00 rsync --daemon # rsync localhost:: tconway # Like most daemons, it forks by default. I've wanted this feature for some time, for debugging, but instead, just started it with truss, with the fork option. Tim Conway [EMAIL PROTECTED] 303.682.4917 Philips Semiconductor - Longmont TC 1880 Industrial Circle, Suite D Longmont, CO 80501 Available via SameTime Connect within Philips, n9hmg on AIM perl -e 'print pack(, 19061,29556,8289,28271,29800,25970,8304,25970,27680,26721,25451,25970), .\n ' There are some who call me Tim? Dave Dykstra [EMAIL PROTECTED] Sent by: [EMAIL PROTECTED] 11/21/2001 07:15 AM To: [EMAIL PROTECTED] cc: (bcc: Tim Conway/LMT/SC/PHILIPS) Subject:Re: --no-detach option? Classification: On Wed, Nov 21, 2001 at 12:23:29PM -, Max Bowsher wrote: I did the same, for cygwin, but I called the option --debug-daemon. --no-detach is probably a better name. Heres my patch. - Original Message - From: Jos Backus [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Tuesday, November 20, 2001 11:05 PM Subject: --no-detach option? How about adding a --no-detach option (to be used in combination with --daemon) to rsync so it can be run under Dan Bernstein's daemontools' supervise? If there's interest I'll provide a patch. Rsync will already not detach if stdin is not a socket. Is that sufficient? - Dave Dykstra
Re: --no-detach option?
Excuse me, I meant to say if stdin in IS a socket. - Dave Dykstra On Wed, Nov 21, 2001 at 07:46:29AM -0700, [EMAIL PROTECTED] wrote: Not in daemon mode. = # ps -ef |grep rsync # rsync --daemon # ps -ef |grep rsync root 23716 1 0 07:42:58 ?0:00 rsync --daemon # rsync localhost:: tconway # Like most daemons, it forks by default. I've wanted this feature for some time, for debugging, but instead, just started it with truss, with the fork option. Tim Conway [EMAIL PROTECTED] 303.682.4917 Philips Semiconductor - Longmont TC 1880 Industrial Circle, Suite D Longmont, CO 80501 Available via SameTime Connect within Philips, n9hmg on AIM perl -e 'print pack(, 19061,29556,8289,28271,29800,25970,8304,25970,27680,26721,25451,25970), .\n ' There are some who call me Tim? Dave Dykstra [EMAIL PROTECTED] Sent by: [EMAIL PROTECTED] 11/21/2001 07:15 AM To: [EMAIL PROTECTED] cc: (bcc: Tim Conway/LMT/SC/PHILIPS) Subject:Re: --no-detach option? Classification: On Wed, Nov 21, 2001 at 12:23:29PM -, Max Bowsher wrote: I did the same, for cygwin, but I called the option --debug-daemon. --no-detach is probably a better name. Heres my patch. - Original Message - From: Jos Backus [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Tuesday, November 20, 2001 11:05 PM Subject: --no-detach option? How about adding a --no-detach option (to be used in combination with --daemon) to rsync so it can be run under Dan Bernstein's daemontools' supervise? If there's interest I'll provide a patch. Rsync will already not detach if stdin is not a socket. Is that sufficient? - Dave Dykstra
Compressed backup mode?
Hi list! Is there any way to tell rsync to keep the mirrored files compressed? I'd like to use it for backup purposes and would like to save some space on the target machine. If there's no such way, I probably have to reactivate my C-skills (But I hope that ain't necessary :)) Holger
Re: --no-detach option?
On Wed, Nov 21, 2001 at 08:54:18AM -0600, Dave Dykstra wrote: Excuse me, I meant to say if stdin in IS a socket. That mode of operation is indeed useful when running rsync --daemon from inetd or tcpserver. I am talking about a mode in which rsync still listen()s, etc. but can be managed by its parent (supervise in the daemontools case). -- Jos Backus _/ _/_/_/Santa Clara, CA _/ _/ _/ _/ _/_/_/ _/ _/ _/_/ [EMAIL PROTECTED] _/_/ _/_/_/use Std::Disclaimer;
delete-before-update patch
I have been using this simple patch enough that I know it works for my
purpose,
now I submit it here, for comments.
--delete-before-update
implies -W, unlinks the destination file just before the new (temporary)
file is written.
This would be used when writing to a small or near full medium to use the
minmum space when writing.
In my case, I happen to be writing to compact flash, so since -W turns the
block checksum off, I need -c to force a checksum to ensure that byte wise
identical files are not rewritten.
Tim's comment below concerned me, but looking at the code, -W and -c can
sensibly be used together.
(correct me if I am wrong)
-W turns off the per block checksum.
-c turns on whole file checksum.
so, the flags that I am using --delete-before-update -c make sense.
[EMAIL PROTECTED] wrote:
-W and -c are actually kind of opposite effects... -W means never
checksum... if it's different in length or time, send it.
-c means ALWAYS checksum, even if time and length are identical.
diff -ru rsync-2.4.6/options.c rsync-2.4.6-delete-before-update/options.c
--- rsync-2.4.6/options.c Tue Sep 5 19:46:43 2000
+++ rsync-2.4.6-delete-before-update/options.c Wed Nov 14 08:13:03 2001
@@ -23,6 +23,7 @@
int make_backups = 0;
int whole_file = 0;
+int delete_before_update = 0;
int copy_links = 0;
int preserve_links = 0;
int preserve_hard_links = 0;
@@ -181,7 +182,7 @@
}
enum {OPT_VERSION, OPT_SUFFIX, OPT_SENDER, OPT_SERVER, OPT_EXCLUDE,
- OPT_EXCLUDE_FROM, OPT_DELETE, OPT_DELETE_EXCLUDED, OPT_NUMERIC_IDS,
+ OPT_EXCLUDE_FROM, OPT_DELETE_BEFORE_UPDATE, OPT_DELETE, OPT_DELETE_EXCLUDED,
+OPT_NUMERIC_IDS,
OPT_RSYNC_PATH, OPT_FORCE, OPT_TIMEOUT, OPT_DAEMON, OPT_CONFIG, OPT_PORT,
OPT_INCLUDE, OPT_INCLUDE_FROM, OPT_STATS, OPT_PARTIAL, OPT_PROGRESS,
OPT_COPY_UNSAFE_LINKS, OPT_SAFE_LINKS, OPT_COMPARE_DEST,
@@ -197,6 +198,7 @@
{server, 0, 0,OPT_SERVER},
{sender, 0, 0,OPT_SENDER},
{existing,0, 0,OPT_EXISTING},
+ {delete-before-update, 0, 0,OPT_DELETE_BEFORE_UPDATE},
{delete, 0, 0,OPT_DELETE},
{delete-excluded, 0, 0,OPT_DELETE_EXCLUDED},
{force, 0, 0,OPT_FORCE},
@@ -436,6 +438,11 @@
whole_file=1;
break;
+ case OPT_DELETE_BEFORE_UPDATE:
+ delete_before_update=1;
+ whole_file=1;
+ break;
+
case 'H':
#if SUPPORT_HARD_LINKS
preserve_hard_links=1;
@@ -706,6 +713,9 @@
args[ac++] = --suffix;
args[ac++] = backup_suffix;
}
+
+ if (delete_before_update)
+ args[ac++] = --delete-before-update;
if (delete_mode !delete_excluded)
args[ac++] = --delete;
diff -ru rsync-2.4.6/receiver.c rsync-2.4.6-delete-before-update/receiver.c
--- rsync-2.4.6/receiver.c Thu Mar 30 06:23:03 2000
+++ rsync-2.4.6-delete-before-update/receiver.c Wed Nov 14 08:11:21 2001
@@ -34,6 +34,7 @@
extern char *tmpdir;
extern char *compare_dest;
extern int make_backups;
+extern int delete_before_update;
extern char *backup_suffix;
static struct delete_list {
@@ -394,6 +395,17 @@
presmissions then act as though the remote end sent
us the file permissions we already have */
file-mode = st.st_mode;
+ }
+
+ if(delete_before_update) {
+ if (fd1 != -1) {
+ close(fd1);
+ if(robust_unlink(fname) != 0) {
+ rprintf(FERROR,unlink %s :
+%s\n,fname,strerror(errno));
+ continue;
+ }
+ fd1 = -1;
+ }
}
if (fd1 != -1 st.st_size 0) {
Re: --no-detach option?
On Wed, Nov 21, 2001 at 11:07:21AM -0800, Jos Backus wrote: On Wed, Nov 21, 2001 at 08:54:18AM -0600, Dave Dykstra wrote: Excuse me, I meant to say if stdin in IS a socket. That mode of operation is indeed useful when running rsync --daemon from inetd or tcpserver. I am talking about a mode in which rsync still listen()s, etc. but can be managed by its parent (supervise in the daemontools case). I'm not familiar with daemontools; I checked the web site and it wasn't obvious to me. What's the advantage of using daemontools supervise? Why does it need to run the daemon as a subprocess? Assuming it's a command to make sure a daemon keeps running, it seems to me that it ought to be able to work if given a process id and not require any deaemon it could supervise to be modified to not fork. I have a script for my own use which does that. - Dave Dykstra
Re: --no-detach option?
On Wed, Nov 21, 2001 at 03:27:52PM -0600, Dave Dykstra wrote: I'm not familiar with daemontools; I checked the web site and it wasn't obvious to me. What's the advantage of using daemontools supervise? Why does it need to run the daemon as a subprocess? Like AIX's SRC (System Resource Controller), svscan/supervise together with svc/svstat are designed to control daemons in a uniform, platform-independent way. So rather than having start|stop scripts (/etc/rc?.d/*, /etc/rc.local, etc.) for each daemon, a service scanner (svscan) runs which starts supervise processes, which in turn manage each individual service. By virtue of supervise being the parent of the service being managed, problems with stale pidfiles and such are being avoided. A simple example: traitor:/service% ls -l sshd lrwxr-xr-x 1 root wheel 17 May 7 2001 sshd - /var/service/sshd traitor:/service% ls -l /var/service/sshd total 3 drwxr-xr-x 4 nobody wheel 512 May 7 2001 log -rwxr-xr-x 1 rootwheel 91 May 7 2001 run drwx-- 2 rootwheel 512 Nov 21 13:48 supervise traitor:/service% cat /var/service/sshd/run #!/bin/sh PATH=/usr/sbin exec sshd -D -e 21 The service can be controlled (up/down/restart/run once) using the svc command. Among others, one thing this setup makes easy is for a privileged process to be controlled by an unprivileged group of users, by simply manipulating the permissions on the service control socket. Assuming it's a command to make sure a daemon keeps running, it seems to me that it ought to be able to work if given a process id and not require any deaemon it could supervise to be modified to not fork. I have a script for my own use which does that. It does more than just that. Hope this explains things a little bit. - Dave Dykstra -- Jos Backus _/ _/_/_/Santa Clara, CA _/ _/ _/ _/ _/_/_/ _/ _/ _/_/ [EMAIL PROTECTED] _/_/ _/_/_/use Std::Disclaimer;
Re: How to setup Rsync as an NT Service
To create the install package described here you will need to obtain a copy of the NT Server or Windows 2000 Server Resource Kit. There are many sources for these utilities. Perhaps the easiest is to get the book and CD from any technical bookstore or online at http://www.amazon.com for as low as $35. Search for: The NT Server 4.0 Resource Kit Supplement 4 Windows 2000 Server Resource Kit I suggest to add a paragraph to use cygrunsrv instead of srvany as any CygWin user can download it easily =) (as in: cygrunsrv -I rsyncd -p /usr/bin/rsync -a '--config /etc/rsync.conf --daemon') BTW: whats' wrong in a plaineasy CygWin's precompiled rsync? (I'm interested in commentssuggestions as I'm the mantainer of that package... ^_^) -- Lapo 'Raist' Luchini [EMAIL PROTECTED] (PGP X.509 keys available) http://www.lapo.it (ICQ UIN: 529796)
Re: Bandwidth Limits
On 20 Nov 2001, [EMAIL PROTECTED] wrote: It is a bit less than obvious... It can be sure about its own kBps, but wire protocols may vary... 100Mbps of ethernet is not 100/16 ofr 16Mbps token ring is not 100/1.044 of T1 is not ...whatever rsh,, ssh, and rsync transport protocols vary in overhead... the one thing of which rsync can be certain is the number of bytes of actual data it transfers... At least, that's my take on it. Right... sockets work in bytes, not bits, and as Tim says there is always overhead. Dividing wire speed in bits/s by ten often gives a reasonable estimate for bytes/s, since most transports have some framing or interpacket or redundancy overhead. -- Martin
