savannah-hackers-public
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Karl Berry
Subject: Re: [Savannah-hackers-public] git accumulations on vcs
Date: Sat, 2 Mar 2013 22:59:54 GMT

Hi Paul,

    Do you know what they're doing?  

I was hoping someone who actually has some experience with git admin
would be spurred to look.  Anyway.
    
    Presumably they're all waiting on something since if they were all
    active the server would be on its knees.  Can you tell what they're
    waiting on

Nope.  I would speculate that it's the net, because what else would it
be ...  Like the other end hung up and it's not noticing?  Don't know an
easy way to tell if that is the case, I'm afraid.

    (does strace -p <pid> show anything interesting)?  
    
vcs(26)#$ strace -p 9935
Process 9935 attached - interrupt to quit
read(0,  <unfinished ...>
Process 9935 detached

    How they were invoked/command line args, etc.?

They are all invoked in the standard way on savannah, from inetd, and
have exactly the same cmdline args and the like.  There are four
processes for each hung git.  Here is the latest one:

USER       PID  PPID %CPU %MEM   RSS    VSZ STAT  NI  STARTED COMMAND
nobody   31726 32714  0.0  0.0   436   1708 Ss     0   Feb 28 timeout 120m 
/usr/lib/git-core/git-daemon --inetd --export-all --base-path=/srv/git /srv/git
nobody   31727 31726  0.0  0.0   888   2532 S      0   Feb 28 
/usr/lib/git-core/git-daemon --inetd --export-all --base-path=/srv/git /srv/git
nobody   31728 31727  0.0  0.0   624   3136 S      0   Feb 28 git upload-pack 
--strict --timeout=0 .
nobody   31729 31728  0.0  0.0   816   5944 S      0   Feb 28 git-upload-pack 
--strict --timeout=0 .

Doing ls -l /proc/*/cwd | fgrep .git shows a variety of repositories --
gnulib, emacs, freetype, ranger, qemu, gluster, etc., to name a few.
Clearly it's not a repository-specific thing, nor user-specific.

Jim, are you there?  What troubles me most is that the timeout 120m is
not effective.  (I suggested that precisely to avoid this accumulation
of uselessly stale processes.)  The timeout is from coreutils 8.5, maybe
that is old enough that it doesn't kill something hung in read()?  I
guess I could compile the latest, but it all takes time ...

Anyway, I'll kill them tomorrow unless something comes up.  I'm sure
there will be more coming along in due course.

    We have a Git server here and I never see that kind of thing.  But of
    course the usage model is very different.

Savannah regularly has these kinds of problems, with all vc's, repo
web browsers, you name it :(.  This is just the current incarnation.

Thanks,
k



reply via email to

[Prev in Thread] Current Thread [Next in Thread]