Re: rcd(8) - new service manager daemon

[2026-06-15 20:10] Baptiste Daroussin <[email protected]>
> On Mon 15 Jun 19:31, Philipp wrote:
> > [2026-06-15 08:47] Baptiste Daroussin <[email protected]>
> > > On Sun 14 Jun 16:15, Alan Somers wrote:
> > > > On Sun, Jun 14, 2026 at 1:26 PM Baptiste Daroussin <[email protected]> wrote:
> > > > > [...]
> > > > >
> > > > > Key features:
> > > > >
> > > > > [...]
> > > > >   - Socket activation (pre-bound sockets passed via fd inheritance)
> > > >
> > > > [...]
> > > > 
> > > > This sounds turboawesome.  Parallel boot, pdfork, procctl, and UCL, all sound
> > > > very exciting to me.  I can't wait to beta-test.  And
> > > > backwards-compatibility, too, is super good.  IIRC, the lack of
> > > > backwards-compatibility is why the NextBSD experiment failed.  Since
> > > > you're the expert, could you tell us how else this rcd differs from
> > > > NextBSD/launchd?
> > >
> > > TL;DR rcd is less ambitious and fully design for FreeBSD (and probably FreeBSD
> > > only).
> > >
> > > launchd replaces cron(8) and inetd(8): it handles periodic jobs (StartInterval,
> > > StartCalendarInterval) and socket-activated services (inetdCompatibility,
> > > Sockets).  rcd focuses solely on service management and does not attempt to
> > > replace cron or inetd. In the future, tighter integration with cron and inetd
> > > (similar to Solaris SMF) could be considered, but this is not planned today.
> > 
> > I'm a bit confused about this statement. Because socket activation
> > sounds for me like a replacement for inetd. Of course not a drop in
> > replacement and it only works when the service supports it.
> > 
> > It is already possible to either listen direct on a socket or use
> > inetd. What is the benefit of socket activation? In general wouldn't
> > it be better to add socket activation to inetd or an inetd replacement?
> > 
>
> 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.

I don't understand this argument. inetd listen on the socket and on
a connection it passes it to stdin/stdout of fresh programm. For me it
sounds like it would be a good match to add a way to pass the connection
via fd inheritance. Yes socket activation and (current) inetd have
a different interface to the service but do more or less the same:
Wait for connections and pass them to a service. So why having socket
activation in rcd but not a classic inetd interface? Or the other way
around: Why having the classic inetd interface in inetd but not socket
activation?

You mentioned that socket activation is for "heavyweight daemon while
guaranteeing port availability". Can you explain this a bit more or
give a concrete example for a service? On first look this sounds like
a nice to have feature but the more I think about it, the less benefits
I see.

For high availibility I would prefere that the service itself manage the
socket and connection, because then it might move connections to in which
are partial handled to another instance or even (with firewall support)
to another server.

For servers which have a long startup time socket activation would only
add a delay during startup for connections. When a service would like to
have this, it would be quite simple to implement: bind early and run
a thread accepting all connections. But the delay would (imho) lead to
bad user expirience during startup and maybe to timeouts. An alternativ
would be to accept early but send an application error (i.e. http 503).
But with this aproach the socket activation doesn't help, because the
service would need to accept during the startup. Or go the simple way
and bind after the startup. Then the port is closed a bit longer. But
when port availibilty is a problem then you better look at some sort of
high availibity, because a reboot also cause the port to be closed.

Some other feature might come in mind is binding to priviled ports, but
there is already mac_portacl(4) which is imho the better solution for
this problem.

I just want to understand what the gain of this feature is and in which
situation it would be a option to consider.

Philipp