stopped working after waking up from sleep

[Jimmy-Z]

I had to kill it, delete the sock file, restart it.

[cuviper]

Well, I can only suspect Cygwin or Windows itself, or some interaction therein. From ssh-pageant's side, the program has no clue about system sleep, and the APIs it's using shouldn't matter.

[Jimmy-Z]

Yeah, I've been using this for about a year, and only encountered this recently.

[Jimmy-Z]

As a side note, if I don't delete the socket file, it will fail like this:

> ssh-pageant.exe -d -r -a %localappdata%\ssh-pageant-sock
ssh-pageant: connect: Bad file descriptor

[localhorst]

I have a similar issue:
Starting up Cmder, including Git for Windows, I get this error:

ssh-pageant: connect: Bad file descriptor
ssh-pageant: connect: Bad file descriptor

Note that it's printed twice, because I have two ssh keys registered in Git.
When using Git commands, the keys are found, but I have to type in my passphrase each time I connect to a repo

I had no success in deleting ssh-pageant-sock
Can you help me find a solution?
Should I discuss this with Git for Windows or Cmder?

[cuviper]

I doubt Cmder has anything to do with this. I guess you could ask Git for Windows, but I expect it will depend on their MSYS2 runtime, and probably back to Cygwin in turn.

[thw0rted]

Jimmy's comment was helpful. A previous failure had left a stale socket file in the location specified by the path argument (-a) and future invocations failed until I found and deleted it. It was helpful for me to figure out where in the shell lifecycle this was being automatically invoked (in my case, .bash_profile), which let me check the argument being passed to the -a flag.

@cuviper , would it be possible to log the name of the socket file that ssh-pageant is trying to "connect" to, when it fails in this way? Even more helpful would be to look for running instances of pageant.exe and warn if there are none, or if none of them have an open handle on the named file.

[cuviper]

would it be possible to log the name of the socket file that ssh-pageant is trying to "connect" to, when it fails in this way?

We could add a formatted warn(...) before the exit here:

ssh-pageant/main.c

Line 172 in d79751d

cleanup_warn("connect");

Even more helpful would be to look for running instances of pageant.exe and warn if there are none, or if none of them have an open handle on the named file.

That's possible, but significantly more complicated.

(And to be honest, I don't use this program myself anymore, nor even Windows except on rare occasion.)

[thw0rted]

I see you're already checking if the unusable path is a socket and trying to remove it, but that doesn't seem to have worked. My C is a little rusty (haven't used it in anger since undergrad) but it looks like the path_is_socket method is conditional based on whether __MSYS__ is defined, and on the MSys side there's a comment about the difference between how Cygwin and MSys use socket files to communicate.

This related SO question has more details about that, specifically that Cygwin uses !<socket >54321 s {guid} while MSys does not include the s literal. I'm running ssh-pageant through "Git Bash", included with "Git For Windows", which was based on MSys but now uses "Git For Windows SDK", which is maybe a fork? Anyway for whatever reason, when I launch ssh-pageant from inside Git Bash, it creates a socket file with the literal s, "Cygwin style". Is it possible that the #ifdef is giving me the first version of the method (with the comment about buggy MSys), making it to the if on L137, and failing the test because it's a 54-byte-style file instead of 52-byte-style?

I'm not sure where I even got my ssh-pageant binary from, maybe it's distributed with Git For Windows, or by the PuTTY distro I got -- it just shows up in /usr/bin in Bash. I'm not sure how to tell which branch of the macro I wound up with. But I think that it wouldn't hurt to update the first (longer) version of path_is_socket to include the possibility of a 54-byte socket file, adding that to L137 and updating the fscanf on L141. (I don't know enough scanf-fu to say "optionally with this extra literal"; maybe it's safe enough to just delete any file that's exactly 52 or 54 bytes and starts with !<socket >{digits} ? If somebody stored important data in the GUID section of a file that starts with the Cygwin socket sequence, they deserve what they get.)

I think I know enough C to make these tiny changes myself, but I definitely don't have the infrastructure set up right now to build and test them. I noticed you're now working for RHEL, but maybe there's a more active maintainer still on the project who could take a look at this?

[cuviper]

The MSYS fallbacks are for the old MSYS based on the original MinGW and an old fork of Cygwin, and is now basically defunct. The modern MSYS2 is based on mingw-w64 (even for 32-bit) and stays in sync with current Cygwin development, and AFAIK this is still what the Git for Windows SDK is based on. From #29 and #30 you can see that the __NEWLIB__ condition distinguishes MSYS and MSYS2. You shouldn't be getting into that old compat code at all.

maybe there's a more active maintainer still on the project who could take a look at this?

There's been no other maintainer here, just the occasional contributor passing by. It's such a tiny tool that it never really needed much, but hopefully some interested user can find time to dig into this issue, if you're not able. Maybe the Git for Windows folks can take a look, since they're shipping ssh-pageant.