You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@subversion.apache.org by Ben Collins-Sussman <su...@collab.net> on 2005/07/05 20:06:04 UTC

Re: write-lock not removed with fsfs?

Bruce, did you ever figure this problem out?


On Apr 28, 2005, at 11:32 AM, Bruce Christensen wrote:

> We're running svn client 1.1.4 on Fedora Core 3, accessing a server
> running svn 1.1.1 on RH Enterprise Linux AS  release 4 using the
> svn+ssh protocol.
>
> Whenever one of our users does a commit, svnrep/db/write-lock is
> created, which is to expected, However, the lock is never removed when
> the commit is finished, which means that no other users can commit
> until someone manually removes the write-lock file from the
> repository.
>
> File permissions immediately after user brucec does a commit are as  
> follows:
>
> drwxrwxr-x   7 root      serveradmin  4096 Apr 22 16:57 svnrep
>
> [brucec@admin Raid]$ ls -l /Raid | grep svnrep
> drwxrwxr-x   7 root      serveradmin  4096 Apr 22 16:57 svnrep
> [brucec@admin Raid]$ ls -l /Raid/svnrep/
> total 56
> drwxrwxr-x  2 root serveradmin 4096 Apr 22 16:57 conf
> drwxrwxr-x  2 root serveradmin 4096 Apr 22 16:57 dav
> drwxrwsr-x  5 root serveradmin 4096 Apr 28 10:27 db
> -r--r--r--  1 root serveradmin    2 Apr 22 16:57 format
> drwxrwxr-x  2 root serveradmin 4096 Apr 22 16:57 hooks
> drwxrwxr-x  2 root serveradmin 4096 Apr 22 16:57 locks
> -rw-rw-r--  1 root serveradmin  379 Apr 22 16:57 README.txt
> [brucec@admin Raid]$ ls -l /Raid/svnrep/db
> total 52
> -rw-rw-r--  1 brucec serveradmin    8 Apr 28 10:27 current
> -rw-rw-r--  1 root   serveradmin    5 Apr 22 16:57 fs-type
> drwxrwsr-x  2 root   serveradmin 4096 Apr 28 10:27 revprops
> drwxrwsr-x  2 root   serveradmin 4096 Apr 28 10:27 revs
> drwxrwsr-x  2 root   serveradmin 4096 Apr 28 10:27 transactions
> -rw-rw-r--  1 root   serveradmin   37 Apr 22 16:57 uuid
> -rw-r--r--  1 brucec serveradmin    0 Apr 28 10:27 write-lock
>
> At this point, brucec can continue to commit, but any other user who
> tries to commit gets the following message:
>
> Transmitting file data .svn: Commit failed (details follow):
> svn: Can't open file '/Raid/svnrep/db/write-lock': Permission denied
> svn: Your commit message was left in a temporary file:
> svn:    '/tmp/issues/svn-commit.tmp'
>
> All committers are in the serveradmin group.
>
> Any ideas on how to solve this?
>
> Thanks!
>
> --Bruce
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
> For additional commands, e-mail: users-help@subversion.tigris.org
>


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org

Re: write-lock not removed with fsfs?

Posted by Max Bowsher <ma...@ukf.net>.
Jani Averbach wrote:
> On 2005-07-05 15:06-0500, Ben Collins-Sussman wrote:
>> Bruce, did you ever figure this problem out?
>>
> In fact I saw this behaviour just two days ago in RHEL4
> with SVN 1.1.1.
>
>>
>> On Apr 28, 2005, at 11:32 AM, Bruce Christensen wrote:
>>
>>> We're running svn client 1.1.4 on Fedora Core 3, accessing a server
>>> running svn 1.1.1 on RH Enterprise Linux AS  release 4 using the
>>> svn+ssh protocol.
>
> This system runs via ra_dav.
>
>>> Whenever one of our users does a commit, svnrep/db/write-lock is
>>> created, which is to expected, However, the lock is never removed when
>>> the commit is finished, which means that no other users can commit
>>> until someone manually removes the write-lock file from the
>>> repository.
>
> Same here.
>
>>> File permissions immediately after user brucec does a commit are as
>>> follows:
>>> [brucec@admin Raid]$ ls -l /Raid/svnrep/db
>>> -rw-r--r--  1 brucec serveradmin    0 Apr 28 10:27 write-lock
>
> Same again.
>
>>> At this point, brucec can continue to commit, but any other user who
>>> tries to commit gets the following message:
>>>
>>> Transmitting file data .svn: Commit failed (details follow):
>>> svn: Can't open file '/Raid/svnrep/db/write-lock': Permission denied
>>> svn: Your commit message was left in a temporary file:
>>> svn:    '/tmp/issues/svn-commit.tmp'
>>>
>
> And again.

This is just the classic permissions problem that we've seen many many times 
before.

chmod g+w /Raid/svnrep/db/write-lock

The presence of the file write-lock does _not_ indicate a claimed write 
lock. It exists all the time.
libsvn_fs_fs takes out an apr_file_lock()-type lock to acquire write access 
to the repository.

Max.



---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org

Re: write-lock not removed with fsfs?

Posted by Jani Averbach <ja...@jaa.iki.fi>.
On 2005-07-05 15:06-0500, Ben Collins-Sussman wrote:
> Bruce, did you ever figure this problem out?
>
In fact I saw this behaviour just two days ago in RHEL4
with SVN 1.1.1.

> 
> On Apr 28, 2005, at 11:32 AM, Bruce Christensen wrote:
> 
> >We're running svn client 1.1.4 on Fedora Core 3, accessing a server
> >running svn 1.1.1 on RH Enterprise Linux AS  release 4 using the
> >svn+ssh protocol.

This system runs via ra_dav.

> >Whenever one of our users does a commit, svnrep/db/write-lock is
> >created, which is to expected, However, the lock is never removed when
> >the commit is finished, which means that no other users can commit
> >until someone manually removes the write-lock file from the
> >repository.

Same here.

> >File permissions immediately after user brucec does a commit are as  
> >follows:
> >[brucec@admin Raid]$ ls -l /Raid/svnrep/db
> >-rw-r--r--  1 brucec serveradmin    0 Apr 28 10:27 write-lock

Same again.

> >At this point, brucec can continue to commit, but any other user who
> >tries to commit gets the following message:
> >
> >Transmitting file data .svn: Commit failed (details follow):
> >svn: Can't open file '/Raid/svnrep/db/write-lock': Permission denied
> >svn: Your commit message was left in a temporary file:
> >svn:    '/tmp/issues/svn-commit.tmp'
> >

And again.

BR, Jani

-- 
Jani Averbach 

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org

Re: write-lock not removed with fsfs?

Posted by Bruce Christensen <br...@gmail.com>.
On 7/5/05, Ben Collins-Sussman <su...@collab.net> wrote:
> Have you followed the 'svn+ssh checklist', in the box at the end of
> chapter 6?
> 
> I can't tell if it's a umask problem or something... does it only
> happen to this one user?

I didn't know that that little section existed. It turns out that it
was a umask problem. Thanks for pointing me in the right direction.

For others who may have the same problem, I've included the wrapper
script that I wrote below.

--Bruce

#!/usr/bin/perl

=head1 NAME

svnwrap

=head1 SYNOPSIS

    su
    mv svnwrap /usr/bin
    cd /usr/bin
    for prog in svnadmin svnlook svnserve; do
      mv $prog $prog-dist
      ln -s svnwrap $prog 
    done

=head1 DESCRIPTION

This script runs a program with umask 002.

Place this script in the same directory as svnserve, svnadmin, and svnlook.
Then symlink svnserve, svnadmin, and svnlook to this script, renaming the
original versions of those programs to svnserve-dist, svnadmin-dist, and
svnlook-dist. This script will set the umask to 002 and then run the -dist
version of whatever script it was called as.

For details on why this might be useful, see the "svn_ssh:// server checklist"
section at the end of chapter six of the Subversion book, available at
http://svnbook.red-bean.com/en/1.1/ch06s05.html as of this writing.

=head1 LICENSE

Copyright (c) 2005 by Bruce Christensen.

This script may be redistributed under the same terms as Subversion itself.

=head1 AUTHOR

Originally written by Bruce Christensen, <me at brucec dot net>.

Last modified 5 July 2005.

=cut

use strict;
use warnings;

use Cwd 'abs_path';
use File::Basename;
use File::Spec;

my $SUFFIX = "-dist";
my $MASK = 002;

umask $MASK;
my $cmd = File::Spec->catfile( dirname(abs_path($0)), basename($0) . $SUFFIX );
exec { $cmd } $cmd, @ARGV;

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org


Re: write-lock not removed with fsfs?

Posted by Ben Collins-Sussman <su...@collab.net>.
[Please keep this on the users@ list]  :-)

On Jul 5, 2005, at 3:33 PM, Bruce Christensen wrote:
>
> To answer your question, we still haven't found any solution to this
> persistent lock problem. I haven't spent too much more time on it.
> I've just created a script that people run before committing that
> deletes the write-lock file (which could be bad if multiple people
> commit at the same time, but it's better than not committing at all).
>
> We'd like to migrate our CVS repository to Subversion, but we can't
> until we find a solution to this problem.
>
> Do you have any ideas on what to do to track down this problem?

Have you followed the 'svn+ssh checklist', in the box at the end of  
chapter 6?

I can't tell if it's a umask problem or something... does it only  
happen to this one user?


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org