asyncio.start_unix_server maybe shouldn’t default to cleanup_socket=True when sock parameter is passed

[Hawk777]

Bug report

Bug description:

When asyncio.start_unix_server is called and the sock parameter is passed (rather than path), a server is wrapped around an existing socket. In this case, the fact that cleanup_socket defaults to True 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 a different 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 server may not even have filesystem permission to see the socket—after all, only clients should need that. Then the os.stat call in create_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 implementation start_unix_server takes arbitrary kwargs and forwards them to create_unix_server, but the documentation instead mentions each parameter explicitly and doesn’t mention cleanup_socket at all.

CPython versions tested on:

3.13

Operating systems tested on:

Linux

[dmitrin9]

Hey, I can take this issue.

Before creating a PR though, I'd want to confirm whether this was intended or not, because it seems like something that was intentional.

[Hawk777]

Doing cleanup by default when path is passed is a change in behaviour too, but it seems like a good idea IMO (in that case the server is responsible for creating the socket so it’s logical it should also be responsible for deleting it). Only when sock is passed does it seem like it probably shouldn’t be done by default.

[Hawk777]

Agreed that getting an opinion, ideally from whoever made the change initially, would be good.

[dmitrin9]

Haha yea I was searching the github PRs tab, grepping, listing via gh-cli, and I genuinely couldn't find it. I was able to narrow it down to before python 3.13 and after python 3.12.

Is there a standardized way to find who initially made a change?

[Hawk777]

git log -p, git log -G, and git blame can all help. In this case git log -p -G cleanup_socket quickly revealed that the parameter and the code behind it were added in 74b868f, which mentions gh-111246 and gh-111483.

[Hawk777]

The discussion there mentions the use of the sock parameter, but only in the sense of “it’s harder to get the name if someone uses that, but hey we can use getsockname”; I don’t see any discussion of the idea that maybe it shouldn’t be removed at all in that case.

[Hawk777]

@CendioOssman perhaps you have some thoughts on this, as the author of the original change?

[Hawk777]

(Side note, if you want to get the inode number for the listening socket, why are you doing getsockname plus stat rather than fstat, or, equivalently, stat on the descriptor rather than the name? That would fix a race if some other process replaces the socket after you bind but before you stat.)

[CendioOssman]

The idea was that since this creates a server object, it implies a great deal of ownership. E.g. accepting and creating new sockets.

Secondly, removing all traces of the socket when it is closed is how most sockets behave, except for Unix sockets.

Hence, having the cleanup be enabled by default seemed like the most useful and least surprising option.

Admittedly, systemd socket activation was not considered.

[CendioOssman]

(Side note, if you want to get the inode number for the listening socket, why are you doing getsockname plus stat rather than fstat, or, equivalently, stat on the descriptor rather than the name? That would fix a race if some other process replaces the socket after you bind but before you stat.)

I seem to recall that the socket's inode number was from the magical socket file system, and not from the file on disk. So this is a race, yes, but no alternative was found.