Re: rcd(8) - new service manager daemon

Cy Schubert <[email protected]> Mon, 15 Jun 2026 18:10:01 -0700
Newsgroups gmane.os.freebsd.devel.hackers
Message-ID <[email protected]>
In message <[email protected]>, Baptiste Daroussin writes:
> On Mon 15 Jun 10:23, Juraj Lutter wrote:
> > Hi,
> > 
> > in the beginning: It’s truly a great work that you’ve done!
> > 
> > > On 15. Jun 2026, at 08:47, Baptiste Daroussin <[email protected]> wrote:
> > > 
> > > On Sun 14 Jun 16:15, Alan Somers wrote:
> > >> On Sun, Jun 14, 2026 at 1:26 PM Baptiste Daroussin <[email protected]> 
> wrote:
> > >>> 
> > >>> Hello everyone
> > >>> 
> > >>> I have been working for the past years on rcd(8), a new service manager
> > >>> daemon for FreeBSD, some of you might recall a presentation in french 1
> 5
> > >>> years ago or some discussion in BSDcam also that old!
> > >>> I would like to start a discussion about its integration into the tree.
> > >>> 
> > 
> > 
> > Speaking of ports: What is your imagination that the new rcd should be plug
> ged into ports?
> > 
> > Like, once committed into base, should ports remain with “traditional” 
> rc.d files until
> > the rcd is the default and then switch to UCL files? Or are there any plans
>  to introduce
> > any “parallel” mechanisms to deliver UCL an rc.d files? If yes, will th
> ere be any preference
> > of UCL over rc.d?
> > 
> > Sorry for too many questions :-)
>
> We could deliver both, if a rc.d script has keyword NORCD, then it will be
> ignored by rcd, so the .ucl file would be the only one used.

Sun delivered services similar the proposal here. svcd(8) was/is a child of 
init(8). It's been a couple of decades since I worked on Solaris but IIRC 
both did coexist.

I think the approach taken here is more elegant than that of Sun's/Oracle's 
svcd and friends and certainly easier to work with than systemd and it's 
unit files, some of which located in semi-documented locations.

Users who wish to update the FreeBSD provided rc scripts/UCL would need to 
place theirs in some alternate location, though this is an advantage it 
also disadvantages the user when incompatible updates are applied. 
(Probably premature for this discussion.)

This is certainly a welcome development.



>
> Best regards,
> Bapt
>


-- 
Cheers,
Cy Schubert <[email protected]>
FreeBSD UNIX:  <[email protected]>   Web:  https://FreeBSD.org
NTP:           <[email protected]>    Web:  https://nwtime.org

			e**(i*pi)+1=0