Oooh. That's a very cool utility. I didn't know about that one.
It looks to me like /dev/random is blocking quite nastily. (And this time,
it only took about 30 seconds . . . go figure.) svn.strace, around the
important area:
17:41:07 connect(3, {sa_family=AF_INET, sin_port=htons(3690),
sin_addr=inet_addr("127.0.0.1")}, 16) = 0
(large amount of uninteresting stuff)
17:41:07 write(3, "( CRAM-MD5 ( ) ) ", 17) = 17
17:41:07 read(3, "( step ( 52:<5717741632206738798"..., 4096) = 69
17:41:43 write(3, "38:zorba 7db8a2c4e537e888c7a3d49"..., 42) = 42
17:41:43 read(3, "( success ( ) ) ( success ( 36:0"..., 4096) = 94
It's waiting for svnserve to reply, as near as I can tell, and
svnserve.strace:
1097 17:41:07 munmap(0x40099000, 4096) = 0
1097 17:41:07 write(4, "( success ( ( CRAM-MD5 ) 2:mv ) "..., 34) = 34
1097 17:41:07 read(4, "( CRAM-MD5 ( ) ) ", 4096) = 17
1097 17:41:07 open("/dev/random", O_RDONLY) = 14
1097 17:41:07 read(14, "n\25%y\270", 8) = 5
1097 17:41:07 read(14, "\177", 3) = 1
1097 17:41:07 read(14, "YO", 2) = 2
1097 17:41:43 close(14) = 0
1097 17:41:43 uname({sys="Linux", node="(censored)", ...}) = 0
1097 17:41:43 gettimeofday({1078508503, 171557}, NULL) = 0
1097 17:41:43 write(4, "( step ( 52:<5717741632206738798"..., 69) = 69
So, yeah. Blocking on /dev/random. I'm guessing the entropy pool is empty -
reading through the /dev/random docs, it seems like it tries to accumulate
entropy from system hardware. Unfortunately this is a VPS, and so there
isn't really any physical hardware with entropy available to it -
everything's virtual through VPS drivers. I have no idea if that would make
any difference, but . . . there's the problem, at least.
Anybody have a clue how to fix this? Should I just, like, cat the kernel
source into /dev/random and hope that fixes it? ;) Or is there a better way?
Thanks,
-Ben
----- Original Message -----
From: "Tobias Ringstrom" <tobias@ringstrom.mine.nu>
To: "Ben Wilhelm" <zorbathut@uswest.net>
Cc: <users@subversion.tigris.org>
Sent: Thursday, March 04, 2004 4:29 PM
Subject: Re: password-db failure?
> Ben Wilhelm wrote:
> > make install
> > mkdir /usr/local/svn
> > svnadmin create /usr/local/svn/mv
> > ( edit /usr/local/svn/users to contain [users] \n username = password
\n)
> > ( edit /usr/local/svn/mv/conf/svnserve.conf to contain [general] \n
> > password-db = ../../users \n)
> > svnserve -d -r /usr/local/svn
> > cd ~
> > mkdir mv
> > touch mv/foo.bar
> > svn import mv svn://localhost/mv
>
> That's a nice reproduction recepie, thanks!
>
> > . . . and grr. Now it seems to be working - sort of - it's back to the
> > five-minute delay-before-doing-anything. At least, it takes five minutes
to
> > authenticate my password, during which it uses 0% CPU.
>
> What??? Five minutes? Something is very weird indeed. If you're on
> Linux, you can run svnserve under strace like this:
>
> strace -t -f -o svnserve.strace svnserve -d -r /usr/local/svn
>
> and checkout like this:
>
> strace -t -o svn.strace svn import mv svn://localhost/mv
>
> If you study svnserve.strace and svn.strace after it's done, you
> should be able to figure out why it's waiting for five minutes.
> Another way is to use a debugger. Add --enable-maintainer-mode to
> configure to compile with debug info.
>
> /Tobias
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Fri Mar 5 18:51:31 2004