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