Re: rcd(8) - new service manager daemon

On 15 Jun 2026, at 19:10, Baptiste Daroussin <[email protected]> wrote:
> 
> Adding socket activation to inetd wouldn't make sense (imho). they're opposite models.
> inetd multiplexes connections to lightweight programs; socket activation defers
> startup of a heavyweight daemon while guaranteeing port availability. They
> complement each other.

There may be some terminology problems here, because inetd can do socket activation, it just doesn’t follow the protocol that systemd uses. The ‘nowait’ model in inetd is quite similar to (and the direct ancestor of) both launchd and systemd’s notion of socket activation.

The protocol used by systemd is quite nice, it lets you inherit the *listening* socket while also retaining ownership of it, so the child process can handle as many connections as it wants, exit based on its own policy, and be restarted in a race-free way without losing connection attempts. The lack of support for this is a problem for FreeBSD because things like Docker storage daemons depend on it. I have patched the ZFS one to manage connections itself, but this means I have a process using 10-15 MiB of RAM to handle events that happen every few weeks at most. I normally stop and start the service manually before managing volumes, but that’s annoying. With rcd, I can just use the unmodified upstream version.

I haven’t yet had a look at the code, but the design sounds almost exactly what I want. The one question I didn’t see addressed was how you integrate other event sources?  For example, restarting (or SIGHUPing) a service when a network appears, running a backup when a specific external disk is mounted, running a service when I’m on my home network, and so on? These are currently devd events, but devd.conf is clunky (things like filesystems appearing are two events and you need some stateful tracking if you want to know both the device node and the volume name) and doesn’t integrate with the rest of the rc system.

I’d also like a bit of clarity on the future of UCL before it’s adopted more in the base system. I wrote some tooling to generate C++ headers from UCL schemas that expose typed UCL data structures a while ago, but the code in UCL did not inspire confidence. There were a number of security vulnerabilities found around then and there were a number of issues, the ones I remember were:

 - It supports SI suffixes, but uses a b suffix for the binary ones not the standard i.
 - It doesn’t support things like times or durations as first-class types.
 - Similarly, paths and URLs are just strings.
 - The grammar does not have a formal definition.
 - There is no test suite independent of the implementation.

The attempts at interoperable parsers for the format have failed due to the last two. It’s possible to fall back to using JSON for interoperability, but JSON requires more high-level types to be encoded as strings and that just pushes the interoperability problem elsewhere. In contrast, TOML, which systemd uses, has multiple interoperable implementations. Apple’s PKL has first-class support for durations and bindings to several languages. UCL doesn’t seem to be more widely adopted than when we discussed it almost 15 years ago and the one implementation is a big pile of C that is optimised for parsing performance, not security (or readability).

David