Branko Cibej to Anton Shepelev: > > On FreeBSD 14.3, svn 1.14.2 > > Out of interest, where did you get this version? I have a VM > with FreeBSD 14.2 and the Subversion in ports is version > 1.14.5.
Probably an unfinished upgrade from 14.1. After `pkg upgrade -f' (which fixed some other errors), my Subversion is 1.14.5 (r1922182). The issue persists. > > I have made sure that both /dev/random and /dev/urandom do > > not block, by reading a single byte from them: > > > > od -vAn -N2 -tu2 < /dev/random > > od -vAn -N2 -tu2 < /dev/urandom > > > Reading one byte won't tell you much. You just tested that the > entropy pool isn't empty. Try reading 100 or 1000 bytes, > that's a more realistic test. It works, too. > Subversion itself uses randomness -- via APR's > apr_generate_random_bytes(), which uses /dev/urandom on > FreeBSD -- to encrypt passwords on disk. This is an optional > feature and doesn't seem to be enabled in the port. And > anyway, /dev/urandom is guaranteed not to block, see > https://s.apache.org/7v30k . I thought urandom was symlinked from random, but checking currnt FreeBSD docs shows it is not (or no longer) so. OK. > Given all of the above, what evidence do you have that your > checkout is blocking on /dev/[u]random -> It is the only reason I have seen mentioned in connexion with an infinte blocking of svn. > -> 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>
