detached process are not killed and consume bandwidth

[pkernevez]

I had processes that consume bandwidth, after investigation they are create by githudd detached processes:
-+= 00001 root /sbin/launchd
|-+- 71284 pke githudd /Users/pke/myrepo
| -+- 97514 pke git fetch
| --- 97515 pke /usr/bin/ssh git@github.com git-upload-pack '/myrepo.git'

$ ps -edf | grep hud | wc -l
85

Some of those process were started one month ago.

After killing all the pending githudd, my bandwidth radically decreased:

[gbataille]

@pkernevez

As briefly discussed, by design, there ought to be a single gtihudd daemon process. Which is supposed to poll (git fetch) only the latest visited GIT repo

I have seen that your issue exists on my laptop too. I'll try to investigate.

In the meantime if you feel the auto-fetch feature is more costly (because of this bug) than it's worth, you can add this line to your ~/.githudrc

run_fetcher_daemon=False

--> nevermind, just tested. Does not work :/ One more bug #28

[pkernevez]

May be related to this message :

[gbataille]

Yes it's likely due to the "self healing".

When githud runs (everytime you render your prompt), it tries to communicate with the githudd daemon. If it does not finds it, or finds it unresponsive, it should kill what might be there, and then pop a new daemon.

So it must be something like:

• the communication socket goes bad
• the communication can't happen
• the process fails to be killed (don't know why)
• a new one is spawned

2 things you might do:

• there is a setting in the config file that controls how often the background process does a git fetch. you can kind of disable it by putting a large value there. githudd_sleep_seconds=xxx
• There is a log file setting: githudd_log_file_path=/dev/null. it's disabled by default because it has limited use, and it's very verbose so it quickly adds up. If you are able to "easily" reproduce the issue, I would be interested to get logs. I can't easily reproduce it on my side. I'll dig in the code anyway to try and make sense of it

[gbataille]

Hum, so one possibility (I think it's rather a low likelihood) is a recent change to fix #21 . I use to hardcode the path in which to store the pid and the socket. The thing is that the "default" I had chosen did not necessarily exist for everyone. That meant on first usage, they got an error (semi-obscure) and fixing it would require them to modify their config file.

So I introduced a change to ask the OS what the temp folder was.

There is a small possibility that the OS does not always respond the same thing (I don't know what's his criteria). I say it's a small possibilty though because as I write this, I have 2 githudd process running but I can find only 1 socket and 1 pid file in my /var/folders/...

Maybe you can check that on your side too?

[gbataille]

Another question: do you processes have a similar start date/time?

In my current case, they do. which makes me wonder if it's not some concurrency on process start. But with the number of process you mentioned originally I find that unlikely

[gbataille]

and one final thing, because I don't see anything obvious in the code, could you export this variables in all your shell
GITHUD_DEBUG=TRUE

It should give more info on stderr when an error occurs

[gbataille]

Discussions and tests with @pkernevez led to the culprit. Seems to be a concurrency issue where githud runs several times at once. All the githud instance check for the githudd daemon which might not be able to respond to all, and therefore several processes try to restart the daemon. Since restarting is not thread-safe, several daemons are started. And since I maintain a single PID file pointing to a (supposed) single githudd instance, those multiple githudd processes are zombie as far as I'm concerned. I don't know they exist, so I never clean them up.

Having githud launch several time concurrently means however that several terminals (and their prompts) are rendered at the same time. Which it took us a long time to understand. This is due to iTerm2 on MacOS (at least in @pkernevez case). when iTerm2 changes screen (in a multi screen setup) it seems to render all the prompts of the open terminal (maybe to account for the different layout/real estate). And that creates the concurrent call.