ghub keeps opening processes until it locks Emacs

[Joel Ekström]

I'm not entirely sure the origin of this issue is actually ghub, it might be magit trying to request data - but here's the problem at least:

If I have emacs running for a while (few hours), eventually I won't be able to save or open files any more because of "too many open file handles". The issue appears to be that ghub tries to open connections that it never closes. When this problem appears I usually have around 100 open buffers in fundamental mode containing the following message:

Lisp expression: Such a Github API token is not available:

  Host:    api.github.com
  User:    accatyyc
  Package: ghub

  Scopes requested in `ghub-github-token-scopes':
    repo
  Store on Github as:
    "Emacs package ghub @ Joels-Macbook-Pro"
  Store locally according to option `auth-sources':
    ("~/.authinfo" "~/.authinfo.gpg" "~/.netrc")

WARNING: The token will be stored unencrypted in "~/.authinfo".
         If you don't want that, you have to abort and customize
         the `auth-sources' option.

If in doubt, then abort and first view the section of
the Ghub documentation called "Interactively Creating
and Storing a Token".

Otherwise confirm and then provide your Github username and
password at the next two prompts.  Depending on the backend
you might have to provide a passphrase and confirm that you
really want to save the token.

Create and store such a token? (yes or no) 

Since the buffers are just fundamental mode I cannot interact with them even if the message seems meant to be interactive.

If I try to close these buffers, emacs will complain that they have running processes.

The issue is probably something with my tokens that I can fix, but I think ghub is doing the wrong thing here to bring down emacs with it!

[Jonas Bernoulli]

ghub keeps opening processes until it locks Emacs

Are you sure it opens processes? If so, does it close them? Later you only talk about buffers, not processes.

When this problem appears I usually have around 100 open buffers in fundamental mode containing the following message:

Ghub doesn't put that text into buffers; it passes it to yes-or-no-p. I don't see how a bug in Ghub could cause the text to end up in buffers instead. Do you advice or redefine yes-or-no-p?

What ghub-using packages do you use? Do you use any custom code that uses ghub directly? Packages are supposed to identify themselves; since the text contains "Package: ghub", that means that you are either using custom code (which does not have to identify itself) or some package is not identifying itself (which it should, among other things because it would help narrow the issue down).

[Joel Ekström]

Are you sure it opens processes? If so, does it close them? Later you only talk about buffers, not processes.

Emacs says the buffers have running processes when I attempt to close them.

Ghub doesn't put that text into buffers; it passes it to yes-or-no-p. I don't see how a bug in Ghub could cause the text to end up in buffers instead. Do you advice or redefine yes-or-no-p?

The only thing I can think of is this:

(fset 'yes-or-no-p 'y-or-n-p)

I do not use ghub in any custom code (in fact, I wasn't aware that this package existed until these errors started appearing 😅)

I'm looking through my packages to find out if anything could be using this - I need to figure out how to find which packages are responsible for a dependency. From a brief look of all my installed packages I see nothing except magit that might want to interact with github though.

[Joel Ekström]

Update on this: I looked through all my packages and there was nothing that required ghub, which means it was an old dependency (which actually makes this ghastly behaviour even weirder. What was using it?).

I did a package-autoremove and it's now gone (and the ghost buffers with it). But still, if nothing was installed that was using it, why was it triggered in the first place? 🤔

[Jonas Bernoulli]

What was using it?

Magit depended on it for a while but the functionality that made that necessary has now been moved to the new Forge package.

But still, if nothing was installed that was using it, why was it triggered in the first place?

If nothing explicitly requires it, then it should not even get loaded, which would also prevent it from doing anything. So I have no idea what was going on and I don't think we will ever find out.