You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Roman Neuhauser <de...@bellavista.cz> on 2003/08/19 12:06:04 UTC

FreeBSD: 0.26 extremely unstable

I don't know what to think about this: we're in rev 18, and the number
of times I had to run svnadmin recover is about the same. I'm not sure
if this is a Subversion or FreeBSD issue, so I'm cc'ing the port
maintainer.

client:

roman@freepuppy ~/work/trunk 1043:1 > svn up
roman@ishtar.bellavista.cz's password: 
At revision 18.
roman@freepuppy ~/work/trunk 1043:0 > svn up
roman@ishtar.bellavista.cz's password: 
svn: Couldn't find a repository
svn: No repository found in 'svn+ssh://ishtar.bellavista.cz/home/svn/repos/trunk'
roman@freepuppy ~/work/trunk 1043:1 >  uname -a
FreeBSD freepuppy.bellavista.cz 4.8-STABLE FreeBSD 4.8-STABLE #2: Thu Jun  5 12:57:47 CEST 2003     root@freepuppy.bellavista.cz:/usr/obj/usr/src/sys/FREEPUPPY2_5  i386
roman@freepuppy ~/work/trunk 1044:0 > svn --version
svn, version 0.26.0 (r6550)
   compiled Aug 14 2003, 15:05:41
...

server:

roman@ishtar home/svn/repos 1027:0 > uname -a
FreeBSD ishtar.bellavista.cz 4.8-STABLE FreeBSD 4.8-STABLE #0: Wed Jun  4 15:45:44 CEST 2003     root@freepuppy.bellavista.cz:/usr/obj/usr/src/sys/ISHTAR_4  i386
roman@ishtar home/svn/repos 1028:0 > svn --version
svn, version 0.26.0 (r6550)
   compiled Aug 14 2003, 14:53:12
...

Note that I am the only person accessing the repo ATM.

-- 
The From: header's been munged to get rid of unwanted cc's.
My real address: neuhauser@bellavista.cz.

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

Re: FreeBSD: 0.26 extremely unstable

Posted by Roman Neuhauser <de...@bellavista.cz>.
# dev-null@bellavista.cz / 2003-08-19 14:06:04 +0200:
> I don't know what to think about this: we're in rev 18, and the number
> of times I had to run svnadmin recover is about the same.

    subversion is linked against bdb 4.0.14 (db4-4.0.14_1,1) on both
    the client and the server.

-- 
The From: header's been munged to get rid of unwanted cc's.
My real address: neuhauser@bellavista.cz.

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

Re: FreeBSD: 0.26 extremely unstable - backtrace

Posted by Roman Neuhauser <de...@bellavista.cz>.
# dev-null@bellavista.cz / 2003-08-19 14:06:04 +0200:
> I don't know what to think about this: we're in rev 18, and the number
> of times I had to run svnadmin recover is about the same.

    I have found that svnserve is dumping core:

    Aug 19 14:40:57 ishtar /kernel: pid 4112 (svnserve), uid 1000: exited on signal 6 (core dumped)

    I have rebuilt the port with --enable-debug added to the configure
    options, and this is what I get from gdb:

#0  0x282f10f0 in kill () from /usr/lib/libc.so.4
No symbol table info available.
#1  0x28332cb9 in abort () from /usr/lib/libc.so.4
No symbol table info available.
#2  0x2808e8f0 in default_warning_func (baton=0x0, err=0x805d050) at subversion/libsvn_fs/fs.c:109
No locals.
#3  0x2808ec76 in cleanup_fs_apr (data=0x8061050) at subversion/libsvn_fs/fs.c:275
        fs = (svn_fs_t *) 0x8061050
        err = (svn_error_t *) 0x805d050
#4  0x2827f5a7 in run_cleanups (cref=0x8061028) at apr_pools.c:1979
        cref = (cleanup_t **) 0x8061028
        c = (cleanup_t *) 0x100f
#5  0x2827eae5 in apr_pool_destroy (pool=0x8061018) at apr_pools.c:755
        active = (apr_memnode_t *) 0x100f
        allocator = (apr_allocator_t *) 0x8052080
#6  0x2827eaca in apr_pool_destroy (pool=0x8058018) at apr_pools.c:752
        active = (apr_memnode_t *) 0x100f
        allocator = (apr_allocator_t *) 0x8052000
#7  0x2827eaca in apr_pool_destroy (pool=0x8053018) at apr_pools.c:752
        active = (apr_memnode_t *) 0x100f
        allocator = (apr_allocator_t *) 0x283400a0
#8  0x2827e679 in apr_pool_terminate () at apr_pools.c:585
No locals.
#9  0x2827c248 in apr_terminate () at start.c:117
No locals.
#10 0x28333508 in exit () from /usr/lib/libc.so.4
No symbol table info available.
#11 0x804a517 in main (argc=2, argv=0xbfbffb50) at subversion/svnserve/main.c:208
        listen_once = 0
        daemon_mode = 0
        tunnel_mode = 1
        read_only = 0
        sock = (apr_socket_t *) 0x282ce91e
        usock = (apr_socket_t *) 0xbfbffb50
        in_file = (apr_file_t *) 0x80580a0
        out_file = (apr_file_t *) 0x80580e0
        sa = (apr_sockaddr_t *) 0x2
        pool = (apr_pool_t *) 0x8058018
        connection_pool = (apr_pool_t *) 0xbfbffaf4
        err = (svn_error_t *) 0x2805ef63
        os = (apr_getopt_t *) 0x8058050
        opt = 116 't'
        errbuf = "Dúżż\001\000\000\000Húżżr+\005(¨,\006(\000`\006(\000a\006(\000b\006(\000c\006(\000d\006(\000e\006(\000f\006(\000g\006(\000h\006(\000i\006(\000j\006(\000k\006(\000l\006(\000m\006(ÚG\005(*=\005(¨,\006(|\212\004\b,ř\004\b\000a\006(\ba\006(ěúżżI\e\005(\000m\006(\210\a,(ŮŽ\a\001\000m\006(Üůżż\016\000\000\000\016\000\000\000´úżż.\"\005(F\222\004\b\004Ď\212\006\000`\006(°úżż\001\000\000\000|\212\004\b´úżż\013\"\005(F\222\004\b\000\000\000\000l)\005(˘!\005(¨,\006("...
        arg = 0x0
        root = 0x804dfe3 "/"
        status = 70014
        conn = (svn_ra_svn_conn_t *) 0x805a018
        proc = {pid = 671493288, in = 0x28066d00, out = 0x1bffaec, err = 0xbfbffa54}
        handling_mode = connection_mode_fork


-- 
The From: header's been munged to get rid of unwanted cc's.
My real address: neuhauser@bellavista.cz.

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

Re: FreeBSD: 0.26 extremely unstable - SOLVED

Posted by Jack Repenning <jr...@collab.net>.
At 9:37 PM -0400 8/20/03, pll@lanminds.com wrote:
>Unless your point is that in the long run the performance gain
>svn+ssh gives you will put significantly further ahead.  In which
>case, it's probably worth it :)

I don't think we think the speed difference is a permanent thing, 
only a current performance bug somewhere.
-- 
-==-
Jack Repenning
CollabNet, Inc.
8000 Marina Boulevard, Suite 600
Brisbane, California 94005
o: 650.228.2562
c: 408.835-8090

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

Re: FreeBSD: 0.26 extremely unstable - SOLVED

Posted by Ben Collins-Sussman <su...@collab.net>.
pll@lanminds.com writes:

> Unless your point is that in the long run the performance gain 
> svn+ssh gives you will put significantly further ahead.  In which 
> case, it's probably worth it :)

The book compares the pros and cons.  For most people, the main
decision comes down to:  what kind of accounts do you want?  If your
users already have ssh accounts, then svn+ssh:// fits nicely into your
existing security infrastructure.  On the other hand, many admins
*hate* the fact that CVS commits require system accounts, and are very
happy that apache uses its own users-file.


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

Re: FreeBSD: 0.26 extremely unstable - SOLVED

Posted by pl...@lanminds.com.
In a message dated: Wed, 20 Aug 2003 21:22:52 EDT
Garrett Rooney said:

>pll@lanminds.com wrote:
>> 
>> This would seem to imply why it is a good idea to use the http: 
>> method, no?
>
>perhaps, but svn+ssh:// is faster, uses existing ssh infrastructure, and 
>is a lot easier to set up, so as with all things you have to consider 
>the various options and decide which one gives you something you can 
>live with.

Hmm. I s'pose, though if you end up having to hack a wrapper script 
to get that to work, then have to fight with getting groups and 
permissions working properly (after you've diagnosed that problem), 
it seems that just setting up http: is less effort.

Unless your point is that in the long run the performance gain 
svn+ssh gives you will put significantly further ahead.  In which 
case, it's probably worth it :)
-- 

Seeya,
Paul
--
Key fingerprint = 1660 FECC 5D21 D286 F853  E808 BB07 9239 53F1 28EE

	It may look like I'm just sitting here doing nothing,
   but I'm really actively waiting for all my problems to go away.

	 If you're not having fun, you're not doing it right!



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

Re: FreeBSD: 0.26 extremely unstable - SOLVED

Posted by Garrett Rooney <ro...@electricjellyfish.net>.
pll@lanminds.com wrote:

> In a message dated: 20 Aug 2003 08:23:37 CDT
> Ben Collins-Sussman said:
> 
> 
>>A bunch of people using svn+ssh:// is *exactly* the same as these
>>people all logging in to the machine and reading/writing the
>>berkeley-db files directly.  There is no "gateway server" like pserver
>>or apache.  Thus someone with a weird umask can break access for
>>everyone else.
> 
> 
> This would seem to imply why it is a good idea to use the http: 
> method, no?

perhaps, but svn+ssh:// is faster, uses existing ssh infrastructure, and 
is a lot easier to set up, so as with all things you have to consider 
the various options and decide which one gives you something you can 
live with.

-garrett


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

Re: FreeBSD: 0.26 extremely unstable - SOLVED

Posted by pl...@lanminds.com.
In a message dated: 20 Aug 2003 08:23:37 CDT
Ben Collins-Sussman said:

>A bunch of people using svn+ssh:// is *exactly* the same as these
>people all logging in to the machine and reading/writing the
>berkeley-db files directly.  There is no "gateway server" like pserver
>or apache.  Thus someone with a weird umask can break access for
>everyone else.

This would seem to imply why it is a good idea to use the http: 
method, no?
-- 

Seeya,
Paul
--
Key fingerprint = 1660 FECC 5D21 D286 F853  E808 BB07 9239 53F1 28EE

	It may look like I'm just sitting here doing nothing,
   but I'm really actively waiting for all my problems to go away.

	 If you're not having fun, you're not doing it right!



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

Re: FreeBSD: 0.26 extremely unstable - SOLVED

Posted by Ben Collins-Sussman <su...@collab.net>.
Roman Neuhauser <de...@bellavista.cz> writes:

>     my answer: I have never encountered messed up RCS file permissions
>     in any CVS repository I've been using, be the access method pserver
>     or ext/ssh. granted, I'm not a CVS old hand: just three years or so.

Because pserver is *one* process accessing the RCS files.  I'm talking
about scenarios where people set CVSROOT to just plain old path on
local disk.  This is how CVS used to work before it had a network layer.

>     unless, of course, you are talking about messing with the RCS files
>     directly, but that doesn't qualify: we're not messing with the SVN
>     repository database either. just svn+ssh://

A bunch of people using svn+ssh:// is *exactly* the same as these
people all logging in to the machine and reading/writing the
berkeley-db files directly.  There is no "gateway server" like pserver
or apache.  Thus someone with a weird umask can break access for
everyone else.


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

Re: FreeBSD: 0.26 extremely unstable - SOLVED

Posted by Roman Neuhauser <de...@bellavista.cz>.
# sussman@collab.net / 2003-08-19 11:00:30 -0500:
> Roman Neuhauser <de...@bellavista.cz> writes:
> 
> > # dev-null@bellavista.cz / 2003-08-19 14:06:04 +0200:
> > > I don't know what to think about this: we're in rev 18, and the number
> > > of times I had to run svnadmin recover is about the same. I'm not sure
> > > if this is a Subversion or FreeBSD issue, so I'm cc'ing the port
> > > maintainer.
> > 
> >     the problem turned out to be wrong umask: subversion/bdb creates
> >     log files ($REPOS/db/log.*) with 644. This makes a pretty poor
> >     comparison to CVS: Subversion can't cater for three users without
> >     hacking. (The handwaving in the handbook notwithstanding.)
> 
> You're kidding, right?
> 
> Ask Karl about how often this happens in CVS repositories.  Answer:
> ALL the time.

    my answer: I have never encountered messed up RCS file permissions
    in any CVS repository I've been using, be the access method pserver
    or ext/ssh. granted, I'm not a CVS old hand: just three years or so.

> When three cvs users all start modifying repository RCS
> files, the most *common* problems is messed up permissions and/or
> umasks.

    so umask 022 is messed up?

    unless, of course, you are talking about messing with the RCS files
    directly, but that doesn't qualify: we're not messing with the SVN
    repository database either. just svn+ssh://

    This is what the svnbook says:

    "The most common problem administrators run into is repository
    ownership and permissions. Does every process (or user) in the
    previous list have the rights to read and write the Berkeley DB
    files? Assuming you have a Unix-like operating system, a
    straightforward approach might be to place every potential
    repository user into a new svn group, and make the repository wholly
    owned by that group. But even that's not enough, because a process
                                                             ^^^^^^^^^
    may write to the database files using an unfriendly umask--one which
    ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
    prevents access by other users."
    ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

    The surrounding text makes it seem like it's talking about
    mixed-access repositories, ones that are accessed with file://,
    svn+ssh://, and through webdav, but in fact, it's not.

-- 
The From: header's been munged to get rid of unwanted cc's.
My real address: neuhauser@bellavista.cz.

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

Re: FreeBSD: 0.26 extremely unstable - SOLVED

Posted by Greg Hudson <gh...@MIT.EDU>.
On Tue, 2003-08-19 at 12:00, Ben Collins-Sussman wrote:
> Ask Karl about how often this happens in CVS repositories.  Answer:
> ALL the time.  When three cvs users all start modifying repository RCS
> files, the most *common* problems is messed up permissions and/or
> umasks.

CVS bashes your umask to 002 by default, trading off security against
convenience.  We don't do that, so (at the moment) we're really
inconvenient.  And I don't think we ought to start doing that, both
because it's a security hole and because it's especially impolite to
bash global process state in a library.

I think the right answer is for libsvn_fs to set the permissions of
newly created logfiles to match the permissions of the repository
itself, as defined by some reference file or the db directory or
whatever.  This solution is difficult because it requires getting
Sleepycat to add support to Berkeley DB for doing that.

(You can still have a problem in CVS.  On a machine with System V group
ownership semantics, with users who have different primary groups, you
have to make sure the repository is g+s or else new files won't be
writable by other users.  But if you have BSD group ownership semantics,
or you have users all in the same primary group, or you have a g+s
repository root, you won't have an issue.)


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

Re: FreeBSD: 0.26 extremely unstable - SOLVED

Posted by Ben Collins-Sussman <su...@collab.net>.
Roman Neuhauser <de...@bellavista.cz> writes:

> # dev-null@bellavista.cz / 2003-08-19 14:06:04 +0200:
> > I don't know what to think about this: we're in rev 18, and the number
> > of times I had to run svnadmin recover is about the same. I'm not sure
> > if this is a Subversion or FreeBSD issue, so I'm cc'ing the port
> > maintainer.
> 
>     the problem turned out to be wrong umask: subversion/bdb creates
>     log files ($REPOS/db/log.*) with 644. This makes a pretty poor
>     comparison to CVS: Subversion can't cater for three users without
>     hacking. (The handwaving in the handbook notwithstanding.)

You're kidding, right?

Ask Karl about how often this happens in CVS repositories.  Answer:
ALL the time.  When three cvs users all start modifying repository RCS
files, the most *common* problems is messed up permissions and/or
umasks.


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

Re: FreeBSD: 0.26 extremely unstable - SOLVED

Posted by kf...@collab.net.
Roman Neuhauser <de...@bellavista.cz> writes:
>     the problem turned out to be wrong umask: subversion/bdb creates
>     log files ($REPOS/db/log.*) with 644. This makes a pretty poor
>     comparison to CVS: Subversion can't cater for three users without
>     hacking. (The handwaving in the handbook notwithstanding.)

Hmmm.  I thought:

   1. The Subversion server must run with uid/gid and permissions that
      have write access to the repository it's going to serve.  This
      is true even for read-only operations.

   2. A CVS server must run with uid/gid and permissions that have
      write access to the repository it's going to serve.  This is
      true even for read-only operations.

Are Subversion's actual requirements stricter than this?


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

Re: FreeBSD: 0.26 extremely unstable - SOLVED

Posted by Roman Neuhauser <de...@bellavista.cz>.
# dev-null@bellavista.cz / 2003-08-19 14:06:04 +0200:
> I don't know what to think about this: we're in rev 18, and the number
> of times I had to run svnadmin recover is about the same. I'm not sure
> if this is a Subversion or FreeBSD issue, so I'm cc'ing the port
> maintainer.

    the problem turned out to be wrong umask: subversion/bdb creates
    log files ($REPOS/db/log.*) with 644. This makes a pretty poor
    comparison to CVS: Subversion can't cater for three users without
    hacking. (The handwaving in the handbook notwithstanding.)

-- 
The From: header's been munged to get rid of unwanted cc's.
My real address: neuhauser@bellavista.cz.

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