On 24. 12. 25 16:05, Anton Shepelev wrote:
Branko Cibej to Anton Shepelev:
[...]
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.
It is something else. It can't be blocking on /dev/urandom if it hasn't
opened /dev/urandom.
IMHO, it would be more
polite of svn to fail and explain which operation timed out.
Clearly nothing has timed out, that's why the process is blocked.
What else can I do -- learn and apply dtrace?
I think dtrace/strace would be the next thing to try yes.
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.
That's really not a problem. We all accept that e-mail is asynchronous.
Nay, we revel in it! :D
-- Brane
