Re: rcd(8) - new service manager daemon

Baptiste Daroussin <[email protected]> Mon, 15 Jun 2026 20:10:31 +0200
Newsgroups gmane.os.freebsd.devel.hackers
Message-ID <[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.

Best regards,
Bapt