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.
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.
Erik, 2.5.5 rsync crashes and burns my hard disk, you are indeed lucky to get a segmentation fault. When I reported flakiness I was told it was my hardware. I upgraded my hardware - no difference. Then I was told to change my 2.4.x kernel. Why? it runs everything else, and has reliably for over a year? Yet every time I run rsync to back up from /dev/hda1 to /dev/hdc1 it crashes and takes the whole system down. cp of the same filesystem works, but not rsync. Depending on the number of "v"s and the --exclude options it crashes at different points in the process. While rebooting I often have to fsck from "maintenance mode". That is not nice. In fairness, though, I am backing up a heck of a lot of files. So I wish you luck with your cron segmentation faults. But the above are my observations. With SuSE Linux, not RedHat 7.2. Although you would likely be running a similar kernel version to mine: "Linux version 2.4.10-4GB (root@Pentium.suse.de) (gcc version 2.95.3 20010315 (SuSE))" I keep hoping the next version has somehow gotten this fixed... Sincerely (Dr) Trevor G Marshall Contributing Editor, BYTE.com http://www.TrevorMarshall.com At 09:47 AM 10/1/2002 -0400, you 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 faultrsync -acx --delete ${_backup_dirs} backup-server::backup-client> >If I run rsync from the command-line everything works as expected and no >segmentation fault. > >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 >
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 >
Erik: One more thing to try: redirect in /dev/null to the rsync command.
At one time, at least, its behaviour was different based on the nature of
its STDIN. Make sure STDERR and STDIN are redirected somewhere, too...
either a file or null.
Some programs test their STDIO to see what environment they're running in,
and may do something unexpected if they see what appears to be a socket,
for instance(as is the case with some implementations of cron).
I've run into a few other things that didn't want to run from cron until
I
overrode STDIO.
Tim Conway
conway.tim@sphlihp.com reorder name and reverse domain
303.682.4917 office, 303.921.0301 cell
Philips Semiconductor - Longmont TC
1880 Industrial Circle, Suite D
Longmont, CO 80501
Available via SameTime Connect within Philips, caesupport2 on AIM
"There are some who call me.... Tim?"
Erik Enge <eenge@prium.net>
Sent by: rsync-admin@lists.samba.org
10/01/2002 12:49 PM
To: rsync@lists.samba.org
cc: (bcc: Tim Conway/LMT/SC/PHILIPS)
Subject: Re: rsync 2.5.5 segmentation fault on Linux x86.
Classification:
Paul Haas <paulh@hamjudo.com> writes:
> 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 also noticed in the logs that rsync exists with "exit code 12":
Oct 1 01:31:59 backup-server inetd[1282]: pid 1935: exit status 12
Oct 1 02:06:37 backup-server rsyncd[1936]: wrote 32 bytes read
831588069 bytes total
size 36516321121
Does that tell us anything more of what might be the problem?
Erik.
--
To unsubscribe or change options:
http://lists.samba.org/mailman/listinfo/rsync
Before posting, read: http://www.tuxedo.org/~esr/faqs/smart-questions.html
stdin may be closed, or may appear to be a socket, fifo, pipe, or file,
probably some stuff i don't know about. I remember rsync used to look at
something in stdio, and act as if it were invoked with --daemon, even
without that flag. Somebody'll correct the details. I just know that I
have had, in the past, applications that didn't run in cron without <
>
and 2>.
Tim Conway
conway.tim@sphlihp.com reorder name and reverse domain
303.682.4917 office, 303.921.0301 cell
Philips Semiconductor - Longmont TC
1880 Industrial Circle, Suite D
Longmont, CO 80501
Available via SameTime Connect within Philips, caesupport2 on AIM
"There are some who call me.... Tim?"
Erik Enge <eenge@prium.net>
Sent by: rsync-admin@lists.samba.org
10/01/2002 02:10 PM
To: Tim Conway/LMT/SC/PHILIPS@AMEC
cc: rsync@lists.samba.org
Subject: Re: rsync 2.5.5 segmentation fault on Linux x86.
Classification:
tim.conway@philips.com writes:
> Erik: One more thing to try: redirect in /dev/null to the rsync
> command. At one time, at least, its behaviour was different based on
> the nature of its STDIN. Make sure STDERR and STDIN are redirected
> somewhere, too... either a file or null.
All our output are redirected to a file. What would STDIN for a cronjob
be? Somehow that doesn't seem to make sense.
Thanks for your response,
Erik.
--
To unsubscribe or change options:
http://lists.samba.org/mailman/listinfo/rsync
Before posting, read: http://www.tuxedo.org/~esr/faqs/smart-questions.html