Re: [Savannah-hackers-public] git accumulations on vcs

[Karl Berry]

Hi James,

    Is 9935's parent inetd process still running; 

Yes (the parent is 9934).

USER       PID  PPID %CPU %MEM   RSS    VSZ STAT  NI  STARTED COMMAND
nobody    9934  9932  0.0  0.0   284   3136 S      0   Jan 13 git upload-pack 
--strict --timeout=0 .
nobody    9935  9934  0.0  0.0   400   5360 S      0   Jan 13 git-upload-pack 
--strict --timeout=0 .

The further ancestors 9932 (the git-daemon invoked from inetd) and 9931
(the timeout) are still running too.  Like I said, four processes per
hung git.

    what does lsof(8) say about said parent process?  

COMMAND  PID   USER   FD   TYPE    DEVICE    SIZE      NODE NAME
git     9934 nobody  cwd    DIR     202,2    4096   2498832 /srv/git/gperf.git
git     9934 nobody  rtd    DIR     202,2    4096         2 /
git     9934 nobody  txt    REG     202,2 1019720   5271957 /usr/bin/git
git     9934 nobody  mem    REG       0,0                 0 [heap] (stat: No 
such file or directory)
git     9934 nobody  mem    REG     202,2 1323460   6037981 
/lib/i686/cmov/libc-2.11.2.so
git     9934 nobody  mem    REG     202,2  117367   6037970 
/lib/i686/cmov/libpthread-2.11.2.so
git     9934 nobody  mem    REG     202,2   79980   5267575 
/usr/lib/libz.so.1.2.3.4
git     9934 nobody  mem    REG     202,2  113964   6037959 /lib/ld-2.11.2.so
git     9934 nobody    0u  IPv4 478441215               TCP 
vcs.savannah.gnu.org:git->188.233.26.218.internet.sx.cn:5388 (ESTABLISHED)
git     9934 nobody    1u  IPv4 478441215               TCP 
vcs.savannah.gnu.org:git->188.233.26.218.internet.sx.cn:5388 (ESTABLISHED)
git     9934 nobody    2w  FIFO       0,8         478441230 pipe

    Ie, are the tcp socket(s) still ESTABLISHED?

Evidently yes.

    If not, the bug likely is in inetd.

Which I'm not about to delve into :).  Or update the Debian version,
which these machines need and which might fix it ...

It seems to me there still has to be a bug in this version of timeout as
well, since regardless of what else might be happening, it's been more
than 120 wall-clock minutes and thus timeout should have killed it.

It also doesn't seem sensible to me for git to sit around for,
literally, months waiting for input, but whatever.

We seem to have reached the end of the road, so I'm killing these old
things now (I'll leave one around in case there are any other ideas).
If/when they start to accumulate again, as I'm sure they will, I'll
compile the latest timeout.  That's the one thing I know how to do :).

Thanks,
karl