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

git-maintenance doesn't work on WSL #604

Closed
2 tasks done
nedsociety opened this issue Sep 8, 2023 · 19 comments · Fixed by #605
Closed
2 tasks done

git-maintenance doesn't work on WSL #604

nedsociety opened this issue Sep 8, 2023 · 19 comments · Fixed by #605

Comments

@nedsociety
Copy link

nedsociety commented Sep 8, 2023

Setup

  • Which version of microsoft/git are you using? Is it 32-bit or 64-bit?
$ git --version --build-options
git version 2.39.2.vfs.0.0
cpu: x86_64
built from commit: e7fd49f4d278a3c36be6c1ef7e720e893fd5c747
sizeof-long: 8
sizeof-size_t: 8
shell-path: /bin/sh
  • Are you using Scalar or VFS for Git?

I'm using scalar but I'd believe that the vanilla git-maintenance also has the problem.

  • Which version of Windows are you running? Vista, 7, 8, 10? Is it 32-bit or 64-bit?

WSL, ubuntu, 22.04

  • Any other interesting things about your environment that might be related
    to the issue you're seeing?

Systemd is enabled. The .gitconfig in WSL refers to the host's git credential provider.

Details

  1. enable systemd in WSL
  2. add this line to .gitconfig (path may differ)
[credential]
        helper = "/mnt/c/Program\\ Files/Git/mingw64/bin/git-credential-manager.exe"
scalar register <your repo>
  • What did you expect to occur after running these commands?

the hourly systemd job is executed without an error.

  • What actually happened instead?

it fails since WSL can't run the host credential manager.

  • If the problem was occurring with a specific repository, can you specify
    the repository?

    • Other internal repo.

X-posting of microsoft/WSL#10459 . I'd believe that a fix from WSL should be a better solution, but git may also generate a better service unit file to workaround the issue.

git/builtin/gc.c

Line 2443 in 0e35ce9

"RestrictAddressFamilies=AF_UNIX AF_INET AF_INET6\n"

Apparently this list is not enough for WSL to run the host-side cred provider.

@dscho
Copy link
Member

dscho commented Sep 8, 2023

it fails since WSL can't run the host credential manager.

Is this only the case when Git maintenance runs, or do you also experience this when running git fetch manually in WSL?

@nedsociety
Copy link
Author

nedsociety commented Sep 8, 2023

Is this only the case when Git maintenance runs, or do you also experience this when running git fetch manually in WSL?

Only when git maintenance runs through systemd. Both git fetch and git for-each-repo --config=maintenance.repo maintenance run runs fine on login shell, though it doesn't really help if it's not scheduled.

@dscho
Copy link
Member

dscho commented Sep 8, 2023

@mjcheetham this seems to be a Git Credential Manager problem more than a microsoft/git problem. Would you have any insights?

@nedsociety
Copy link
Author

FYI, changing ExecStart to /mnt/c/Windows/system32/cmd.exe /c "echo test" also shows the same error. I doubt GCM is directly responsible for this issue.

@dscho
Copy link
Member

dscho commented Sep 8, 2023

changing ExecStart to /mnt/c/Windows/system32/cmd.exe /c "echo test" also shows the same error.

Oh, you see an error message somewhere? And where is that ExecStart coming from that you mentioned?

@dscho
Copy link
Member

dscho commented Sep 8, 2023

And how did you enable systemd? Could you please provide a step-by-step minimal reproducer? Like, using Git Credential Manager or CMD directly in a file in .config/ somewhere I guess?

@dscho
Copy link
Member

dscho commented Sep 8, 2023

git/builtin/gc.c

Line 2443 in 0e35ce9

"RestrictAddressFamilies=AF_UNIX AF_INET AF_INET6\n"

Apparently this list is not enough for WSL to run the host-side cred provider.

Are you saying that it works if you remove that RestrictAddressFamilies line?

@nedsociety
Copy link
Author

nedsociety commented Sep 8, 2023

Reproducer

  1. Install WSL from Microsoft Store. Then install Ubuntu 22.04.
  2. Enable systemd as guided in here.
  3. Install git on the host. I installed it with the official git-scm installer release with the following option:
    image
  4. From host, clone a private github repo with HTTPS. It will ask for github authentication info for the first time. Do it.
  5. Install microsoft-git inside WSL.
  6. In WSL create ~/.gitconfig with the following content: (the path may change if the host git installation path is different)
[credential]
        helper = "/mnt/c/Program\\ Files/Git/mingw64/bin/git-credential-manager.exe"
  1. Now use scalar to clone the same repo as in the step 4. It won't ask the info twice since it now uses the credential helper from the host's git installation. This is an expected behavior.
  2. During the scalar clone it would have installed a systemd timer called git-maintenance in ~/.config/systemd/user. This behavior is also expected.
  3. Now trigger it with systemctl --user start git-maintenance@hourly.service. It fails:
ned@NEDHOME ~ $ systemctl --user start git-maintenance@hourly.service
Job for git-maintenance@hourly.service failed because the control process exited with error code.
See "systemctl --user status git-maintenance@hourly.service" and "journalctl --user -xeu git-maintenance@hourly.service" for details.
ned@NEDHOME ~ [1] $ systemctl --user status git-maintenance@hourly.service
× git-maintenance@hourly.service - Optimize Git repositories data
     Loaded: loaded (/home/ned/.config/systemd/user/git-maintenance@.service; static)
     Active: failed (Result: exit-code) since Fri 2023-09-08 22:01:08 KST; 12s ago
TriggeredBy: ● git-maintenance@hourly.timer
    Process: 747380 ExecStart=/usr/local/lib/git-core/git --exec-path=/usr/local/lib/git-core for-each-repo --config=ma>
   Main PID: 747380 (code=exited, status=1/FAILURE)

Sep 08 22:01:07 NEDHOME systemd[437]: Starting Optimize Git repositories data...
Sep 08 22:01:08 NEDHOME git[747387]: WSL (747387) ERROR: UtilBindVsockAnyPort:285: socket failed 97
Sep 08 22:01:08 NEDHOME git[747381]: fatal: could not read Username for 'https://github.com': No such device or address
Sep 08 22:01:08 NEDHOME git[747381]: error: failed to prefetch remotes
Sep 08 22:01:08 NEDHOME git[747381]: error: task 'prefetch' failed
Sep 08 22:01:08 NEDHOME systemd[437]: git-maintenance@hourly.service: Main process exited, code=exited, status=1/FAILURE
Sep 08 22:01:08 NEDHOME systemd[437]: git-maintenance@hourly.service: Failed with result 'exit-code'.
Sep 08 22:01:08 NEDHOME systemd[437]: Failed to start Optimize Git repositories data.

Fiddling with the configuration

The file ~/.config/systemd/user/git-maintenance@.service has a systemd timer setup for git-maintenance.

# This file was created and is maintained by Git.
# Any edits made in this file might be replaced in the future
# by a Git command.

[Unit]
Description=Optimize Git repositories data

[Service]
Type=oneshot
ExecStart="/usr/local/lib/git-core/git" --exec-path="/usr/local/lib/git-core" for-each-repo --config=maintenance.repo maintenance run --schedule=%i
LockPersonality=yes
MemoryDenyWriteExecute=yes
NoNewPrivileges=yes
RestrictAddressFamilies=AF_UNIX AF_INET AF_INET6
RestrictNamespaces=yes
RestrictRealtime=yes
RestrictSUIDSGID=yes
SystemCallArchitectures=native
SystemCallFilter=@system-service
  • Calling the ExecStart line manually (replacing %i to hourly) in the login shell does the maintenance job successfully.
  • Changing ExecStart to something like /mnt/c/Windows/system32/cmd.exe /c "echo test" fails with UtilBindVsockAnyPort as noted above, which suggests that running a host binary fails when systemd runs them with these setups. That explains why git failed to run the credential helper which resides in the host side.
  • As the error mentioned UtilBindVsockAnyPort, I commented out RestrictAddressFamilies to see if it's a socket problem. It made the maintenance job successful.

@dscho
Copy link
Member

dscho commented Sep 8, 2023

  • I commented out RestrictAddressFamilies to see if it's a socket problem. It made the maintenance job successful.

Excellent finding, and valuable, important information in the context of this ticket.

Could you see whether it works if you uncomment that line and add AF_NETLINK?

@nedsociety
Copy link
Author

nedsociety commented Sep 8, 2023

AF_NETLINK

It didn't work :/ it shows the same socket error.

@dscho
Copy link
Member

dscho commented Sep 8, 2023

Can you see anything in dmesg or syslog that might give a hint what was blocked?

@nedsociety
Copy link
Author

nedsociety commented Sep 8, 2023

  • Nothing seems relevant in dmesg.
  • I don't have syslogd so no syslog available.
  • journalctl shows no more clue than what's already shown in systemctl --user status.

@dscho
Copy link
Member

dscho commented Sep 8, 2023

@nedsociety you seem to know tons more about systemd than I do, maybe you can find a list of all available AF_* values for that line, and then see whether specifying them all "makes it work"?

@nedsociety
Copy link
Author

nedsociety commented Sep 8, 2023

okay, I've got the list from here and it seems working when I put everything:

RestrictAddressFamilies=AF_UNIX AF_LOCAL AF_INET AF_AX25 AF_IPX AF_APPLETALK AF_X25 AF_INET6 AF_DECnet AF_KEY AF_NETLINK AF_PACKET AF_RDS AF_PPPOX AF_LLC AF_IB AF_MPLS AF_CAN AF_TIPC AF_BLUETOOTH AF_ALG AF_VSOCK AF_KCM AF_XDP

well but binary searching around these list seems too much hassle 😭

@dscho
Copy link
Member

dscho commented Sep 8, 2023

AF_VSOCK

This sounds awfully close to UtilBindVsockAnyPort, no?

@nedsociety
Copy link
Author

AF_VSOCK

This sounds awfully close to UtilBindVsockAnyPort, no?

Huh, good eyes. It actually worked.

@OneBlue
Copy link

OneBlue commented Sep 8, 2023

AF_VSOCK

This sounds awfully close to UtilBindVsockAnyPort, no?

Huh, good eyes. It actually worked.

Indeed as a WSL maintainer I confirm that AF_VSOCK is what we use.

@nedsociety
Copy link
Author

nedsociety commented Sep 8, 2023

With the issue in WSL repo was concluded as wontfix, I guess adding AF_VSOCK to the list seems to be the only choice left?

dscho added a commit to dscho/git that referenced this issue Sep 10, 2023
When running in the Windows Subsystem for Linux (WSL), it is usually
necessary to use the Git Credential Manager for authentication when
performing the background fetches.

This requires interoperability between the Windows Subsystem for Linux
and the Windows host to work, which uses so-called vsocks, i.e. sockets
intended for communcations between virtual machines and the host they
are running on.

However, when Git is configured to run background maintenance via
`systemd`, the address families available to those maintenance processes
are restricted, and did not include `AF_VSOCK`. This leads to problems
e.g. when a background fetch tries to access github.com:

	systemd[437]: Starting Optimize Git repositories data...
	git[747387]: WSL (747387) ERROR: UtilBindVsockAnyPort:285: socket failed 97
	git[747381]: fatal: could not read Username for 'https://github.com': No such device or address
	git[747381]: error: failed to prefetch remotes
	git[747381]: error: task 'prefetch' failed
	systemd[437]: git-maintenance@hourly.service: Main process exited, code=exited, status=1/FAILURE
	systemd[437]: git-maintenance@hourly.service: Failed with result 'exit-code'.
	systemd[437]: Failed to start Optimize Git repositories data.

Address this (pun intended) by adding the `AF_VSOCK` address family to
the allow list.

This fixes microsoft#604.

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
@dscho
Copy link
Member

dscho commented Sep 10, 2023

Indeed as a WSL maintainer I confirm that AF_VSOCK is what we use.

@OneBlue thanks for confirming!

adding AF_VSOCK to the list seems to be the only choice left?

@nedsociety yes, and it is also the correct thing to do. See gitgitgadget#1586 and #605 for the progress of the fix.

gitster pushed a commit to git/git that referenced this issue Sep 11, 2023
When running in the Windows Subsystem for Linux (WSL), it is usually
necessary to use the Git Credential Manager for authentication when
performing the background fetches.

This requires interoperability between the Windows Subsystem for Linux
and the Windows host to work, which uses so-called vsocks, i.e. sockets
intended for communcations between virtual machines and the host they
are running on.

However, when Git is configured to run background maintenance via
`systemd`, the address families available to those maintenance processes
are restricted, and did not include `AF_VSOCK`. This leads to problems
e.g. when a background fetch tries to access github.com:

	systemd[437]: Starting Optimize Git repositories data...
	git[747387]: WSL (747387) ERROR: UtilBindVsockAnyPort:285: socket failed 97
	git[747381]: fatal: could not read Username for 'https://github.com': No such device or address
	git[747381]: error: failed to prefetch remotes
	git[747381]: error: task 'prefetch' failed
	systemd[437]: git-maintenance@hourly.service: Main process exited, code=exited, status=1/FAILURE
	systemd[437]: git-maintenance@hourly.service: Failed with result 'exit-code'.
	systemd[437]: Failed to start Optimize Git repositories data.

Address this (pun intended) by adding the `AF_VSOCK` address family to
the allow list.

This fixes microsoft#604.

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
dscho added a commit to dscho/git that referenced this issue Sep 21, 2023
When running in the Windows Subsystem for Linux (WSL), it is usually
necessary to use the Git Credential Manager for authentication when
performing the background fetches.

This requires interoperability between the Windows Subsystem for Linux
and the Windows host to work, which uses so-called vsocks, i.e. sockets
intended for communcations between virtual machines and the host they
are running on.

However, when Git is configured to run background maintenance via
`systemd`, the address families available to those maintenance processes
are restricted, and did not include `AF_VSOCK`. This leads to problems
e.g. when a background fetch tries to access github.com:

	systemd[437]: Starting Optimize Git repositories data...
	git[747387]: WSL (747387) ERROR: UtilBindVsockAnyPort:285: socket failed 97
	git[747381]: fatal: could not read Username for 'https://github.com': No such device or address
	git[747381]: error: failed to prefetch remotes
	git[747381]: error: task 'prefetch' failed
	systemd[437]: git-maintenance@hourly.service: Main process exited, code=exited, status=1/FAILURE
	systemd[437]: git-maintenance@hourly.service: Failed with result 'exit-code'.
	systemd[437]: Failed to start Optimize Git repositories data.

Address this (pun intended) by adding the `AF_VSOCK` address family to
the allow list.

This fixes microsoft#604, and is a
backport of 5e8515e (maintenance(systemd): support the Windows
Subsystem for Linux, 2023-09-10).

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
dscho added a commit that referenced this issue Sep 23, 2023
dscho added a commit that referenced this issue Nov 3, 2023
When running in the Windows Subsystem for Linux (WSL), it is usually
necessary to use the Git Credential Manager for authentication when
performing the background fetches.

This requires interoperability between the Windows Subsystem for Linux
and the Windows host to work, which uses so-called vsocks, i.e. sockets
intended for communcations between virtual machines and the host they
are running on.

However, when Git is configured to run background maintenance via
`systemd`, the address families available to those maintenance processes
are restricted, and did not include `AF_VSOCK`. This leads to problems
e.g. when a background fetch tries to access github.com:

	systemd[437]: Starting Optimize Git repositories data...
	git[747387]: WSL (747387) ERROR: UtilBindVsockAnyPort:285: socket failed 97
	git[747381]: fatal: could not read Username for 'https://github.com': No such device or address
	git[747381]: error: failed to prefetch remotes
	git[747381]: error: task 'prefetch' failed
	systemd[437]: git-maintenance@hourly.service: Main process exited, code=exited, status=1/FAILURE
	systemd[437]: git-maintenance@hourly.service: Failed with result 'exit-code'.
	systemd[437]: Failed to start Optimize Git repositories data.

Address this (pun intended) by adding the `AF_VSOCK` address family to
the allow list.

This fixes #604, and is a
backport of 5e8515e (maintenance(systemd): support the Windows
Subsystem for Linux, 2023-09-10).

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
dscho added a commit that referenced this issue Nov 3, 2023
dscho added a commit that referenced this issue Nov 3, 2023
When running in the Windows Subsystem for Linux (WSL), it is usually
necessary to use the Git Credential Manager for authentication when
performing the background fetches.

This requires interoperability between the Windows Subsystem for Linux
and the Windows host to work, which uses so-called vsocks, i.e. sockets
intended for communcations between virtual machines and the host they
are running on.

However, when Git is configured to run background maintenance via
`systemd`, the address families available to those maintenance processes
are restricted, and did not include `AF_VSOCK`. This leads to problems
e.g. when a background fetch tries to access github.com:

	systemd[437]: Starting Optimize Git repositories data...
	git[747387]: WSL (747387) ERROR: UtilBindVsockAnyPort:285: socket failed 97
	git[747381]: fatal: could not read Username for 'https://github.com': No such device or address
	git[747381]: error: failed to prefetch remotes
	git[747381]: error: task 'prefetch' failed
	systemd[437]: git-maintenance@hourly.service: Main process exited, code=exited, status=1/FAILURE
	systemd[437]: git-maintenance@hourly.service: Failed with result 'exit-code'.
	systemd[437]: Failed to start Optimize Git repositories data.

Address this (pun intended) by adding the `AF_VSOCK` address family to
the allow list.

This fixes #604, and is a
backport of 5e8515e (maintenance(systemd): support the Windows
Subsystem for Linux, 2023-09-10).

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.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
Development

Successfully merging a pull request may close this issue.

3 participants