Skip to content

test-servers: put unix-domain-path inside LOGDIR#19810

Closed
icing wants to merge 4 commits intocurl:masterfrom
icing:test-uds-in-logdir
Closed

test-servers: put unix-domain-path inside LOGDIR#19810
icing wants to merge 4 commits intocurl:masterfrom
icing:test-uds-in-logdir

Conversation

@icing
Copy link
Contributor

@icing icing commented Dec 2, 2025

Seeing errors in Windows runs like Error binding socket on path C:/msys64/tmp/curl-socksd-42Ne8CeN, place the UDS paths into the test runners $LOGDIR to avoid possible interferences in parallel runs.

The UDS paths are created as temp files, but unlinked right away before passing them on to started servers. By using $LOGDIR, we avoid possible mixups here.

Seeing errors in Windows runs like `Error binding socket on path C:/msys64/tmp/curl-socksd-42Ne8CeN`,
place the UDS paths into the test runners $LOGDIR to avoid possible interferences
in parallel runs.

The UDS paths are created as temp files, but unlinked right away before passing
them on to started servers. By using $LOGDIR, we avoid possible mixups here.
@icing
Copy link
Contributor Author

icing commented Dec 2, 2025

@dfandrich I hope this is a good way to achieve this. My perl is not what it used to be...

@icing
Copy link
Contributor Author

icing commented Dec 2, 2025

@vszakats
Copy link
Member

vszakats commented Dec 2, 2025

Tried in a local Win 11 VM, and the result is similar (WSAEOPNOTSUPP):

> servers.exe sws --unix-socket hello.sock 
17:37:07.618437 Error binding socket on path hello.sock (10045) The attempted operation is not supported for the type of object referenced.

Support seems to be present:

> sc query afunix 

SERVICE_NAME: afunix 
        TYPE               : 1  KERNEL_DRIVER  
        STATE              : 4  RUNNING 
                                (STOPPABLE, NOT_PAUSABLE, IGNORES_SHUTDOWN)
        WIN32_EXIT_CODE    : 0  (0x0)
        SERVICE_EXIT_CODE  : 0  (0x0)
        CHECKPOINT         : 0x0
        WAIT_HINT          : 0x0

https://devblogs.microsoft.com/commandline/af_unix-comes-to-windows/
https://devblogs.microsoft.com/commandline/windowswsl-interop-with-af_unix/

@vszakats
Copy link
Member

vszakats commented Dec 2, 2025

Testing now with #19812. It seems to make it work in the above env.

Ref: https://stackoverflow.com/questions/68791319/unix-domain-socket-bind-failed-in-windows/68794755#68794755

@icing
Copy link
Contributor Author

icing commented Dec 2, 2025

@vszakats
Copy link
Member

vszakats commented Dec 3, 2025

With this applied over #19812, curl uses an absolute filename to connect to the socks5 server,
which is a step to the right direction, but it confuses the URL parser, breaking with this:

curl.exe ... --socks5 localhostD:/a/curl/curl/bld/tests/log/8/server/socks-uds ...
=== Start of file trace1467
 15:15:41.269000 * !!! WARNING !!
 15:15:41.269000 * This is a debug build of libcurl, do not use in production.
 15:15:41.269000 * alloc connection, bits.close=0
 15:15:41.269000 * Unsupported proxy scheme for 'localhostD:/a/curl/curl/bld/tests/log/8/server/socks-uds'
 15:15:41.269000 * closing connection #-

https://github.com/curl/curl/actions/runs/19898592049/job/57035659366?pr=19812#step:13:2682

Without this applied, the URL confusion does not happen, but the socks5 filename is an incorrect,
relative one on Windows:

curl.exe ... --socks5 localhost/tmp/curl-socksd-xe3LMbVY ...
=== Start of file trace1467
 14:11:55.693000 * !!! WARNING !!
 14:11:55.693000 * This is a debug build of libcurl, do not use in production.
 14:11:55.693000 * alloc connection, bits.close=0
 14:11:55.693000 * setup connection, bits.close=0
 14:11:55.693000 * setup connection, bits.close=0
 14:11:55.693000 * new connection, bits.close=0
 14:11:55.693000 *   Trying /tmp/curl-socksd-xe3LMbVY:0...
 14:11:55.693000 * Immediate connect fail for /tmp/curl-socksd-xe3LMbVY: Network down
 14:11:55.693000 * Failed to connect to 127.0.0.1 port 64407 via localhost/tmp/curl-socksd-xe3LMbVY after 4 ms: Could not connect to server
 14:11:55.693000 * closing connection #0

https://github.com/curl/curl/actions/runs/19896583933/job/57028545111?pr=19812

I think this patch helps, but the URL format does not support Windowsy names:
Ref: dfa84a0 #8668.

@icing
Copy link
Contributor Author

icing commented Dec 4, 2025

@vszakats can I close this one, since you have merged it into yours?

@vszakats
Copy link
Member

vszakats commented Dec 4, 2025

@icing I planned to merge it separately, but was still thinking how to describe
it. What do you think of this?:

Change Unix domain socket paths from /tmp/curl-socksd-<random> to
/drive/path/to/LOGDIR/PIDDIR/*-uds to avoid having to create and
delete them before use. Also to use a path which remains an absolute one
while passed from MSYS2 Perl to native Windows curl tool and test server
via the command-line, and keep pointing to the same location, fixing:

=== Start of file commands.log
../src/curl.exe -q --output log/3/curl1468.out --include --trace-ascii log/3/trace1468
  --trace-time http://this.is.a.host.name:64405/1468
  --proxy socks5h://localhost/tmp/curl-socksd-YnbvRo98 [...]
=== End of file commands.log
=== Start of file socks2_server.log
[...]
14:11:54.597968 Listening on Unix socket D:/a/_temp/msys64/tmp/curl-socksd-YnbvRo98

Ref: https://github.com/curl/curl/actions/runs/19896583933/job/57028545111?pr=19812

The curl tool is pending #19825 to fix accepting an absolute unix domain
socket filename on Windows.

vszakats added a commit that referenced this pull request Dec 4, 2025
Windows 10.17063+ (having unix socket support) fails to set for unix
sockets the `SO_REUSEADDR` option, with error 10045 (`WSAEOPNOTSUPP`),
and also fails to set `SO_KEEPALIVE` with error 10042 (`WSAENOPROTOOPT`).

Fix by not enabling these socket options on Windows for unix sockets.

Also:
- fixing test 1435, 1436 to run in CI.
- fixing the `socksd` test server for test 1467, 1468, 1470. But, also
  disable these for now due to another Windows issue: #19825

Ref: https://stackoverflow.com/questions/68791319/unix-domain-socket-bind-failed-in-windows/68794755#68794755
Ref: #19810
Closes #19812
@vszakats vszakats closed this in 8d9aa6d Dec 5, 2025
@vszakats
Copy link
Member

vszakats commented Dec 5, 2025

Merged now with the text above. Thanks!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Development

Successfully merging this pull request may close these issues.

2 participants