Hello.
Reading from /dev/random takes an undefined amount of time. /dev/random
is a source of "true random" numbers in Linux - the timing of some events
like keyboard manipulation is used for producing these numbers and, if
there is nobody doing stuff that is used to feed this random number
generator
it simply blocks until it happens.
Try removing /dev/random (or moving it to something else) and creating
a link
from /dev/urandom to /dev/random. /dev/urandom is a pseudo random number
generator that always returns a number immediately.
* Just as an experiment: try doing your stuff while someone furiously
plays with
the keyboard on the machine in which the process is stopping. You will
see that
the wait will be *very* reduced.
Igor.
BRUGGEMAN Jens (JBRG) wrote:
> Hi,
>
> I seem to have an ennoying problem with subversion.
> I installed subversion version 1.1.1-r3 on a Linux Gentoo box. I
> alsoo made the repositories, configuration went perfect even the usage
> did.
> Quit an amazing system !
>
> On the Gentoo box you have 1 main process being 'svnserve -d -r
> /home/repositories'. This runs as deamon as you can see.
> When an user wants to performa an update, commit or checkout .. This
> main process forks and creates a child process. the child process
> will do its thing and close itself and return to the parent (main).
> But sometimes, I can't really say when (but often) an update, or
> commit takes like for-ever (10-15 minutes) to take place. I already
> upgrade the subversion client TortoiseSVN to the latest version to be
> sure it is not client-side problem. I alsoo upgraded the svn server
> to the latest build being 1.1.3 to be sure this isn't a problem which
> is already solved.
> I have used the command 'strace' on the process so see what is
> happening with the child process and why it takes such a long time.
> Some users did an update on their working copy and aborted the action
> because it took too long. This process is 'idling' now already for
> about 1 day. Doing nothing. I can kill the process for sure, but isn't
> there a time-out on the child processes?
>
> I can paste some logging of a process which has stopped doing anything:
>
> 11:21:59 fork(Process 9952 attached
> ) = 9952
> [pid 9952] 11:21:59 getpid() = 9952
> [pid 9952] 11:21:59 getrlimit(RLIMIT_STACK, {rlim_cur=RLIM_INFINITY,
> rlim_max=RLIM_INFINITY}) = 0
> [pid 9952] 11:21:59 close(3) = 0
> [pid 9952] 11:21:59 write(4, "( success ( 1 2 ( ANONYMOUS ) ( "...,
> 52) = 52
> [pid 9952] 11:21:59 read(4, "( 2 ( edit-pipeline ) 31:svn://1"...,
> 4096) = 59
> ....
> [pid 9952] 11:21:59 open("/dev/random", O_RDONLY) = 5
> [pid 9952] 11:21:59 read(5, "\25\320XW\362~", 8) = 6
> *[pid 9952] 11:21:59 read(5, <unfinished ...>
> [pid 9952] 11:30:06 <... read resumed> ")}", 2) = 2*
>
>
> Between those 2 actions: 9 minutes before resuming. Why did it even
> stop? I got lots of such message, unfinished .. after some time
> resumed action.
>
> After that line:
> [pid 9953] 11:30:06 <... read resumed> "\230\10\226\257t\266U\3", 8) = 8
> [pid 9952] 11:30:06 close(5 <unfinished ...>
> [pid 9953] 11:30:06 close(5 <unfinished ...>
> [pid 9952] 11:30:06 <... close resumed> ) = 0
> [pid 9953] 11:30:06 <... close resumed> ) = 0
> .... (Lots of actions)
> [pid 9952] 11:30:08 unlink("/tmp/report.tmp") = 0
> [pid 9952] 11:30:08 write(4, "( success ( ) ) ", 16) = 16
> [pid 9952] 11:30:08 read(4, <unfinished ...>
>
> 11:30:08 was the latest action the process has done. Doing a read
> which was unfinished and never resumed.
> I still have the process doing 'ps -ef | grep svn'
> root 9952 3630 0 11:21 ? 00:00:00 svnserve -d -r
> /home/svnroot/
> So the process started at 11:21 .. Took about 9 minutes and did not
> even complete.
>
> What could be wrong? Anyone any ideas? I would love to get this
> problem solved to get an optimal working situation.
>
> Greetings,
> Jens
Received on Fri Feb 11 22:00:40 2005