Re: [PATCH 1/3] tools/router: use socket activation

Demi Marie Obenour
2025-12-09T11:25:18Z

[-- Attachment #1.1.1: Type: text/plain, Size: 2098 bytes --]

On 12/9/25 06:04, Alyssa Ross wrote:
> Alyssa Ross <hi@alyssa.is> writes:
>
>> Demi Marie Obenour <demiobenour@gmail.com> writes:
>>
>>> On 12/9/25 05:55, Alyssa Ross wrote:
>>>> Demi Marie Obenour <demiobenour@gmail.com> writes:
>>>>
>>>>> On 12/8/25 19:38, Alyssa Ross wrote:
>>>>>> This means we can use readiness notification to wait until the sockets
>>>>>> are created without having to add special functionality for that to
>>>>>> the router program, and also means we can do extra system-specific
>>>>>> setup to the sockets, like changing their owners, outside of the
>>>>>> router.
>>>>>>
>>>>>> Since the socket paths were the only arguments taken by the router,
>>>>>> this also lets us drop the clap dependency entirely.
>>>>>
>>>>> I strongly recommend open-coding the file descriptor stuff instead
>>>>> of using a third-party library for it. It's just a two calls to
>>>>> getsockopt() (SO_DOMAIN and SO_TYPE) per socket, and listenfd pulls
>>>>> in wasm-bindgen and js-sys!
>>>>
>>>> It pulls in wasm-bindgen and js-sys if you're building for those
>>>> platforms, which we are not. An inert mention in Cargo.lock is not a
>>>> problem. The only dependency of listenfd in our context (checked via
>>>> cargo tree) is on libc, which is already a dependency of tokio.
>>>>
>>>> I've implemented systemd socket activation in Rust before, and it's not
>>>> at all nice, even with libsystemd. listenfd adds 295 extra lines of
>>>> code in total. I think that's worth it.
>>>
>>> Ah, I didn't mean to actually implement the whole thing, but rather
>>> to open-code the specific case used here.
>>>
>>> If listenfd is a very popular crate, I'd go with it. Otherwise,
>>> I'd be too concerned about supply-chain risk. On the other hand,
>>> I might be too used to having to use Fedora and Debian packages for
>>> my Rust dependencies.
>>
>> "#28 in Unix APIs", ahead of landlock and just behind libseccomp.
>
> (And also packaged by both Fedora and Debian.)

Go ahead and use it then!
--
Sincerely,
Demi Marie Obenour (she/her/hers)

[-- Attachment #1.1.2: OpenPGP public key --]
[-- Type: application/pgp-keys, Size: 7253 bytes --]

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]