I decided to upgrade my development machine to MacOS Sequoia 15.0 last night and immediately noticed that my Vapor service would no longer start in (or outside) of Xcode. I am pretty sure this is related to the new Local Network Privacy (LNP) feature that was migrated from iOS to macOS with this release.
I did a search and did not seem to find this issue or a solution, yet I find it hard to believe I'm the only one who has encountered it. My service is created as a Swift package with a executable target. I am looking for a way to get my service running again in (and outside) of Xcode. Thanks!
A quick context. I have a Postgres server running on the local area network and the application in development in Xcode. The application has had no problem getting to the server until the upgrade.
The error is:
[ ERROR ] Opening new connection for pool failed: PSQLError(code: connectionError, underlying: NIOPosix.NIOConnectionError(host: "postgres.lan", port: 5432, dnsAError: nil, dnsAAAAError: nil, connectionErrors: [NIOPosix.SingleConnectionFailure(target: [IPv6]postgres.lan/xxx:xxx:xxxx::xxxx:5432, error: connect(descriptor:addr:size:): No route to host (errno: 65)), NIOPosix.SingleConnectionFailure(target: [IPv4]postgres.lan/xxx.xxx.xxx.xxxx:5432, error: connect(descriptor:addr:size:): No route to host (errno: 65))])) [database-id: psql]
nslookup from the terminal from the macOS machine works fine and returns the same IP addresses I removed from the error above. I am able to ping the machine and connect to it from TablePlus (for example).
I suppose that I should add that I tried putting a app.client.get call to an internal address to see if that might get the LNP permission prompt to show. It did not. I also added a call to URLSession.shared.data. Again nothing. They all failed in a similar way, but with different errors in the case of URLSession. Nothing I have tried results in the permission dialog being shown or the application having local area network access.
I will reply to myself here. After spending some time trying to work around this a variety of ways. The simplest solution I found, was to change the Run Scheme for the application to set "Debug process as" to root. It defaults to me.
If you run an executable as a launchd daemon, it runs as root and local network privacy does not apply to code running as root.
That made me consider how I could run the app as root, which led to the discovery of the setting in the scheme. I would prefer not to be running an executable as root, but right now I don't seem to have a better option.