Bug report

Bug description:

Whenasyncio.start_unix_server is called and thesock parameter is passed (rather thanpath), a server is wrapped around an existing socket. In this case, the fact thatcleanup_socket defaults toTrue is very weird and potentially broken: it means that asyncio will try to delete a socket that someone else created (either other code in the same process, or, in the case of e.g. systemd socket passing, a socket created by adifferent program).

This is problematic for a couple of reasons when using systemd socket passing:

• If the server succeeds at deleting the socket, it breaks socket activation. Socket activation means systemd creates the socket, and when the first connection arrives, it starts the server. The way it’s intended to work is that, if the server terminates, it leaves the socket in place, and systemd will start the server again if another connection comes in, allowing virtually seamless service restarts. If the server deletes the listening socket, this breaks.
• If systemd passes the listening socket to the server, the servermay not even have filesystem permission to see the socket—after all, only clients should need that. Then theos.stat call increate_unix_server blows up.

So this is definitely a nontrivial backwards compatibility break from 3.12 (which didn’t have cleanup logic at all and didn’t have the parameter) to 3.13, despite not being mentioned in the release notes. It also seems like a bit of a footgun in general, not to mention the fact that in implementationstart_unix_server takes arbitrary kwargs and forwards them tocreate_unix_server, butthe documentation instead mentions each parameter explicitly and doesn’t mentioncleanup_socket at all.

CPython versions tested on:

3.13

Operating systems tested on:

Linux