[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: hot-backup.py hangs

From: Philip Martin <philip_at_codematters.co.uk>
Date: 2003-10-23 04:14:44 CEST

Malcolm Fernandes <mfernandes@octigabay.com> writes:

>> We are using:
>> svn, version 0.30.0 on Suse Linux
>> The hot-backup script ran successfully on several earlier attempts.
>> Scenario:
>> Was committing several hundred files and was simultaneously checking out a
>> project from another xterm (http access).
>> While the two subversion operations were running, I fired up the hot-backup
>> script. It ran for a while and then hung after re-copying the logfiles.
>> Re-copying logfile 'log.0000000228'...
>> Re-copying logfile 'log.0000000229'...
>> Backup completed.
>> An strace of the process revealed:
>> /usr/bin/strace -p27646
>> write(2, "Log sequence error: page LSN 227"..., 64) = ? ERESTARTSYS (To be
>> restarted)
>> Interrupted the script after about half-hour and got this traceback
>> message: Traceback (most recent call last):
>> File "./hot-backup.py", line 160, in ?
>> stdout_lines = outfile.readlines()
>> KeyboardInterrupt
>> Attempted to run db_recover manually and got this error:
>> # /usr/bin/db_recover -h

I see hot-backup.py is currently using db_archive and db_recover
directly, I think using svnadmin would be better. The script also has
/usr/local/BerkeleyDB.4.0/bin hardcoded, did you modify it to use

Looking at hot-backup.py itself I think there is a race choosing the
name of the backup dir. The script gets a listing of the backup
directory, then chooses a subdir name based on that listing and then
copies into that subdir. If two scripts run simultaneously (say the
one you start manually and the one started by the commit) they could
get the same directory listing, choose the same name, and then backup
into the same subdir. That would probably cause the hang you see.

There is also the known race that could potentially delete log files
that have not been backed up fully, but that should not cause your

Overall hot-backup.py is less than perfect :-( It may be time for me
to get round to reviewing the 'svnadmin hotcopy' patch. I was
initially enthusiatic, but my enthusiasm waned when I realised that it
could not be made robust in a few corner cases (obscure things like
set_data_dir). However an admin would have to modify hot-backup.py to
handle set_data_dir, and given the history of hot-backup.py any such
modification might well be imperfect. That might be enough to justify
a less flexible but more reliable 'svnadmin hotcopy' based system.

Philip Martin
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Thu Oct 23 04:15:29 2003

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.