Re: rsync 2.5.6 hanging
Zachary Denison [EMAIL PROTECTED] wrote: I get the same exact results on redhat 7.3 and redhat 8.0 so I dont think it is a redhat issue. Also if I use an earlier version of rsync (version 2.3.4), then I still get the same problem, but it doesn't crash as quickly as the 2.5.6 version. You didn't answer my questions - assuming you are running rsync 2.5.6 on the source machine: 1. what version of rsync is running on the ftp server? (destination machine) 2. if you know the exact file that it gets stuck on, then how big is that file? Again, not sure I can help you yet, but the answers to those questions may give either me or others the clues needed to help you. -- Hardy Merrill Red Hat, Inc. --- Hardy Merrill [EMAIL PROTECTED] wrote: FYI - RHL 6.1 is no longer supported - from a Red Hat perspective that is :-( See the Red Hat Errata: Security Alerts, Bugfixes, and Enhancements page here http://www.redhat.com/apps/support/errata/ You may indeed get help here since this list is an rsync list. If I knew what your problem might be I'd try to help you myself, but I don't so hopefully someone else will chime in with some ideas for you to try. One question I do have is what version of rsync is running on the ftp server? Also, if you know the exact file it gets stuck on, how big is that file? -- Hardy Merrill Red Hat, Inc. Zachary Denison [EMAIL PROTECTED] wrote: I am using rsync 2.5.6 on redhat linux 6.1 with 1gb ram. What I would like to do is mirror a directory on the server to another server for backup purposes. The server is an ftp server and the main directory in question is 77GB consisting of 391000 subdirectories and files. when I run rsync with the following command: /usr/bin/rsync -av --rsh=ssh --stats --progress --rsync-path=/usr/bin/rsync --delete --force --exclude=logs/ /ftpfs/ 10.10.1.237:/ftpfs/ it starts to transmit some files and then gets stuck. Actually now it is stuck on one file and every time I run it it it freezes as it is transmitting the file: as in the example below: 196608 22% 629.92kB/s0:00:01 then it just hangs.. I have 1gb of ram in the machine so it shouldn't be a lack of memory issue. I would greatly appreciate any ideas. thank you.. Zach. -- 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 2.5.6 hanging
FYI - RHL 6.1 is no longer supported - from a Red Hat perspective that is :-( See the Red Hat Errata: Security Alerts, Bugfixes, and Enhancements page here http://www.redhat.com/apps/support/errata/ You may indeed get help here since this list is an rsync list. If I knew what your problem might be I'd try to help you myself, but I don't so hopefully someone else will chime in with some ideas for you to try. One question I do have is what version of rsync is running on the ftp server? Also, if you know the exact file it gets stuck on, how big is that file? -- Hardy Merrill Red Hat, Inc. Zachary Denison [EMAIL PROTECTED] wrote: I am using rsync 2.5.6 on redhat linux 6.1 with 1gb ram. What I would like to do is mirror a directory on the server to another server for backup purposes. The server is an ftp server and the main directory in question is 77GB consisting of 391000 subdirectories and files. when I run rsync with the following command: /usr/bin/rsync -av --rsh=ssh --stats --progress --rsync-path=/usr/bin/rsync --delete --force --exclude=logs/ /ftpfs/ 10.10.1.237:/ftpfs/ it starts to transmit some files and then gets stuck. Actually now it is stuck on one file and every time I run it it it freezes as it is transmitting the file: as in the example below: 196608 22% 629.92kB/s0:00:01 then it just hangs.. I have 1gb of ram in the machine so it shouldn't be a lack of memory issue. I would greatly appreciate any ideas. thank you.. Zach. -- 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: Deleting a remote file when deleted locally...
[EMAIL PROTECTED] [EMAIL PROTECTED] wrote: Hello, I have several individual files in a directory that I want to keep syncronized. Here's an example: Server #1 (host): /tmp/file1 /tmp/file2 Now of course I can run rsync -a /tmp/file1 [EMAIL PROTECTED]:/tmp... But, when I delete /tmp/file1 from the host and try to run this it complains about /tmp/file1 being non-existant... Can I force (or using a more elegant method) make the remote server delete an individual file if it no longer exists on the host?... Obviously I do not want to rsync the entire directory, I just want that single file to be transferred... Did you notice the --delete option in the rsync manpage? Does that not do what you want here? -- Hardy Merrill Red Hat, Inc. -- 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: rsyncing Maildirs
jw schultz [EMAIL PROTECTED] wrote: On Thu, Nov 06, 2003 at 10:48:37AM +0100, Snorre Narum Garmann wrote: Hi I'm trying to take a backup of all the users emails on a server using rsync, but there is probably something about the patterns I haven't understood quite. Every user has a folder called Maildir in their home directory. So the structure is like this: /home/user1/Maildir /home/user2/Maildir etc. I'm not interested in backing up the other folders that the users might have. The mailbackup share points to the /home folder so I'm trying the following without success: rsync -av --include /*/Maildir/** --exclude * -recursive server::mailbackup . This backs up nothing. Why doesn't this work? Could anyone enlighten me? Because you failed to include the parent directories all the way up the line. Read the manpage section on EXCLUDE PATTERNS. I'd use --exclude-from because you will need more patterns than one normally wants on the command-line. According to what jw suggested for including the parent directories, this is what I tried and I think it worked - I've modified the directories from my test to correspond to yours: rsync-include-file -- + /*/ + /*/Maildir/ + /*/Maildir/** - /** rsync -av --include-from=rsync-include-file server::mailbackup . HTH. -- Hardy Merrill Red Hat, Inc. -- 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: exit code definitions
I didn't search the web for this - I just looked for *.h files in the rsync source, and found error.h. I'm guessing the contents of error.h is what you're after. Check the rsync source out of CVS and view error.h. HTH. -- Hardy Merrill Red Hat, Inc. [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: Hi ! I've spent countless hours search the internet to find a list of exit codes for rsync. Can someone point me to a list of error codes and their meanings? this would be much appreciated !! thanks !! -- 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: Operation not permitted?
Just a guess, as I'm a Samba newbie, but if you're trying to *write* to the Samba mount, then the Samba server needs to give *write* permissions to that filesystem. On Red Hat Linux, this is typically done in /etc/samba/smb.conf find the correct share, and look for the 'writable' option. After making changes, I think you need to restart samba. Not sure why rsync does a chown. HTH. -- Hardy Merrill Red Hat, Inc. Max Kipness [EMAIL PROTECTED] wrote: Hello, Can someone tell me what the problem is here. I am doing an rsync on a sendmail spool directory to a folder that is a samba mount. Why is rsync trying to change owner? Does it have to? I tried manually changing owner (as root) on a file that is sitting on the samba mount and I got the same operation not permitted error. Does anybody know why this is? Or do I need to ask in a samba mailling list. Here is the error: chown var/spool/mail/[EMAIL PROTECTED] : Operation not permitted chown var/spool/mail/[EMAIL PROTECTED] : Operation not permitted chown var/spool/mail/[EMAIL PROTECTED] : Operation not permitted chown var/spool/mail/[EMAIL PROTECTED] : Operation not permitted Thanks, Max -- 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: @ERROR auth failed on module
What is the exact command you are using on the cygwin client to do the rsync transfer? -- Hardy Merrill Red Hat, Inc. IMAC, Sebastian Mangelkramer [EMAIL PROTECTED] wrote: hi rsync-list, i have an authentication problem with my rsync-server. @ERROR auth failed on module XXX i`ve searched for an solution that fixes this problem in the mailinglist archives of rsync. but no one solves my problem. i`m running rsync version 2.5.6cvs protocol version 26 on debian 3.0 with kernel 2.4.22 my rsyncd.config looks like this: ### s15523492:~# cat /etc/rsyncd.conf max connections = 25 socket options = SO_KEEPALIVE log file = /var/log/rsync [foo-bar] uid = nobody gid = nogroup use chroot = no auth users = foo comment = Backup f|r foo-bar path = /backup/foo-bar read only = false strict modes = false secrets file = /etc/rsyncd.sec hosts allow = my.ip my rsyncd.sec file like this: (has chmod 400) foo:bar fo01:bar1 everytime when i want to connect i get this error: @ERROR auth failed on module foo-bar on the client machine i use the rsync that comes with cygwin under win2k server. anyone has an idea? thank you. regards, -- Sebastian Mangelkramer System Administrator IMAC - Information Management Consulting Blarerstra_e 56, D-78462 Konstanz Tel. +49 (0)7531 - 90 39-42 Fax +49 (0)7531 - 90 39-47 E-Mail: [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 daemon and secrets file
Martin Pool [EMAIL PROTECTED] wrote: On Mon, 25 Aug 2003 12:49:36 -0400 Hardy Merrill [EMAIL PROTECTED] wrote: IMHO, it would enhance user understanding to provide a concrete EXAMPLE of this. Also, it would help in 'man rsyncd.conf' not only to see an example of an rsyncd.conf file, but also to see examples of the different transfers that could be done with that rsyncd.conf file. I'm not criticizing - just mearly noticing an area that given some attention, could increase user understanding and decrease support. Could you please draft a couple of paragraphs to add to the manual that you think would improve it? If you post them here I will check them and commit them. Documentation is definitely not my strong suit :-) It's pretty rough, and I'm not sure that it's in the place that makes the most sense, but it's at least a start. Let me know what your thoughts are. I first checked out rsync from CVS this morning and started with rsyncd.conf.5 from that. I'm including the whole *changed* rsyncd.conf.5 - I added an EXAMPLE in the auth users section. Thanks. -- Hardy Merrill Red Hat, Inc. -- 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 daemon and secrets file
I'll include the attachment this time... Hardy Merrill .TH rsyncd\.conf 5 26 Jan 2003 .SH NAME rsyncd\.conf \- configuration file for rsync server .SH SYNOPSIS .PP rsyncd\.conf .PP .SH DESCRIPTION .PP The rsyncd\.conf file is the runtime configuration file for rsync when run as an rsync server\. .PP The rsyncd\.conf file controls authentication, access, logging and available modules\. .PP .SH FILE FORMAT .PP The file consists of modules and parameters\. A module begins with the name of the module in square brackets and continues until the next module begins\. Modules contain parameters of the form \'name = value\'\. .PP The file is line-based - that is, each newline-terminated line represents either a comment, a module name or a parameter\. .PP Only the first equals sign in a parameter is significant\. Whitespace before or after the first equals sign is discarded\. Leading, trailing and internal whitespace in module and parameter names is irrelevant\. Leading and trailing whitespace in a parameter value is discarded\. Internal whitespace within a parameter value is retained verbatim\. .PP Any line beginning with a hash (#) is ignored, as are lines containing only whitespace\. .PP Any line ending in a \e is continued on the next line in the customary UNIX fashion\. .PP The values following the equals sign in parameters are all either a string (no quotes needed) or a boolean, which may be given as yes/no, 0/1 or true/false\. Case is not significant in boolean values, but is preserved in string values\. .PP .SH LAUNCHING THE RSYNC DAEMON .PP The rsync daemon is launched by specifying the --daemon option to rsync\. .PP The daemon must run with root privileges if you wish to use chroot, to bind to a port numbered under 1024 (as is the default 873), or to set file ownership\. Otherwise, it must just have permission to read and write the appropriate data, log, and lock files\. .PP You can launch it either via inetd, as a stand-alone daemon, or from an rsync client via a remote shell\. If run as a stand-alone daemon then just run the command rsync --daemon from a suitable startup script\. If run from an rsync client via a remote shell (by specifying both the -e/--rsh option and server mode with :: or rsync://), the --daemon option is automatically passed to the remote side\. .PP When run via inetd you should add a line like this to /etc/services: .PP .RS rsync 873/tcp .RE .PP and a single line something like this to /etc/inetd\.conf: .PP .RS rsync stream tcp nowait root /usr/bin/rsync rsyncd --daemon .RE .PP Replace /usr/bin/rsync with the path to where you have rsync installed on your system\. You will then need to send inetd a HUP signal to tell it to reread its config file\. .PP Note that you should not send the rsync server a HUP signal to force it to reread the \f(CWrsyncd\.conf\fP file\. The file is re-read on each client connection\. .PP .SH GLOBAL OPTIONS .PP The first parameters in the file (before a [module] header) are the global parameters\. .PP You may also include any module parameters in the global part of the config file in which case the supplied value will override the default for that parameter\. .PP .IP \fBmotd file\fP The motd file option allows you to specify a message of the day to display to clients on each connect\. This usually contains site information and any legal notices\. The default is no motd file\. .IP .IP \fBlog file\fP The log file option tells the rsync daemon to log messages to that file rather than using syslog\. This is particularly useful on systems (such as AIX) where syslog() doesn\'t work for chrooted programs\. .IP .IP \fBpid file\fP The pid file option tells the rsync daemon to write its process id to that file\. .IP .IP \fBsyslog facility\fP The syslog facility option allows you to specify the syslog facility name to use when logging messages from the rsync server\. You may use any standard syslog facility name which is defined on your system\. Common names are auth, authpriv, cron, daemon, ftp, kern, lpr, mail, news, security, syslog, user, uucp, local0, local1, local2, local3, local4, local5, local6 and local7\. The default is daemon\. .IP .IP \fBsocket options\fP This option can provide endless fun for people who like to tune their systems to the utmost degree\. You can set all sorts of socket options which may make transfers faster (or slower!)\. Read the man page for the setsockopt() system call for details on some of the options you may be able to set\. By default no special socket options are set\. .IP .PP .SH MODULE OPTIONS .PP After the global options you should define a number of modules, each module exports a directory tree as a symbolic name\. Modules are exported by specifying a module name in square brackets [module] followed by the options for that module\. .PP .IP .IP \fBcomment\fP The comment option specifies a description string that is displayed next
Re: rsync daemon and secrets file
After seeing another question answered today on the same 'rsyncd.secrets' topic, I solved my problem - I had more than one: 1. in the /etc/rsyncd.conf file, I specified secrets file = /etc/rsync.secrets when the proper file was 'rsyncd.secrets' 2. the one and only line I have in /etc/rsyncd.secrets does need an end-of-line character at the end. after making those 2 changes, I do get the password prompt on the client, and when I enter the password correctly, the transfer completes correctly. I also realized that the rsync client does not need to have a system account corresponding to the rsync server module name - the client can just specify the module name as the user name, as in [EMAIL PROTECTED]::DEST. So, if the module name is 'test', and I either don't have a account 'test' on the client, or I'm logged on as a different account(not 'test') on the client, then I can still do the transfer by specifying 'test@' before the server hostname and module, like rsync -avv [EMAIL PROTECTED]::test-secret/one_secret /tmp/rsync_test_secret Although 'man rsync' does technically describe this in the CONNECTING TO AN RSYNC SERVER OVER A REMOTE SHELL PROGRAM section with this command: rsync -av --rsh=ssh -l ssh-user [EMAIL PROTECTED]::module[/path] local-path IMHO, it would enhance user understanding to provide a concrete EXAMPLE of this. Also, it would help in 'man rsyncd.conf' not only to see an example of an rsyncd.conf file, but also to see examples of the different transfers that could be done with that rsyncd.conf file. I'm not criticizing - just mearly noticing an area that given some attention, could increase user understanding and decrease support. -- Hardy Merrill Red Hat, Inc. Hardy Merrill [EMAIL PROTECTED] wrote: I'm trying to understand how to properly setup the /etc/rsyncd.conf file to run an rsync daemon with a secrets file specified in a module - the rsync.conf manpage does not spell it out clearly enough. Rsync server is rsync-2.5.6. If this is my /etc/rsyncd.conf file: log file = /var/log/rsync uid = root gid = root [test] uid = rsync1 gid = rsync1 path = /rsync_test comment = Rsync Test - Comment [test-secret] comment = Testing Secret Stuff path = /rsync_test_secret secrets file = /etc/rsync.secrets auth users = joe And this is the /etc/rsyncd.secrets file: - test:another_pw And permissions on the /etc/rsync* files: - [EMAIL PROTECTED] etc]# ls -l rsync* -rw-r-1 root root 261 Aug 22 09:02 rsyncd.conf -rw-r-1 root root9 Aug 22 09:10 rsyncd.secrets And permissions on the /rsync_test_secret directory: drwxr-xr-x3 rsync1 rsync1 4096 Jul 10 12:16 rsync_test drwxr-xr-x3 root root 4096 Aug 22 08:44 rsync_test_secret With those settings, a client logged on to a different machine in the same network, as user test, connecting with rsync -avv my.rsync_server.com::test-secret/one_secret /tmp/rsync_test_secret gets the 'password:' prompt, and then after entering password 'another_pw', gets this error: @ERROR: auth failed on module test-secret and the /var/log/rsync log gets this error: 2003/08/22 09:11:08 [3377] auth failed on module test-secret from my.rsync_server.com ([ip of client]) What am I missing? TIA. -- Hardy Merrill Red Hat, Inc. -- 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 with SSH problem
CHEUNG Chi Wai, Chris [EMAIL PROTECTED] wrote: I have add the ssh key to my .ssh/authorized_files. When I enter the command, the errors are as follow. [EMAIL PROTECTED] .ssh]# rsync mandrake82::X /rsynctest --recursive -e ssh From 'man rsync' - CONNECTING TO AN RSYNC SERVER OVER A REMOTE SHELL PROGRAM: In order to distinguish between the remote-shell user and the rsync server user, you can use '-l user' on your remote-shell command: rsync -av --rsh=ssh -l ssh-user [EMAIL PROTECTED]::module[/path] local-path The ssh-user will be used at the ssh level; the rsync-user will be used to check against the rsyncd.conf on the remote host. HTH. -- Hardy Merrill Red Hat, Inc. buffer_get: trying to get more bytes 129 than in buffer 46 rsync: connection unexpectedly closed (0 bytes read so far) sync error: error in rsync protocol data stream (code 12) at io.c(165) There is no errors when I do not use SSH Please help -- To unsubscribe or change options: http://lists.samba.org/mailman/listinfo/rsync Before posting, read: http://www.catb.org/~esr/faqs/smart-questions.html
rsync daemon and secrets file
I'm trying to understand how to properly setup the /etc/rsyncd.conf file to run an rsync daemon with a secrets file specified in a module - the rsync.conf manpage does not spell it out clearly enough. Rsync server is rsync-2.5.6. If this is my /etc/rsyncd.conf file: log file = /var/log/rsync uid = root gid = root [test] uid = rsync1 gid = rsync1 path = /rsync_test comment = Rsync Test - Comment [test-secret] comment = Testing Secret Stuff path = /rsync_test_secret secrets file = /etc/rsync.secrets auth users = joe And this is the /etc/rsyncd.secrets file: - test:another_pw And permissions on the /etc/rsync* files: - [EMAIL PROTECTED] etc]# ls -l rsync* -rw-r-1 root root 261 Aug 22 09:02 rsyncd.conf -rw-r-1 root root9 Aug 22 09:10 rsyncd.secrets And permissions on the /rsync_test_secret directory: drwxr-xr-x3 rsync1 rsync1 4096 Jul 10 12:16 rsync_test drwxr-xr-x3 root root 4096 Aug 22 08:44 rsync_test_secret With those settings, a client logged on to a different machine in the same network, as user test, connecting with rsync -avv my.rsync_server.com::test-secret/one_secret /tmp/rsync_test_secret gets the 'password:' prompt, and then after entering password 'another_pw', gets this error: @ERROR: auth failed on module test-secret and the /var/log/rsync log gets this error: 2003/08/22 09:11:08 [3377] auth failed on module test-secret from my.rsync_server.com ([ip of client]) What am I missing? TIA. -- Hardy Merrill Red Hat, Inc. -- 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: authentication error
CHEUNG Chi Wai, Chris [EMAIL PROTECTED] wrote: I have setup a Rysnc server in Mandrake 9.1 When I add a auth user into my Rsync.conf and rsync.secrets, it do not work, everytime it shows [EMAIL PROTECTED] rsync [EMAIL PROTECTED]::X/.html/. / Password: @ERROR: auth failed on module X rsync: connection unexpectedly closed (89 bytes read so far) rsync error: error in rsync protocol data stream (code 12) at io.c(165) This is my rsync's config file [X] path =/Nukephp comment = X.com use chroot auth users = chris, secrets file = /etc/rsyncd.secrets This is my secret.files chris:chris Read 'man rsyncd.conf' - specifically the uid and gid sections. My *wild* guess is that since you haven't specified a uid/gid, that it is using user nobody, and user nobody probably doesn't have read access to your secrets file. As I said, it's just a guess. HTH. -- Hardy Merrill Red Hat, Inc. -- 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: SIGCHLD SIG_IGN, then wait - warning messages
This patch worked for me, and it worked for the person
that posted the bug. No more warnings after applying
this patch.
I'm not sure what the procedure is for this, but I'd like
to request that this patch be committed so it will be
in future rsync versions.
Thanks Wayne!
--
Hardy Merrill
Red Hat, Inc.
Wayne Davison [EMAIL PROTECTED] wrote:
On Thu, Jul 24, 2003 at 09:09:48AM -0400, Hardy Merrill wrote:
What is the status on this?
I finally educated myself on this issue, and would like to propose a
patch. Since there are reports that zombies can get created when using
SIG_IGN on FreeBSD as well as other unices, I think we should change the
code to catch the signal and cleanup the zombies in the signal handler.
This would make the code similar to the handling in main.c.
..wayne..
--- socket.c 27 Jan 2003 03:35:09 - 1.84
+++ socket.c 24 Jul 2003 19:25:05 -
@@ -374,6 +374,14 @@
}
+static RETSIGTYPE sigchld_handler(int UNUSED(val)) {
+ signal(SIGCHLD, sigchld_handler);
+#ifdef WNOHANG
+ while (waitpid(-1, NULL, WNOHANG) 0) {}
+#endif
+}
+
+
void start_accept_loop(int port, int (*fn)(int, int))
{
int s;
@@ -419,14 +427,7 @@
if (fd == -1) continue;
- signal(SIGCHLD, SIG_IGN);
-
- /* we shouldn't have any children left hanging around
-but I have had reports that on Digital Unix zombies
-are produced, so this ensures that they are reaped */
-#ifdef WNOHANG
-while (waitpid(-1, NULL, WNOHANG) 0);
-#endif
+ signal(SIGCHLD, sigchld_handler);
if ((pid = fork()) == 0) {
int ret;
--
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 not connecting
Bhattacharyya, Somraj [EMAIL PROTECTED] wrote: Hi All I am using the following command to update data from one server to another one. But it is returning back with error. Without SSH: [EMAIL PROTECTED] var]# rsync -ae /var/www pc165002.napier.ac.uk:/var/www Without ssh also means without -e. Take the -e out, and this 'Failed to exec' error should disappear. Failed to exec /var/www : Permission denied rsync error: error in IPC code (code 14) at util.c(162) rsync: connection unexpectedly closed (0 bytes read so far) rsync error: error in rsync protocol data stream (code 12) at io.c(150) With SSH: [EMAIL PROTECTED] var]# rsync -ae ssh/var/www pc165002.napier.ac.uk:/var/www ^^^ You need a space between ssh and '/var/www'. Failed to exec ssh/var/www : No such file or directory rsync error: error in IPC code (code 14) at util.c(162) rsync: connection unexpectedly closed (0 bytes read so far) rsync error: error in rsync protocol data stream (code 12) at io.c(150) For with SSH option, I have the specified directory. Can anyone please guide me. Thanks in advance. Somraj -- To unsubscribe or change options: http://lists.samba.org/mailman/listinfo/rsync Before posting, read: http://www.catb.org/~esr/faqs/smart-questions.html -- Hardy Merrill Red Hat, Inc. -- 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: Include-from ?
Max Kipness [EMAIL PROTECTED] wrote: Thanks for the info. I actually did not specify my configuration right so that it is where I was going wrong. However, I'm still not able to only rsync /Test2. My root directory is: /Rootdir And then subdirectories of /Rootdir are: /Test1 /Test2 /Test3 To get only /Test2, I tried the following in the include-only file: + Rootdir/Test2/ - /* This syncs nothing and gives me: excluding directory Rootdir because of pattern /*. I'm NO rsync expert, but here's my guess - you need something like this: + Rootdir/Test2/ - Rootdir/* HTH. -- Hardy Merrill Red Hat, Inc. Thanks, Max -Original Message- From: jw schultz [mailto:[EMAIL PROTECTED] Sent: Sunday, August 03, 2003 2:05 AM To: [EMAIL PROTECTED] Subject: Re: Include-from ? On Sun, Aug 03, 2003 at 01:35:22AM -0500, Max Kipness wrote: Hello - I just finished doing a search of the archives and couldn't seem to get this answered. Example, I have a root directory containing the following directories: /Test1 /Test2 /Test3 I want to rsync only /Test2 and all subdirs under. So my include-from file looks like: + Test2/* - /* This doesn't work as nothing is synced, and if I do a -vv it tells me that nothing is being synced because I've excluded all. I'm sure it didn't say that. Instead it would have spit out a bunch of lines including: excluding directory Test2 because of pattern /* That is because you never included Test2, only everything under it. | + Test2/ | - /* Would be what you want. -- J.W. SchultzPegasystems Technologies email address: [EMAIL PROTECTED] Remember Cernan and Schmitt -- 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 -- 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: SIGCHLD SIG_IGN, then wait - warning messages
What is the status on this? Is it being considered, or just ignored? Some (any) response would be appreciated :) If access to the bug is an issue, I can attach it - just let me know. Thanks. -- Hardy Merrill Red Hat, Inc. Hardy Merrill [EMAIL PROTECTED] wrote: Rsync maintainers please review rsync bug https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=98740 The code in question is in socket.c in start_accept_loop. The user is getting these warning messages: - Jul 8 12:56:59 ftp kernel: application bug: rsync(1051) has SIGCHLD set to SIG_IGN but calls wait(). Jul 8 12:56:59 ftp kernel: (see the NOTES section of 'man 2 wait'). Workaround activated. - I was able to reproduce that error with rsync server and client on Red Hat OS's on a fairly consistent basis by running an rsync server (rsync version 2.5.6 protocol version 27 from cvs 7/14) from the command line (rsync --daemon), and connecting with an rsync-2.4.6 client with this command: rsync -avv my.server.com::test/one /tmp/rsync_test I also produced the same error by using the same command from an rsync-2.5.6 protocol version 26 client. Here is my /etc/rsyncd.conf file: - log file = /var/log/rsync [test] uid = rsync1 gid = rsync1 path = /rsync_test comment = Rsync Test - Comment - Quoting one of the bug messages, These messages are a warning that rsync is not standards compliant with respect to its handling of child processes. According to POSIX (3.3.1.3) it is unspecified what happens when SIGCHLD is set to SIG_IGN. This code in socket.c: - signal(SIGCHLD, SIG_IGN); /* we shouldn't have any children left hanging around but I have had reports that on Digital Unix zombies are produced, so this ensures that they are reaped */ #ifdef WNOHANG while (waitpid(-1, NULL, WNOHANG) 0); #endif - sets SIGCHLD to SIG_IGN, and *then* waits if WNOHANG is defined. It would appear that if there are still children left to be cleaned up in Digital Unix after setting SIGCHLD to SIG_IGN, that there might be a bug in Digital Unix that rsync is coding a fix for. One coding change could be to change the #ifdef WNOHANG to a #ifdef Digital Unix string, so that only Digital Unix OS's would include and execute the waitpid. This would stop warning messages from being produced. Thanks. -- Hardy Merrill Red Hat, Inc. -- 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
SIGCHLD SIG_IGN, then wait - warning messages
Rsync maintainers please review rsync bug https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=98740 The code in question is in socket.c in start_accept_loop. The user is getting these warning messages: - Jul 8 12:56:59 ftp kernel: application bug: rsync(1051) has SIGCHLD set to SIG_IGN but calls wait(). Jul 8 12:56:59 ftp kernel: (see the NOTES section of 'man 2 wait'). Workaround activated. - I was able to reproduce that error with rsync server and client on Red Hat OS's on a fairly consistent basis by running an rsync server (rsync version 2.5.6 protocol version 27 from cvs 7/14) from the command line (rsync --daemon), and connecting with an rsync-2.4.6 client with this command: rsync -avv my.server.com::test/one /tmp/rsync_test I also produced the same error by using the same command from an rsync-2.5.6 protocol version 26 client. Here is my /etc/rsyncd.conf file: - log file = /var/log/rsync [test] uid = rsync1 gid = rsync1 path = /rsync_test comment = Rsync Test - Comment - Quoting one of the bug messages, These messages are a warning that rsync is not standards compliant with respect to its handling of child processes. According to POSIX (3.3.1.3) it is unspecified what happens when SIGCHLD is set to SIG_IGN. This code in socket.c: - signal(SIGCHLD, SIG_IGN); /* we shouldn't have any children left hanging around but I have had reports that on Digital Unix zombies are produced, so this ensures that they are reaped */ #ifdef WNOHANG while (waitpid(-1, NULL, WNOHANG) 0); #endif - sets SIGCHLD to SIG_IGN, and *then* waits if WNOHANG is defined. It would appear that if there are still children left to be cleaned up in Digital Unix after setting SIGCHLD to SIG_IGN, that there might be a bug in Digital Unix that rsync is coding a fix for. One coding change could be to change the #ifdef WNOHANG to a #ifdef Digital Unix string, so that only Digital Unix OS's would include and execute the waitpid. This would stop warning messages from being produced. Thanks. -- Hardy Merrill Red Hat, Inc. -- 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: @ERROR access denied
Hugh, I did a quick test with 2.5.5, and here's what made it work for me - the 'read only' parameter. Here's my daemon /etc/rsyncd.conf file: log file = /var/log/rsync # this is a comment [rsync-test] uid=test gid=test read only=no path=/test_rsync it didn't work until I added the 'read only=no'. Here's a blurb from the rsync manpage: read only The read only option determines whether clients will be able to upload files or not. If read only is true then any attempted uploads will fail. If read only is false then uploads will be possible if file permissions on the server allow them. The default is for all modules to be read only. Give that a try and post back your results. HTH. -- Hardy Merrill Red Hat, Inc. Hugh E Cruickshank [EMAIL PROTECTED] wrote: Hi Hardy: Thanks for your comments. They are greatly appreciated. I tried your suggestion regarding the UID and GID. I set them to the owner and group of the /bak directory. Also I currently have the permissions on the directory at 777. I killed and restarted the server process and retried the command: rsync -avz fapmenu fisdev::bak The results were the same. As for the 2 configuration files, I supplied them because I had been testing with either box as the server, just trying to find something that would work. The 2 were setup slightly differently. The RH/pgiprd server was configured with the secrets file and strict modes = no where as the SCO/fisdev box was not. Again thanks for you comments. Regards, Hugh -- Hugh E Cruickshank, Forward Software, www.forward-software.com From: Hardy Merrill Sent: Monday, July 07, 2003 06:57 Hugh, I'm fairly new to rsync myself, so hopefully other rsync gurus can either confirm or correct my thoughts here. My comments are below. Hugh E Cruickshank [EMAIL PROTECTED] wrote: Hi All: I am new to rsync so be gentle with me. I have been able to get Me too :) rsync working enough to be able to list modules but not transfer files. When I try to transfer a file from the client to the server I use the command: rsync -avz fapmenu fisdev::bak The client displays the following messages: @ERROR: access denied to bak from pgiprd.forsoft.com (192.168.2.19) rsync: connection unexpectedly closed (80 bytes read so far) rsync error: error in rsync protocol data stream (code 12) at io.c(150) While the server issues the following log message: 2003/07/04 12:01:53 [15981] rsync denied on module bak from pgiprd.forsoft.com (192.168.2.19) In the above example fisdev is an SCO OSR5.0.4 system with rsync V2.5.5 that I have downloaded as source and compiled. The daemon was started from a root command line session. pgiprd is a RH8 system with rsync V2.5.5 as supplied by Red Hat. The daemon has been started via xinetd. It does not seem to matter which way I attempt to transfer the file I end up with very similar results. Nor does it seem to matter if I attempt with either root or a normal user. The rsyncd.conf file for fisdev contains: # # Global parameters: # #motd file= /var/rsync/rsyncd.motd log file = /var/rsync/rsyncd.log pid file = /var/rsync/rsyncd.pid #syslog facility= daemon #socket options = # # Default values for module parameters: # #use chroot = no #max connections = 0 #lock file= /var/rsync/rsyncd.lock #read only= no #list = yes #uid = -2 #gid = -2 hosts allow = fisdev pgiprd auth users= root hugh # # Module BAK: # [bak] comment = Default remote backup repository path = /bak Here's my first thought - the rsync-2.5.5 'man rsyncd.conf' states: uidThe uid option specifies the user name or user id that file transfers to and from that module should take place as when the daemon was run as root. In combination with the gid option this determines what file permissions are available. The default is uid -2, which is normally the user nobody. Notice that the default is nobody - since you have commented out the 'uid' line, the default of nobody takes over, and so if /bak directory does not give write permissions to user 'nobody', then you will get permissions errors like you are now seeing. My suggestion is to try specifying the 'uid' and 'gid' parameters with a user/group that does have access to /bak - if 'root' owns /bak, then start by setting 'uid' and 'gid' to 'root'. Although it's ok to have the 'uid' and 'gid' parameters as 'global' parameters
Re: @ERROR access denied
Ok, I think I've got it narrowed down. 1) First, comment out both 'hosts allow' and 'auth users', save it, kill and restart the rsync daemon, and try your rsync again. Hopefully that will work. 2) Uncomment the 'hosts allow' line, save, kill and restart daemon, and try rsync again - you will probably get the same error you had before. Your hosts allow line looked like this: hosts allow = fisdev pgiprd 3) Now, change the values of that hosts allow to be complete domain names, like 'fisdev.your.domain.com' and 'pgiprd.your.domain.com' and see if that works now. If you're not sure what the correct domain name is, on the rsync server machine (this works on linux - not sure about sco), do 'host fisdev' and see what it spits back. According to 'man rsyncd.conf', you can use dotted quad ip addresses, host names as determined by reverse dns, and a few other things. 4) Once you have 'hosts allow' working ok, then move on to 'auth users' - my thought is that that will go smoothly once the 'hosts allow' works right. Again, please post your results. -- Hardy Merrill Red Hat, Inc. Hugh E Cruickshank [EMAIL PROTECTED] wrote: Hi Hardy: Nice catch - I missed that one when I reviewed the man page. Unfortunately it made no difference. I have also tried moving the module params from the global section to the module section but that also made no difference - exactly same messages. Just to keep things straight, here is my latest rsyncd.conf: - # # Global parameters: # #motd file= /var/rsync/rsyncd.motd log file = /var/rsync/rsyncd.log pid file = /var/rsync/rsyncd.pid #syslog facility= daemon #socket options = # # Default values for module paramaters: # #use chroot = no #max connections = 0 #lock file= /var/rsync/rsyncd.lock #read only= no #list = yes #uid = 300 #gid = 200 #hosts allow = fisdev pgiprd #auth users = root hugh # # Module BAK: # [bak] comment = Default remote backup repository path = /bak read only = no uid = 300 gid = 200 hosts allow = fisdev pgiprd auth users= root hugh - Thanks for all your help. Regards, Hugh From: Hardy Merrill Sent: Monday, July 07, 2003 11:30 Hugh, I did a quick test with 2.5.5, and here's what made it work for me - the 'read only' parameter. Here's my daemon /etc/rsyncd.conf file: log file = /var/log/rsync # this is a comment [rsync-test] uid=test gid=test read only=no path=/test_rsync it didn't work until I added the 'read only=no'. Here's a blurb from the rsync manpage: read only The read only option determines whether clients will be able to upload files or not. If read only is true then any attempted uploads will fail. If read only is false then uploads will be possible if file permissions on the server allow them. The default is for all modules to be read only. Give that a try and post back your results. HTH. -- Hardy Merrill Red Hat, Inc. [SNIP] --- Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.497 / Virus Database: 296 - Release Date: 03/07/04 -- To unsubscribe or change options: http://lists.samba.org/mailman/listinfo/rsync Before posting, read: http://www.catb.org/~esr/faqs/smart-questions.html -- Hardy Merrill Red Hat, Inc. -- 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: @ERROR access denied
If anyone else has any ideas, please chime in, as I'm getting to the end of my list of things to try. The server is a SCO box and the client is a RH8 box. Hugh, let's go back to the beginning - in your first message, you stated: --- In the above example fisdev is an SCO OSR5.0.4 system with rsync V2.5.5 that I have downloaded as source and compiled. The daemon was started from a root command line session. pgiprd is a RH8 system with rsync V2.5.5 as supplied by Red Hat. The daemon has been started via xinetd. --- You say that the deamon was started from a root command line session, which to me means something like 'rsync --daemon'. Then you say that the daemon was started via xinetd. Which way have you been using going through these iterations? I forgot about your 'xinetd' statement, so in all my testing on this I've been using a server started from a root command line session - 'rsync --daemon'. If you've been running your server the same way (rsync --daemon), then I'm about out of ideas - it works for me, but not for you. I don't have a SCO box to test on. Hardy Hugh E Cruickshank [EMAIL PROTECTED] wrote: Hi Hardy: Well that seemed to do something. See my comments below. Thanks, Hugh -- Hugh E Cruickshank, Forward Software, www.forward-software.com From: Hardy Merrill Sent: Monday, July 07, 2003 12:38 1) First, comment out both 'hosts allow' and 'auth users', save it, kill and restart the rsync daemon, and try your rsync again. Hopefully that will work. This made a small difference. The client no reports: building file list ... done rsync: connection unexpectedly closed (28 bytes read so far) rsync error: error in rsync protocol data stream (code 12) at io.c(150) The server log shows: 2003/07/07 14:08:48 [3817] rsync to bak/ from pgiprd.forsoft.com (192.168.2.19) And there is now a core file in the /bak directory. 2) Uncomment the 'hosts allow' line, save, kill and restart daemon, and try rsync again - you will probably get the same error you had before. Your hosts allow line looked like this: hosts allow = fisdev pgiprd Back to the original messages. 3) Now, change the values of that hosts allow to be complete domain names, like 'fisdev.your.domain.com' and 'pgiprd.your.domain.com' and see if that works now. If you're not sure what the correct domain name is, on the rsync server machine (this works on linux - not sure about sco), do 'host fisdev' and see what it spits back. According to 'man rsyncd.conf', you can use dotted quad ip addresses, host names as determined by reverse dns, and a few other things. FQDN or IP address results in same messages as 1). 4) Once you have 'hosts allow' working ok, then move on to 'auth users' - my thought is that that will go smoothly once the 'hosts allow' works right. Since I did not get hosts allow working, I did not try anything with auth users. - HEC Again, please post your results. -- Hardy Merrill Red Hat, Inc. [snip] --- Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.497 / Virus Database: 296 - Release Date: 03/07/04 -- 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: @ERROR access denied
Hugh, I'm fairly new to rsync myself, so hopefully other rsync gurus can either confirm or correct my thoughts here. My comments are below. Hugh E Cruickshank [EMAIL PROTECTED] wrote: Hi All: I am new to rsync so be gentle with me. I have been able to get Me too :) rsync working enough to be able to list modules but not transfer files. When I try to transfer a file from the client to the server I use the command: rsync -avz fapmenu fisdev::bak The client displays the following messages: @ERROR: access denied to bak from pgiprd.forsoft.com (192.168.2.19) rsync: connection unexpectedly closed (80 bytes read so far) rsync error: error in rsync protocol data stream (code 12) at io.c(150) While the server issues the following log message: 2003/07/04 12:01:53 [15981] rsync denied on module bak from pgiprd.forsoft.com (192.168.2.19) In the above example fisdev is an SCO OSR5.0.4 system with rsync V2.5.5 that I have downloaded as source and compiled. The daemon was started from a root command line session. pgiprd is a RH8 system with rsync V2.5.5 as supplied by Red Hat. The daemon has been started via xinetd. It does not seem to matter which way I attempt to transfer the file I end up with very similar results. Nor does it seem to matter if I attempt with either root or a normal user. The rsyncd.conf file for fisdev contains: # # Global parameters: # #motd file= /var/rsync/rsyncd.motd log file = /var/rsync/rsyncd.log pid file = /var/rsync/rsyncd.pid #syslog facility= daemon #socket options = # # Default values for module parameters: # #use chroot = no #max connections = 0 #lock file= /var/rsync/rsyncd.lock #read only= no #list = yes #uid = -2 #gid = -2 hosts allow = fisdev pgiprd auth users= root hugh # # Module BAK: # [bak] comment = Default remote backup repository path = /bak Here's my first thought - the rsync-2.5.5 'man rsyncd.conf' states: uidThe uid option specifies the user name or user id that file transfers to and from that module should take place as when the daemon was run as root. In combination with the gid option this determines what file permissions are available. The default is uid -2, which is normally the user nobody. Notice that the default is nobody - since you have commented out the 'uid' line, the default of nobody takes over, and so if /bak directory does not give write permissions to user 'nobody', then you will get permissions errors like you are now seeing. My suggestion is to try specifying the 'uid' and 'gid' parameters with a user/group that does have access to /bak - if 'root' owns /bak, then start by setting 'uid' and 'gid' to 'root'. Although it's ok to have the 'uid' and 'gid' parameters as 'global' parameters, to be more precise, put the 'uid' and 'gid' parameters *inside* the [bak] module - that way there is no mistaking what the user and group must be for that particular module. The rsyncd.conf file for pgiprd contains: I think(?) the rsyncd.conf definition on the rsync *server* is the only one that matters. Since this one is for the *client*, I don't think this one matters at all. HTH. -- Hardy Merrill Red Hat, Inc. # # Global parameters: # #motd file= /var/rsync/rsyncd.motd log file = /var/rsync/rsyncd.log pid file = /var/rsync/rsyncd.pid #syslog facility= daemon #socket options = # # Default values for module paramaters: # #use chroot = no #max connections = 0 #lock file= /var/rsync/rsyncd.lock #read only= no #list = yes #uid = -2 #gid = -2 auth users= root hugh secrets file = /var/rsync/passwd strict modes = no hosts allow = fisdev pgiprd # # Module BAK: # [bak] comment = Default remote backup repository path = /bak Any thoughts, tips or suggestions greatly appreciated. By the way I have reviewed the man pages and FAQ without seeing anything obvious. I have also attempted a google search without much success. TIA Regards, Hugh -- Hugh E Cruickshank, Forward Software, www.forward-software.com --- Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.496 / Virus Database: 295 - Release Date: 03/07/03 -- 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: patch draft for extended attributes on linux
Martin Pool [EMAIL PROTECTED] wrote: On 25 Jun 2003, Hardy Merrill [EMAIL PROTECTED] wrote: Martin Pool [EMAIL PROTECTED] wrote: Nevertheless i do think it worth having something in patches. Yes, if I can get this working I think the best place for it to end up is as an unofficial patch. Are these patches archived somewhere on the rsync website? They should be in the list archives. I'm not trying to beat this to death - I just want to make sure I understand. So, patches are not kept in some separate patches folder somehwere on the rsync website, right? They can only be found either in, or attached to, the email messages they were sent to the rsync mailing list with - correct? It would be nice to set up a little patch grabber. That would be great. Please don't use that patch for anything other than decoration, it probably has bugs still. ok. Thanks. -- Hardy Merrill Red Hat, Inc. -- 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: patch draft for extended attributes on linux
Martin Pool [EMAIL PROTECTED] wrote: Nevertheless i do think it worth having something in patches. Yes, if I can get this working I think the best place for it to end up is as an unofficial patch. Are these patches archived somewhere on the rsync website? -- Hardy Merrill Red Hat, Inc. -- 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: Red Hat rsync - 'sign' patch
jw schultz [EMAIL PROTECTED] wrote: On Mon, Jun 09, 2003 at 01:56:34PM -0400, Hardy Merrill wrote: AFAICT, back in the vicinity of January 2002, a patch (call this patch 'A') was developed to close an 'rsync remote hole' - the patch switched variables in 'sum_struct' to size_t. According to some documentation I have read, that patch itself introduced some comparisons between signed and unsigned, which can cause rsync to not work properly. What documentation? Define improperly. I would like more than just vague hearsay assertions. A test case showing improper behaviour or specific code analysis showing a type mismatch that actually could (even if only in theory) impact behaviour. After much research and testing, I have removed this final 'sign' patch from Red Hat's rsync package. This 'sign' patch fixed a signed vs. unsigned comparison bug on systems that were not built with LFS support. Since Red Hat now (and for several versions back) builds with LFS support, this patch is no longer necessary going forward. So, for future Red Hat releases, Red Hat is not (at this point in time) maintaining any patches outside the plain vanilla publicly released rsync. In the future, if it becomes necessary for me to create a patch to address a bug, I will coordinate with the rsync developers to ensure that the bug and patch are reviewed, and proper action is taken. My goal is for Red Hat to NOT maintain any patches outside the public rsync version. Thanks. -- Hardy Merrill Red Hat, Inc. -- To unsubscribe or change options: http://lists.samba.org/mailman/listinfo/rsync Before posting, read: http://www.catb.org/~esr/faqs/smart-questions.html
Red Hat rsync - 'sign' patch
I recently became the new rsync maintainer for Red Hat,
and I just completed a review of the current patches that
we (Red Hat) maintain for 'rsync'. After removing three
unnecessary patches (either already incorporated into
rsync-2.5.6, or were outdated and couldn't be applied),
we are left with one patch - rsync-2.5.6-sign.patch -
which I have attached.
AFAICT, back in the vicinity of January 2002, a patch
(call this patch 'A') was developed to close an 'rsync
remote hole' - the patch switched variables in
'sum_struct' to size_t. According to some documentation
I have read, that patch itself introduced some comparisons
between signed and unsigned, which can cause rsync to
not work properly.
The patch I have included (rsync-2.5.6-sign.patch), which
is the only one currently that we (Red Hat) plan to
maintain going forward, is a patch that attempts to fix
the signed vs. unsigned comparison's introduced by patch
'A'.
Please review rsync-2.5.6-sign.patch and let me know what
your thoughts are. My hope is that the rsync
maintainers will address all the signed vs. unsigned
comparison issues in rsync - if that were done, I could
remove this final patch, and Red Hat could then maintain
rsync with *no* patches.
Rsync maintainers, please let me know your thoughts on
this patch.
Thanks.
Hardy Merrill
Red Hat, Inc.
--
Hardy Merrill
Red Hat, Inc.
diff -ur rsync-2.5.6/io.c rsync-2.5.6-sign/io.c
--- rsync-2.5.6/io.c2002-04-10 22:11:50.0 -0400
+++ rsync-2.5.6-sign/io.c 2003-06-05 14:05:54.0 -0400
@@ -605,7 +605,7 @@
}
while (len) {
- int n = MIN((int) len, IO_BUFFER_SIZE-io_buffer_count);
+ ssize_t n = MIN((ssize_t) len, IO_BUFFER_SIZE-io_buffer_count);
if (n 0) {
memcpy(io_buffer+io_buffer_count, buf, n);
buf += n;
Only in rsync-2.5.6-sign/: io.c.orig
diff -ur rsync-2.5.6/match.c rsync-2.5.6-sign/match.c
--- rsync-2.5.6/match.c 2002-04-09 02:11:06.0 -0400
+++ rsync-2.5.6-sign/match.c2003-06-05 14:05:54.0 -0400
@@ -190,13 +190,13 @@
sum = (s1 0x) | (s2 16);
tag_hits++;
- for (; j (int) s-count targets[j].t == t; j++) {
+ for (; j (ssize_t) s-count targets[j].t == t; j++) {
int l, i = targets[j].i;
if (sum != s-sums[i].sum1) continue;
/* also make sure the two blocks are the same length */
- l = MIN(s-n,len-offset);
+ l = MIN((ssize_t)s-n,len-offset);
if (l != s-sums[i].len) continue;
if (verbose 3)
@@ -216,7 +216,7 @@
/* we've found a match, but now check to see
if last_i can hint at a better match */
- for (j++; j (int) s-count targets[j].t == t; j++) {
+ for (j++; j (ssize_t) s-count targets[j].t == t; j++) {
int i2 = targets[j].i;
if (i2 == last_i + 1) {
if (sum != s-sums[i2].sum1) break;
@@ -232,7 +232,7 @@
matched(f,s,buf,offset,i);
offset += s-sums[i].len - 1;
- k = MIN((len-offset), s-n);
+ k = MIN((len-offset), (ssize_t)s-n);
map = (schar *)map_ptr(buf,offset,k);
sum = get_checksum1((char *)map, k);
s1 = sum 0x;
@@ -262,7 +262,7 @@
running match, the checksum update and the
literal send. */
if (offset last_match
- offset-last_match = CHUNK_SIZE+s-n
+ offset-last_match = (ssize_t)(CHUNK_SIZE+s-n)
(end-offset CHUNK_SIZE)) {
matched(f,s,buf,offset - s-n, -2);
}
Only in rsync-2.5.6-sign/: match.c.orig
--
To unsubscribe or change options: http://lists.samba.org/mailman/listinfo/rsync
Before posting, read: http://www.catb.org/~esr/faqs/smart-questions.html
ssh-basic test
I'm running 'make check' to run the testsuite, and I did it this way so the ssh-basic test would run: # export rsync_enable_ssh_tests=yes # make check I did set up ssh so this would run, and here's what I get for output: POSIXLY_CORRECT=1 TOOLDIR=`pwd` rsync_bin=`pwd`/rsync srcdir=. ./runtests.sh ./runtests.sh running in /usr/src/redhat/BUILD/rsync-2.5.6_no_segvpatch rsync_bin=/usr/src/redhat/BUILD/rsync-2.5.6_no_segvpatch/rsync srcdir=. testuser=root os=Linux merrill.boston.redhat.com 2.4.20-13.9smp #1 SMP Mon May 12 10:48:05 EDT 2003 i686 i686 i386 GNU/Linux preserve_scratch=no scratchbase=/usr/src/redhat/BUILD/rsync-2.5.6_no_segvpatch/testtmp PASS00-hello PASSchgrp PASSchown PASSdaemon-gzip-download PASSdaemon-gzip-upload PASSdaemon PASSdevices SKIPduplicates (Known minor bug in this code) PASShands PASShardlinks PASSlongdir - ssh-basic log follows Testing for symlinks using 'test -h' Test ssh: basic test: Running: /usr/src/redhat/BUILD/rsync-2.5.6_no_segvpatch/rsync -avH -e ssh --rsync-path=/usr/src/redhat/BUILD/rsync-2.5.6_no_segvpatch/rsync /usr/src/redhat/BUILD/rsync-2.5.6_no_segvpatch/testtmp.ssh-basic/from/ localhost:/usr/src/redhat/BUILD/rsync-2.5.6_no_segvpatch/testtmp.ssh-basic/to building file list ... link_stat /usr/src/redhat/BUILD/rsync-2.5.6_no_segvpatch/testtmp.ssh-basic/from/. : No such file or directory done wrote 25 bytes read 20 bytes 90.00 bytes/sec total size is 0 speedup is 0.00 rsync error: some files could not be transferred (code 23) at main.c(620) - check how the files compare with diff: ./testsuite/ssh-basic.test: line 1: cd: /usr/src/redhat/BUILD/rsync-2.5.6_no_segvpatch/testtmp.ssh-basic/from/: No such file or directory diff: /usr/src/redhat/BUILD/rsync-2.5.6_no_segvpatch/testtmp.ssh-basic/from//./doc/.cvsignore: No such file or directory = It does go on from there, but just more of the same 'No such file or directory' errors. Notice .../testtmp.ssh-basic/from/ and .../testtmp.ssh-basic/to listed in that output above. The testtmp.ssh-basic directory contains 'ls-from' and 'ls-to' files (both 0 length), but no 'from' and 'to' directories. Did I do something wrong, or is there something missing? Thanks. -- Hardy Merrill Red Hat, Inc. -- 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: ssh-basic test
Steve Bonds [EMAIL PROTECTED] wrote: The broken ssh-basic test is fixed in the CVS version of rsync, but not in 2.5.6. Yup, the ssh-basic test in the CVS version *does* work - I just downloaded it and tried it. It should work in the next release of rsync. You can get the new test from the rsync CVS server easily via the cvsweb interface: http://www.samba.org/cgi-bin/cvsweb/rsync/testsuite/ssh-basic.test?rev=1.6content-type=text/x-cvsweb-markup Thanks. -- Hardy Merrill Red Hat, Inc. -- 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: tty settings with rsync -e ssh interrupt
jw schultz [[EMAIL PROTECTED]] wrote:
On Thu, Feb 06, 2003 at 04:19:36PM -0500, Hardy Merrill wrote:
jw schultz [[EMAIL PROTECTED]] wrote:
On Thu, Feb 06, 2003 at 03:46:11PM -0500, Hardy Merrill wrote:
I'm following up on a bug reported back in May 2002:
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=64689
this bug was also reported to the rsync mailing list:
http://www.mail-archive.com/rsync@lists.samba.org/mail5.html#04250
I couldn't find any discussion other than the reporters post
describing the problem.
Anyway, I just downloaded the new rsync-2.5.6 source, installed
it, and found that the bug still exists. This problem shows
itself when using -e ssh, and Ctrl-C'ing at the ssh password
prompt - the terminal gets screwed up.
Anyone have any insight on this?
Thanks.
--
Hardy Merrill
Senior Software Engineer
Red Hat, Inc.
Blame ssh. It is failing to restore the tty settings.
Please excuse my naivete - I'm a relative newbie to rsync - how
come when you run ssh by itself and Ctrl-C at the password
prompt, your terminal is fine? Why is it only affected when
run with -e from rsync?
Sorry. Don't blame ssh. Rsync is messing things up.
I've attached a cleaned up strace output.
What is happening is that both rsync and ssh get the SIGINT.
Unfortunately, before ssh has had a sufficient chance to
process the SIGINT rsync sends it a SIGUSR1 as part of
cleanup. ssh doesn't catch SIGUSR1 so it just exits.
This is the first i've looked at this part of rsync so i'd
be cautious about changing any of the timings. However, it
does seem to me that a more correct behavior on receiving a
SIGINT would be to forward that to the children and give
them a chance to clean up before sending any more signals.
Where does this go from here? Will a solution to this problem
be persued?
Thanks.
--
Hardy Merrill
Senior Software Engineer
Red Hat, Inc.
rsync rt_sigaction(SIGUSR1, {0x8050cc0, [USR1], SA_RESTART|0x400}, {SIG_DFL},
8) = 0
rsync rt_sigaction(SIGUSR2, {0x8050ce0, [USR2], SA_RESTART|0x400}, {SIG_DFL},
8) = 0
rsync rt_sigaction(SIGCHLD, {0x8050d10, [CHLD], SA_RESTART|0x400}, {SIG_DFL},
8) = 0
rsync rt_sigaction(SIGINT, {0x804a840, [INT], SA_RESTART|0x400}, {SIG_DFL}, 8)
= 0
rsync rt_sigaction(SIGHUP, {0x804a840, [HUP], SA_RESTART|0x400}, {SIG_DFL}, 8)
= 0
rsync rt_sigaction(SIGTERM, {0x804a840, [TERM], SA_RESTART|0x400}, {SIG_DFL},
8) = 0
rsync rt_sigaction(SIGPIPE, {SIG_IGN}, {SIG_DFL}, 8) = 0
rsync fork()= [ssh-pid]
ssh execve(/usr/bin/ssh, [ssh, -l, pgsql, leto, rsync, --server,
--sender, -logDtpr, ., /etc], [/* 65 vars */]) = 0
ssh rt_sigaction(SIGPIPE, {SIG_IGN}, {SIG_IGN}, 8) = 0
ssh fcntl64(3, F_SETFL, O_RDONLY|O_NONBLOCK) = 0
ssh open(/dev/tty, O_RDWR|O_LARGEFILE) = 4
ssh rt_sigaction(SIGINT, {0x806f04c, [], 0x400}, {SIG_DFL}, 8) = 0
ssh rt_sigaction(SIGHUP, {0x806f04c, [], 0x400}, {SIG_DFL}, 8) = 0
ssh rt_sigaction(SIGQUIT, {0x806f04c, [], 0x400}, {SIG_DFL}, 8) = 0
ssh rt_sigaction(SIGTERM, {0x806f04c, [], 0x400}, {SIG_DFL}, 8) = 0
ssh rt_sigaction(SIGTSTP, {0x806f04c, [], 0x400}, {SIG_DFL}, 8) = 0
ssh rt_sigaction(SIGTTIN, {0x806f04c, [], 0x400}, {SIG_DFL}, 8) = 0
ssh rt_sigaction(SIGTTOU, {0x806f04c, [], 0x400}, {SIG_DFL}, 8) = 0
ssh ioctl(4, TCGETS, {B38400 opost isig icanon echo ...}) = 0
ssh ioctl(4, TCSETSF, {B38400 opost isig icanon -echo ...}) = 0
ssh write(4, pgsql@leto\'s password: , 23) = 23
ssh read(4, unfinished ...
rsync ... select resumed )= ? ERESTARTNOHAND (To be restarted)
ssh ... read resumed 0xbfffe783, 1) = ? ERESTARTSYS (To be restarted)
rsync --- SIGINT (Interrupt) ---
rsync rt_sigaction(SIGUSR1, {SIG_IGN}, unfinished ...
ssh --- SIGINT (Interrupt) ---
rsync ... rt_sigaction resumed {0x8050cc0, [USR1], SA_RESTART|0x400}, 8) = 0
ssh sigreturn( unfinished ...
rsync rt_sigaction(SIGUSR2, {SIG_IGN}, unfinished ...
ssh ... sigreturn resumed ) = ? (mask now [RTMIN])
rsync ... rt_sigaction resumed {0x8050ce0, [USR2], SA_RESTART|0x400}, 8) = 0
ssh write(4, \n, 1 unfinished ...
rsync wait4([ssh-pid], unfinished ...
ssh ... write resumed ) = 1
rsync ... wait4 resumed 0xbfffeb00, WNOHANG, NULL) = -1 ECHILD (No child
processes)
ssh ioctl(4, TCSETSF unfinished ...
rsync getpid( unfinished ...
ssh ... ioctl resumed , {B38400 opost isig icanon echo ...}) = 0
rsync ... getpid resumed )= 17409
ssh rt_sigaction(SIGINT, {SIG_DFL}, unfinished ...
rsync kill([ssh-pid], SIGUSR1 unfinished ...
ssh ... rt_sigaction resumed NULL, 8) = 0
rsync ... kill resumed ) = 0
ssh --- SIGUSR1 (User defined signal 1) ---
rsync write(2, rsync error: received SIGUSR1 or..., 66) = 66
rsync _exit(20
tty settings with rsync -e ssh interrupt
I'm following up on a bug reported back in May 2002: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=64689 this bug was also reported to the rsync mailing list: http://www.mail-archive.com/rsync@lists.samba.org/mail5.html#04250 I couldn't find any discussion other than the reporters post describing the problem. Anyway, I just downloaded the new rsync-2.5.6 source, installed it, and found that the bug still exists. This problem shows itself when using -e ssh, and Ctrl-C'ing at the ssh password prompt - the terminal gets screwed up. Anyone have any insight on this? Thanks. -- Hardy Merrill Senior Software Engineer Red Hat, Inc. -- 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: tty settings with rsync -e ssh interrupt
jw schultz [[EMAIL PROTECTED]] wrote: On Thu, Feb 06, 2003 at 03:46:11PM -0500, Hardy Merrill wrote: I'm following up on a bug reported back in May 2002: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=64689 this bug was also reported to the rsync mailing list: http://www.mail-archive.com/rsync@lists.samba.org/mail5.html#04250 I couldn't find any discussion other than the reporters post describing the problem. Anyway, I just downloaded the new rsync-2.5.6 source, installed it, and found that the bug still exists. This problem shows itself when using -e ssh, and Ctrl-C'ing at the ssh password prompt - the terminal gets screwed up. Anyone have any insight on this? Thanks. -- Hardy Merrill Senior Software Engineer Red Hat, Inc. Blame ssh. It is failing to restore the tty settings. Please excuse my naivete - I'm a relative newbie to rsync - how come when you run ssh by itself and Ctrl-C at the password prompt, your terminal is fine? Why is it only affected when run with -e from rsync? Thanks. Hardy -- To unsubscribe or change options: http://lists.samba.org/mailman/listinfo/rsync Before posting, read: http://www.tuxedo.org/~esr/faqs/smart-questions.html
