Could not create wakeup socket pair for CFSocket

[danpalmer]

Hey, I've been tracking down an issue with async process I/O on Linux in Swift. I've previously used tuist/Command, and have also used my own basic re-implementation, and today I tried SwiftCommand.

So far all 3 have exhibited the same problem. On the first command invoked, the process hangs, and the following is output:

...10:58:26 <myproject>.xctest[2613:7efdec80] *** Could not create wakeup socket pair for CFSocket!!!

I've written about this here: swiftlang/swift-corelibs-foundation#5197 as well. I had assumed it was my codebase, but 3 implementations suggested to me that it must be a framework bug. However, the fact that no other applications have seen this, and the fact that SwiftCommand has a working Linux test suite, suggests that perhaps it's something complex about how my application is set up.

I can reproduce this 100% of the time when running a serial test suite written with Swift Testing. I'm using the Vapor web framework, and have various other I/O going on such as connections to Postgres.

This issue is a starting point for discussion, because I don't know where the solution will end up being, but I'd appreciate any input you can provide. Are there any issues you're aware of with SwiftCommand that could contribute to this, or could explain the hangs? Do you know of any machine state that needs to be set up correctly for it to work (I've already checked file handle limits)? Have you tried things like parallel invocation of SwiftCommand, or running it off the main thread?

Thanks in advance for your help!

[Zollerboy1]

Hey Dan,

I'm not sure how to reproduce this using SwiftCommand.
Does your (very simple) implementation using tuist/Command in https://github.com/danpalmer/swift-linux-issue/blob/c64576e8c0f9e38e61737288088e515740f0c22d/Sources/swift-linux-issue/tuist_command_impl.swift already exhibit this behavior?
I tried to write a similar program using SwiftCommand:

@preconcurrency import SwiftCommand

let process = try Command.findInPath(withName: "ls")!
    .addArgument(".")
    .setStdout(.pipe)
    .spawn()

let stdoutTask = Task {
    for try await line in process.stdout.lines {
        print(line)
    }
    print("Done!")
}

let status = try await process.status
print("Status: \(status)")

try await stdoutTask.value

(Apparently, I have to update SwiftCommand to Swift 6 at some point, to get rid this @preconcurrency attribute which is currently necessary...)

This works both in macOS and using docker run --rm -v $(pwd):/code -w /code swift:6.1.0 swift run.

It seems to me that you are most likely running into a Foundation bug, so I guess you should focus on resolving the issue there. However, if you can provide more context with which I could reproduce your problem using SwiftCommand, I'd be happy to help!

[danpalmer]

It seems to me that you are most likely running into a Foundation bug

I think I'm running into two bugs, described in this comment: swiftlang/swift-corelibs-foundation#5197 (comment). It looks like tuist's Command and this library both run into the same issue as well, although interestingly the new Subprocess proposal from the Swift team does not run into this issue: https://github.com/iCharlesHu/Subprocess.

Happy to close this if you think it's out of scope, or if you want to pursue this issue on the Foundation bug instead. Since I've found a workaround – moving to the Subprocess library – I don't have capacity to continue investigating this as I'm on personal time not work time for this. Alternatively I'm happy to leave this open long term if you'd like. Whatever is best for your project management.

[Zollerboy1]

interestingly the new Subprocess proposal from the Swift team does not run into this issue: https://github.com/iCharlesHu/Subprocess.

This is an even stronger hint that the issue lies somewhere in Foundation, as Subprocess doesn't use Foundation.Process but implements the subprocess forking using the low level C API instead.

To be honest, if I ever had some spare time, I would try to migrate this library to a custom subprocess implementation as well, because Foundation.Process is just a PITA, but for now it seems to work for most people.

I'll close this issue for now, feel free to open it up again, if you have some new insights impacting this library.