ansaurus

Question

Answer 1

A:

Do you have size limit on the users directory? Might want try to dump it to temp first.

sha 2010-02-24 05:50:41

I don't think the size limit is a factor here. Although the file was getting cut off half-way through, the directory had 20 identical backups all of the same size. I tried dumping to /tmp and it gets cut off at the same point. The crontab is being executed at the super user level, as well, so it should have pretty unfettered access to the filesystem.

Andrew 2010-02-24 06:17:14

One other thought:- Try to wrap svnadmin call into shell scrtipt. Add date/time stamps before and after calling svnadmin. Redirect output to some log file. Also record svnadmin result code. This will give you some idea on how successful was call of svnadmin and how long did it take.- Try to re-schedule this task to a different time (I've some some crazy cron bugs associated with specific date and time of execution).

sha 2010-02-26 04:28:32

Sure enough, when I capture the return code in a shell script, svnadmin dump comes back with "0" when I sudo-execute it manually but it comes back with "1" when crontab does it. I've also logged /usr/bin/id and the information there is identical for both me and crontab. The script is being run in identical user contexts.There must be some crontab config value I'm not seeing here. None of this makes any sense to me. I'll keep digging.

Andrew 2010-02-27 04:51:55

Answer 2

+1 A:

First of all, make sure that svnadmin is on the PATH environment variable of the cron job. You may have to specify a full path for /usr/bin/svnadmin or whatever is appropriate.

Also, rather than svnadmin dump, you may want to look into svnadmin hotcopy which is a tool intended for backups of the repository.

Avi 2010-02-24 05:51:11

I've tried adding the absolute path, but makes no difference. svnadmin _is_ executing, it just doesn't seem to be finishing. I wanted to avoid using hotcopy because it's not as portable. I can (potentially) grab a dump of the repository and use it to create a nightly snapshot of the server in the event of a hardware failure. Well, that's the idea anyway.

Andrew 2010-02-24 06:20:00

Try capturing the standard error of the command into a file, so you can see if it is reporting an error.

Avi 2010-02-24 06:29:14

Andrew 2010-02-24 08:20:34

Answer 3

A:

So, I don't know what the real issue is here, but if I route the STDERR of svnadmin to /dev/null when I do the dump, everything goes well. I tried using the "quiet" flag (-q) and it also succeeds. I'm assuming that when a shell script running from a crontab encounters enough text in STRERR, it stops execution of whatever it's running and goes to the next instruction. I've done an MD5 on a manual file and a scheduled file and they are identical. This seems to be resolved. So if anyone encounters this issue themselves, this is the shell script I used to successfully get past the early truncation. It's a little verbose. Sorry.

#!/bin/sh
echo "STARTING AT $(date +\%Y/\%m/\%d/T%I:\%M:\%S)" >> /home/andrew/svnlog.txt
rm /tmp/andrewMobileApp.dump
svnadmin dump /var/svn/repos/andrewMobileApp > /tmp/andrewMobileApp.dump 2>/dev/null
echo "svnadmin exited with code $?" >> /home/andrew/svnlog.txt
gzip -c /tmp/andrewMobileApp.dump > "/home/andrew/svnbackups/andrewMobileApp.dump.$(date +\%Y\%m\%d\%I\%M\%S).txt.gz"
echo "gzip exited with code $?" >> /home/andrew/svnlog.txt
echo "DONE AT $(date +\%Y/\%m/\%d/T%I:\%M:\%S)" >> /home/andrew/svnlog.txt
echo  "-----" >> /home/andrew/svnlog.txt

This script is invoked through a super-user crontab.

Andrew 2010-02-27 07:39:29

Answer 4

+1 A:

I submitted this as a bug in the Debian cron package, since I was experiencing it there as well (under a vserver). See bug #577133 in Debian. Christian Kastner patched the bug, by adding code to bypass all the mail processing code if no MTA is found.

Bob Feldbauer 2010-04-22 23:37:10

ansaurus

tags:

views:

answers:

CRONTAB doesn't finish svndump

related questions