- Package:
- subversion
- Source:
- subversion
- Description:
- Advanced version control system
- Submitter:
- Adrian 'Dagurashibanipal' von Bidder
- Date:
- 2014-07-17 21:00:05 UTC
- Severity:
- wishlist
Hi,
svn@zbasel:~$ ./SCRIPTS/do-backup
Traceback (most recent call last):
File "/usr/lib/subversion/hot-backup.py", line 97, in ?
youngest = string.strip(stdout_lines[0])
IndexError: list index out of range
(do-backup script is simple, see below)
Sometimes, the database is shredded after this (svn client commands
insist that I should run DB recovery, but svnadmin recover also says to
run DB recovery, so I'm at a loss how to recover). But right now, it is
of course unreproducible.
I will keep the next repository when it is killed that way.
cheers
- -- vbi
=============== do-backup =================
#!/bin/sh
for i in /var/lib/subversion/[a-z]*; do
/usr/lib/subversion/hot-backup.py \
$i /var/lib/subversion/BACKUP > /dev/null
done
===========================================
- -- System Information:
Debian Release: testing/unstable
APT prefers testing
APT policy: (700, 'testing'), (600, 'unstable'), (60, 'experimental')
Architecture: i386 (i686)
Kernel: Linux 2.4.22
Locale: LANG=POSIX, LC_CTYPE="POSIX"
Versions of packages subversion depends on:
ii db4.2-util 4.2.52-8 Berkeley v4.2 Database Utilities
ii libapr0 2.0.48-7 The Apache Portable Runtime
ii libc6 2.3.2.ds1-11 GNU C Library: Shared libraries and
ii libdb4.2 4.2.52-8 Berkeley v4.2 Database Libraries
ii libexpat1 1.95.6-6 XML parsing C library - runtime
ii libldap2 2.1.23-1 OpenLDAP libraries
ii libneon24 0.24.4-3 An HTTP and WebDAV client library
ii libssl0.9.7 0.9.7c-5 SSL shared libraries
ii libsvn0 1.0.0-1 Shared libraries used by Subversion
ii libxml2 2.6.6-1 GNOME XML library
ii patch 2.5.9-1 Apply a diff file to an original
ii python2.3 2.3.3-5 An interactive high-level
ii zlib1g 1.2.1-4 compression library - runtime
- -- no debconf information
iKcEARECAGcFAkBNb6RgGmh0dHA6Ly9mb3J0eXR3by5jaC9sZWdhbC9ncGcvZW1h
aWwuMjAwMjA4MjI/dmVyc2lvbj0xLjUmbWQ1c3VtPTVkZmY4NjhkMTE4NDMyNzYw
NzFiMjVlYjcwMDZkYTNlAAoJEIukMYvlp/fWOpkAoLWeKcxdRdJrs1a1c6LIcQ1G
TceMAJ0WJgOO3UrXIhoAvrn4n2RzmQCh5Q==
=cnie
-----END PGP SIGNATURE-----
If I am reading this right then : svnlook youngest /path/to/repos did not produce any output, that killed the script. It is possible that we have more than one problem here: 1. svnlook fails. Is this because the repository is already corrupt? Or did svnlook corrupt the repository while it was failing? 2. If svnlook can fail, perhaps hot-backup.py should exit with a more descriptive error message. What filesystem is the repository on? What do you have installed from experimental? Thanks for the report, David
my outgoing mailserver (wanadoo.fr) got blocked by fortytwo.ch, please see teh BTS (http://bugs.debian.org/236994) for my followup and request for further info.
Thanks. Looking at how many mail transactions from wanadoo (not just IP space, but the regular mailservers, too) I reject every week, this situation unfortunately is unlikely to change. :-( (From: address set to special for now. I'll have to invalidate that address soon, though, now that it's harvestable in the bts...) (Does X-Debbugs-Cc work for followups?) Now, on-topic: | svn@zbasel:~$ svnadmin verify ./avbidder | * Verified revision 0. | * Verified revision 1. | * Verified revision 2. | * Verified revision 3. | * Verified revision 4. | * Verified revision 5. | ... | * Verified revision 73. | * Verified revision 74. | * Verified revision 75. | * Verified revision 76. | * Verified revision 77. | * Verified revision 78. | svn@zbasel:~$ svnlook youngest ./avbidder | 78 | svn@zbasel:~$ ./SCRIPTS/do-backup avbidder | svn@zbasel:~$ ls BACKUP/ | avbidder-76 avbidder-78 | svn@zbasel:~$ Conclusion: Arrgh! But I had it, just 1 minute ago. svnlook did really fail. So let's do it without verify first. No, that is not it. But we come closer: might it be something with file permissions/file ownership? So, do a commit from one of the projects (I do this via ssh, as another user, the whole repo is chmod g+w) repository permissions after a commit: ================== svn@zbasel:~$ ls -lR avbidder avbidder: total 11 -rw-rw-r-- 1 svn svn 376 Mar 7 03:24 README.txt drwxrwxr-x 2 svn svn 80 Mar 7 03:24 conf drwxrwxr-x 2 svn svn 48 Mar 7 03:24 dav drwxrwxr-x 2 svn svn 480 Mar 9 16:42 db -rw-rw-r-- 1 svn svn 2 Mar 7 03:24 format drwxrwxr-x 2 svn svn 232 Mar 7 03:24 hooks drwxrwxr-x 2 svn svn 104 Mar 7 03:24 locks avbidder/conf: total 4 -rw-rw-r-- 1 svn svn 1101 Mar 7 03:24 svnserve.conf avbidder/dav: total 0 avbidder/db: total 2636 -rw-rw-r-- 1 svn svn 1738 Mar 7 03:24 DB_CONFIG -rw-rw-r-- 1 svn svn 8192 Mar 9 07:58 __db.001 -rw-rw-r-- 1 svn svn 270336 Mar 9 07:58 __db.002 -rw-rw-r-- 1 svn svn 327680 Mar 9 07:58 __db.003 -rw-rw-r-- 1 svn svn 737280 Mar 9 07:58 __db.004 -rw-rw-r-- 1 svn svn 16384 Mar 9 07:58 __db.005 -rw-rw-r-- 1 svn svn 57344 Mar 10 07:42 changes -rw-rw-r-- 1 svn svn 8192 Mar 10 07:42 copies -rw-rw-r-- 1 svn svn 1044487 Mar 9 16:42 log.0000000003 -rw-rw-r-- 1 svn svn 93019 Mar 10 07:42 log.0000000004 -rw-rw-r-- 1 svn svn 65536 Mar 10 07:42 nodes -rw-rw-r-- 1 svn svn 81920 Mar 10 07:42 representations -rw-rw-r-- 1 svn svn 8192 Mar 10 07:42 revisions -rw-rw-r-- 1 svn svn 462848 Mar 10 07:42 strings -rw-rw-r-- 1 svn svn 32768 Mar 10 07:42 transactions -rw-rw-r-- 1 svn svn 8192 Mar 10 07:42 uuids avbidder/hooks: total 20 -rw-rw-r-- 1 svn svn 1390 Mar 7 03:24 post-commit.tmpl -rw-rw-r-- 1 svn svn 1508 Mar 7 03:24 post-revprop-change.tmpl -rw-rw-r-- 1 svn svn 2243 Mar 7 03:24 pre-commit.tmpl -rw-rw-r-- 1 svn svn 1952 Mar 7 03:24 pre-revprop-change.tmpl -rw-rw-r-- 1 svn svn 1500 Mar 7 03:24 start-commit.tmpl avbidder/locks: total 8 -rw-rw-r-- 1 svn svn 295 Mar 7 03:24 db-logs.lock -rw-rw-r-- 1 svn svn 460 Mar 7 03:24 db.lock ================== And with this, it works, too. But I noticed, that sometimes, some files are owned by avbidder.svn instead of svn.svn. But right now, this doesn't seem to be the case. Hnmn. I guess I'll have to report back when I have such a case again as I don't know which files were changed. (I did cp -a as svn user to back up before trying the first time. This first time, on the original repository, produced the error, but then I deleted that repo and restored from the backup so that I could do a verify first. The 'new' repo, of course, had all file ownerships to svn.svn. reiserfs, 2.4.22 The server is a few years old, but I did never have stability problems with it (postgresql database on the same partition - I expect I'd have noticed if there were fundamental problems). IIRC nothing on the server, and only KDE3.2 on the client (well, parts. Most things entered sid by now). How do I check this efficiently? The other question might be what have I still installed from stable [which is relevant here]? The whole installation started out as stable, and so it's quite a mix. Thanks for trying to help. cheers -- vbi
tags 236994 unreproducible quit sorry about that I didn't mean to cc submit@d.o. One thing you can do is to take experimental out of sources.list and then dselect will list the packages as Obsolete/local packages. I don't know if there is a more direct way of doign that. My feeling is that the problem is most likely a permission issue or some sort of transient error that svnlook is not handling properly. Let me know if you manage to consistently reproduce this. Thanks,
tags 236994 unreproducible quit sorry about that I didn't mean to cc submit@d.o. One thing you can do is to take experimental out of sources.list and then dselect will list the packages as Obsolete/local packages. I don't know if there is a more direct way of doign that. My feeling is that the problem is most likely a permission issue or some sort of transient error that svnlook is not handling properly. Let me know if you manage to consistently reproduce this. Thanks,
tags 236994 -unreproducible severity 236994 minor retitle 236994 better error messages on permission problems, please Yo! It's all properly documented after all... http://svnbook.red-bean.com/book/book.html#svn-ch-6-sect-5 | Another common problem is often encountered on Unix-like systems. As a | repository is used, BerkeleyDB occasionally creates new logfiles to journal | its actions. Even if the repository is wholly owned by the svn group, these | newly created files won't necessarily be owned by that same group, which | then creates more permissions problems for your users. A good workaround is | to set the group SUID bit on the repository's db directory. This causes all | newly-created logfiles to have the same group owner as the parent directory. The file db/log.000000x was, of course, created with not only ownership, but also group ownership set to my user instead of the subversion user. I only looked at the permission bits, and my users group could read the files all right... Conclusion: I would have had it much quicker if the error message would have indicated a permission problem in the first place. I wonder if - sbuversion should set umask 002 itself if it detects that the repository is group writable - subversion should set g+s on the db directory from the beginning in all cases (if the repository is not group writeable, this won't do any harm. If it is group writable, it avoids this problem). Yes, give the user enough rope to shoot himself (or whatever), but imho there's no need for the gun to be loaded, pointed at the user and have the safety catch off right from the beginning ;-) greetings -- vbi
The documentation shown in the last message still exists. The link is broken, but it can be found at http://svnbook.red-bean.com/en/1.8/svn.serverconfig.multimethod.html. I do not know if the error message itself still exists, and have no way of reproducing it. Can someone verify that the error still exists, and whether or not it should be forwarded to Apache?