Branko Cibej to Anton Shepelev: > the expected behaviour is that /dev/random may block > but /dev/urandom won't. That's the whole reason why > /dev/urandom was introduced.
What, not for Unicode :-? Seriously, I read that on FreeBSD /urandom was just a link to /random. Now I confirm it is not, or no longer, true. > > -> and not, for example, on DNS resolution? > > In case specifically of DNS resolution, svn does not > hang forever. Futhermore, `svn up' and `svn ls' do > not freeze on the affected system, from working > directories connected to the same repo which it hangs > with during co. My latest test shows that `svn co' > get all the files excep the last one (alphabetically). > and only then hangs: > > <https://paste.c-net.org/RadioBanging> > > Now that's ... "interesting". Previously you wrote, > > > If I do `svn cleanup', then `svn up' hangs forever > > as well. Indeed. I was making a lot of cleanup, up, co, info, and ls invocations, and didn't expect a different sequence could lead to a different result. > So this seems not to be the case. Can you try > something like this: > > ac8 ant> svn cosvn://<hidden> & > > > and then, while the svn job is blocked in the > background: > > ac8 ant> lsof | grep '/dev/u*random' For some reason, $ svn co svn<hidden> ad1 & writes to stdout and blocks, so I tried the `lsof' invocation in another GNU screen window, while `svn co' was hung up, and it printed nothing. If that means it is not blocking on reading random data, then it is blocking on something else. IMHO, it would be more polite of svn to fail and explain which operation timed out. What else can I do -- learn and apply dtrace? P.S.: Beg pardon for delayed replies. I access the affected system remotely, via a reverse SSH tunnel established by autossh, at the relatively rare times the machine is online.
