Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

credential-cache error "fatal: unable to connect to cache daemon: Unknown error" #5314

Open
1 task done
hickford opened this issue Dec 16, 2024 · 10 comments · May be fixed by #5329
Open
1 task done

credential-cache error "fatal: unable to connect to cache daemon: Unknown error" #5314

hickford opened this issue Dec 16, 2024 · 10 comments · May be fixed by #5329

Comments

@hickford
Copy link

hickford commented Dec 16, 2024

  • I was not able to find an open or closed issue matching what I'm seeing

Setup

  • Which version of Git for Windows are you using? Is it 32-bit or 64-bit?
$ git --version --build-options
git version 2.47.1.windows.1
cpu: x86_64
built from commit: 2cd22437f64229935dc564db969cbcbfed5e9045
sizeof-long: 4
sizeof-size_t: 8
shell-path: D:/git-sdk-64-build-installers/usr/bin/sh
feature: fsmonitor--daemon
libcurl: 8.11.0
OpenSSL: OpenSSL 3.2.3 3 Sep 2024
zlib: 1.3.1
  • Which version of Windows are you running?

Windows 11

$ cmd.exe /c ver
Microsoft Windows [Version 10.0.26100.2314]

Details

  • Which terminal/shell are you running Git from?

cmd

  • What commands did you run to trigger this issue?
printf "host=bitbucket.org\nprotocol=https\nusername=tim\npassword=hunter2\n" | git credential-cache store
printf "host=bitbucket.org\nprotocol=https\n" | git credential-cache get
  • What did you expect to occur after running these commands?

Credential saved and retrieved.

  • What actually happened instead?

Error "fatal: unable to connect to cache daemon: Unknown error"

@hickford
Copy link
Author

On another computer this bug occurs intermittently.

@hickford
Copy link
Author

hickford commented Dec 21, 2024

Workaround: delete empty directory %USERPROFILE\.cache\git\credential

@hickford
Copy link
Author

hickford commented Dec 21, 2024

@rimrul Try this to reproduce (corrected path):

  1. Exit cache git credential-cache exit
  2. Store credential with 10 second timeout printf "host=example.com\nprotocol=https\nusername=tim\npassword=hunter2\n" | git credential-cache --timeout 10 store
  3. Observe that file %USERPROFILE\.cache\git\credential\socket is created
  4. Wait about 40 seconds
  5. Observe that file %USERPROFILE\.cache\git\credential\socket has disappeared
  6. Get credential printf "host=example.com\nprotocol=https\n" | git credential-cache get

Expected: empty output

What actually happens: "fatal: unable to connect to cache daemon: Unknown error". Interestingly echo %ERRORLEVEL% prints 128 (ENOTSOCK in errno.h).

To workaround: delete empty directory %USERPROFILE\.cache\git\credential

@rimrul
Copy link
Member

rimrul commented Dec 21, 2024

That does reproduce for me, with a slight difference. The socket file appears and disappears in %USERPROFILE%\.cache\git\credential

@rimrul
Copy link
Member

rimrul commented Dec 21, 2024

And the mistery errno is ECONNREFUSED.

@hickford
Copy link
Author

hickford commented Dec 22, 2024

@rimrul Unfortunately error message "unable to connect to cache daemon" has two possible sources:

if (send_request(socket, &buf) < 0) {
if (connection_fatally_broken(errno))
die_errno("unable to connect to cache daemon");
if (flags & FLAG_SPAWN) {
spawn_daemon(socket);
if (send_request(socket, &buf) < 0)
die_errno("unable to connect to cache daemon");

Assuming the error comes from the first source, perhaps the fix is to add extra error codes to function connection_fatally_broken:

static int connection_fatally_broken(int error)
{
return (error != ENOENT) && (error != ENETDOWN);
}

rimrul added a commit to rimrul/git that referenced this issue Dec 22, 2024
In 245670c (credential-cache: check for windows specific errors, 2021-09-14)
we concluded that on Windows we would always encounter ENETDOWN where we
would expect ECONNREFUSED on POSIX systems, when connecting to unix sockets.
As reported in [1], we do sometimes encounter ECONNREFUSED on Windows aswell,
though. we should handle these cases like we do on non-windows systems.

[1] git-for-windows#4762 (comment)

This fixes git-for-windows#5314

Helped-by: M Hickford <mirth.hickford@gmail.com>
Signed-off-by: Matthias Aßhauer <mha1993@live.de>
@rimrul rimrul linked a pull request Dec 22, 2024 that will close this issue
rimrul added a commit to rimrul/git that referenced this issue Dec 22, 2024
In 245670c (credential-cache: check for windows specific errors, 2021-09-14)
we concluded that on Windows we would always encounter ENETDOWN where we
would expect ECONNREFUSED on POSIX systems, when connecting to unix sockets.
As reported in [1], we do sometimes encounter ECONNREFUSED on Windows aswell,
though. we should handle these cases like we do on non-windows systems.

[1] git-for-windows#4762 (comment)

This fixes git-for-windows#5314

Helped-by: M Hickford <mirth.hickford@gmail.com>
Signed-off-by: Matthias Aßhauer <mha1993@live.de>
rimrul added a commit to rimrul/git that referenced this issue Dec 22, 2024
In 245670c (credential-cache: check for windows specific errors, 2021-09-14)
we concluded that on Windows we would always encounter ENETDOWN where we
would expect ECONNREFUSED on POSIX systems, when connecting to unix sockets.
As reported in [1], we do sometimes encounter ECONNREFUSED on Windows aswell,
though. we should handle these cases like we do on non-windows systems.

[1] git-for-windows#4762 (comment)

This fixes git-for-windows#5314

Helped-by: M Hickford <mirth.hickford@gmail.com>
Signed-off-by: Matthias Aßhauer <mha1993@live.de>
@hickford
Copy link
Author

And the mistery errno is ECONNREFUSED.

How did you determine that?

For me exit code %errorlevel% was 128. Is that equal to errno? I can't see how die_errno works.

@rimrul
Copy link
Member

rimrul commented Dec 22, 2024

I wrote a small wrapper around strerror() that handled the cases that default strerror() didn't and then ran the reproducer.

@rimrul
Copy link
Member

rimrul commented Dec 22, 2024

Looking over the code of die_errno() it looks like it usually ends up in die_builtin() which always exits 128.

git/usage.c

Lines 73 to 79 in f1241af

static NORETURN void die_builtin(const char *err, va_list params)
{
report_fn die_message_fn = get_die_message_routine();
die_message_fn(err, params);
exit(128);
}

@hickford
Copy link
Author

Thanks! So it was just a coincidence that errno 128 happens to relates to sockets. I'll cancel my PR.

rimrul added a commit to rimrul/git that referenced this issue Dec 28, 2024
In 245670c (credential-cache: check for windows specific errors, 2021-09-14)
we concluded that on Windows we would always encounter ENETDOWN where we
would expect ECONNREFUSED on POSIX systems, when connecting to unix sockets.
As reported in [1], we do sometimes encounter ECONNREFUSED on Windows aswell,
though. we should handle these cases like we do on non-windows systems.

[1] git-for-windows#4762 (comment)

This fixes git-for-windows#5314

Helped-by: M Hickford <mirth.hickford@gmail.com>
Signed-off-by: Matthias Aßhauer <mha1993@live.de>
rimrul added a commit to rimrul/git that referenced this issue Dec 28, 2024
In 245670c (credential-cache: check for windows specific errors, 2021-09-14)
we concluded that on Windows we would always encounter ENETDOWN where we
would expect ECONNREFUSED on POSIX systems, when connecting to unix sockets.
As reported in [1], we do sometimes encounter ECONNREFUSED on Windows aswell,
though. we should handle these cases like we do on non-windows systems.

[1] git-for-windows#4762 (comment)

This fixes git-for-windows#5314

Helped-by: M Hickford <mirth.hickford@gmail.com>
Signed-off-by: Matthias Aßhauer <mha1993@live.de>
rimrul added a commit to rimrul/git that referenced this issue Dec 28, 2024
In 245670c (credential-cache: check for windows specific errors, 2021-09-14)
we concluded that on Windows we would always encounter ENETDOWN where we
would expect ECONNREFUSED on POSIX systems, when connecting to unix sockets.
As reported in [1], we do encounter ECONNREFUSED on Windows if the
socket file doesn't exist, but the containing directory does and ENETDOWN if
neither exists. We should handle this case like we do on non-windows systems.

[1] git-for-windows#4762 (comment)

This fixes git-for-windows#5314

Helped-by: M Hickford <mirth.hickford@gmail.com>
Signed-off-by: Matthias Aßhauer <mha1993@live.de>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
2 participants