Thanks to visit codestin.com
Credit goes to github.com

Skip to content

sys, dialer: support AF_UNIX sockets on Windows#12921

Draft
djs55 wants to merge 1 commit intocontainerd:mainfrom
djs55:windows-support-afunix
Draft

sys, dialer: support AF_UNIX sockets on Windows#12921
djs55 wants to merge 1 commit intocontainerd:mainfrom
djs55:windows-support-afunix

Conversation

@djs55
Copy link

@djs55 djs55 commented Feb 19, 2026

GetLocalListener and the containerd dialer on Windows were hardcoded to use named pipes via go-winio. AF_UNIX sockets are supported on Windows 10 1803+ and Windows Server 2019+, and Go supports them natively via net.Listen("unix", path) / net.DialTimeout("unix", ...).

Accept

  • \.\pipe... for backward compat
  • npipe://
  • unix://

Note Windows also has the 108 byte Limit (same as Linux), but there is hope, see: https://lwn.net/Articles/987098/

This will help get containerd + nerdbox working on Windows.

Include some extremely basic unit tests, as documentation for the different paths accepted.

GetLocalListener and the containerd dialer on Windows were hardcoded to
use named pipes via go-winio. AF_UNIX sockets are supported on Windows
10 1803+ and Windows Server 2019+, and Go supports them natively via
net.Listen("unix", path) / net.DialTimeout("unix", ...).

Accept
- \.\pipe\... for backward compat
- npipe://
- unix://

Note Windows also has the 108 byte Limit (same as Linux), but there is
hope, see: https://lwn.net/Articles/987098/

Include some extremely basic unit tests, as documentation for the
different paths accepted.

Signed-off-by: David Scott <[email protected]>
@djs55 djs55 force-pushed the windows-support-afunix branch from b5ff352 to d04100f Compare February 19, 2026 12:46
djs55 added a commit to djs55/containerd that referenced this pull request Feb 19, 2026
Co-Authored-By: Claude Opus 4.6 (1M context) <[email protected]>
if len(path) > 108 {
return nil, fmt.Errorf("%q: unix socket path too long (> 108)", path)
}
if err := os.MkdirAll(filepath.Dir(path), 0660); err != nil {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This won't change permissions (or ownership) for existing directories. Actually, I think on Windows, mode is ignored entirely, as it trickles down to syscall.MkDir; https://github.com/golang/go/blob/b2b1e923ed0e6e44f38948acf601ea22b46087a2/src/syscall/syscall_windows.go#L623-L629

if err := os.Remove(path); err != nil && !os.IsNotExist(err) {
return nil, err
}
l, err := net.Listen("unix", path)
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Which also means that potentially the socket is accessible to "everyone"? I know I looked at some of that when working on;

dmcgowan pushed a commit to dmcgowan/containerd that referenced this pull request Feb 19, 2026
@samuelkarp
Copy link
Member

This will help get containerd + nerdbox working on Windows.

Can nerdbox use the same named pipe client that all the other Windows clients use? Is there any specific need for an AF_UNIX socket in particular?

dmcgowan added a commit to dmcgowan/containerd that referenced this pull request Feb 19, 2026
Updates:
+ Add cherry-pick for containerd#12921 (AF_UNIX on Windows)

Signed-off-by: Derek McGowan <[email protected]>
dmcgowan added a commit to dmcgowan/containerd that referenced this pull request Feb 24, 2026
Updates:
+ Add cherry-pick for containerd#12921 (AF_UNIX on Windows)

Signed-off-by: Derek McGowan <[email protected]>
djs55 pushed a commit to djs55/containerd that referenced this pull request Feb 25, 2026
Updates:
+ Add cherry-pick for containerd#12921 (AF_UNIX on Windows)

Signed-off-by: Derek McGowan <[email protected]>
@djs55
Copy link
Author

djs55 commented Feb 25, 2026

This will help get containerd + nerdbox working on Windows.

Can nerdbox use the same named pipe client that all the other Windows clients use? Is there any specific need for an AF_UNIX socket in particular?

I think either would work, personally in other projects I've been moving away from named pipes towards AF_UNIX to reduce divergence between Windows + Unix but I don't mind either way.

@djs55
Copy link
Author

djs55 commented Feb 25, 2026

Sorry I should have said: thanks for taking a look! I'm trying to get nerdbox working on Windows at the moment, once it's working end-to-end I'll circle back again to polish things. I should probably have made this PR a draft for the moment :) I'll do that now.

@djs55 djs55 marked this pull request as draft February 25, 2026 16:48
dmcgowan added a commit to dmcgowan/containerd that referenced this pull request Feb 25, 2026
Updates:
+ Add cherry-pick for containerd#12921 (AF_UNIX on Windows)

Signed-off-by: Derek McGowan <[email protected]>
@samuelkarp
Copy link
Member

personally in other projects I've been moving away from named pipes towards AF_UNIX to reduce divergence between Windows + Unix

containerd needs to maintain named pipe support on Windows for CRI (Kubernetes) and Docker today, and our named pipe support is mature and works. My preference is to avoid adding more scope to our Windows code (especially as the number of contributors and maintainers that work specifically on Windows is dwindling) until it becomes necessary.

@tianon
Copy link
Member

tianon commented Feb 25, 2026

Can nerdbox use the same named pipe client that all the other Windows clients use? Is there any specific need for an AF_UNIX socket in particular?

Using Windows as a desktop system, I run into this often personally with both containerd and the Docker Engine because WSL cannot access named pipes directly (see https://github.com/jstarks/npiperelay for the most common hack to overcome this).

Having the ability to have daemons like this listen directly on a unix socket would open the possibility for Linux tools inside WSL to interact with them directly: https://devblogs.microsoft.com/commandline/windowswsl-interop-with-af_unix/ 🙇

My preference is to avoid adding more scope to our Windows code (especially as the number of contributors and maintainers that work specifically on Windows is dwindling) until it becomes necessary.

(However, I can fully 100% understand and appreciate that Windows is back to a lack of being an actively supported/maintained platform 🙇 😭 🖤)


for the avoidance of doubt / in case it's not as obvious as I think it is: while I work at the same company as David and Seb, I am not involved in this PR at all and am simply a casual observer who happens to use Windows sometimes and suffers from a papercut this could fix so figured noting another use case was potentially helpful added context ❤️

dmcgowan added a commit to dmcgowan/containerd that referenced this pull request Feb 27, 2026
Updates:
+ Add cherry-pick for containerd#12921 (AF_UNIX on Windows)

Signed-off-by: Derek McGowan <[email protected]>
dmcgowan added a commit to dmcgowan/containerd that referenced this pull request Feb 27, 2026
Updates:
+ Add cherry-pick for containerd#12921 (AF_UNIX on Windows)
+ Update cherry pick to deduplicate commits

Signed-off-by: Derek McGowan <[email protected]>
dmcgowan added a commit to dmcgowan/containerd that referenced this pull request Mar 2, 2026
Updates:
+ Add cherry-pick for containerd#12921 (AF_UNIX on Windows)
+ Update cherry pick to deduplicate commits

Signed-off-by: Derek McGowan <[email protected]>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

Status: Needs Triage

Development

Successfully merging this pull request may close these issues.

5 participants