On Mon, Apr 08, 2019 at 05:05:47PM +0200, Vincent Lefevre wrote: > On 2019-04-08 16:38:37 +0200, Stefan Sperling wrote: > > Since you have a way to reproduce the problem, even if unreliably, > > you're in a position to help. > > But it could take weeks...
Perhaps you can find a way to trigger it on purpose? > > If you don't try, we'll have to wait until someone else figures out where > > the hang occurs or provides a clear and working reproduction recipe. > > > > Sorry, but bugs don't get fixed by magic ;) > > Well, I forgot, there's at least an issue with svnserve. I got that > in the past, and could reproduce it: once I kill the svn client > with Ctrl-C and kill the SSH master too, the sshd terminates, but > svnserve is still running, and now has 1 as its PPID: > > UID PID PPID C STIME TTY TIME CMD > vlefevre 48724 1 0 12:40 ? 00:00:00 svnserve -t Hmm... that looks like the svnserve process was in zombie state and is not being terminated. It is the init system's job to call waitpid() for such processes. I cannot tell how this is supposed to work in your server environment. > If svnserve was waiting for something from sshd, it should at least > have noticed that the connection is no longer there. There is no connection as far as svnserve is concered. In tunnel mode, svnserve reads from stdin and write to stdout, and it is done when these get closed or the process is terminated for some reason. I suspect the problem is caused either in SSH or somewhere else on your server. > lsof still shows: > > svnserve 48724 vlefevre cwd DIR 0,32 4096 > 110673531 /home/users/vlefevre (...:/forge_home) > svnserve 48724 vlefevre rtd DIR 254,0 4096 > 2 / > svnserve 48724 vlefevre txt REG 254,0 86256 > 9413 /usr/bin/svnserve > svnserve 48724 vlefevre 0r FIFO 0,8 0t0 > 957950313 pipe > svnserve 48724 vlefevre 1w FIFO 0,8 0t0 > 957950314 pipe > svnserve 48724 vlefevre 2w FIFO 0,8 0t0 > 957950315 pipe > svnserve 48724 vlefevre 3r CHR 1,9 0t0 > 7109 /dev/urandom > > BTW, is the permanent open of /dev/urandom normal? Those should all be open file handles that will get closed when the process exists. Subversion relies on APR pool cleanup handlers to close files in many cases, and perhaps those handlers haven't been run yet.
