rcd(8) - new service manager daemon

Beastie7

Beastie7

For those who might've missed the big news on the mailing list - I decided to post it here.

Looks like the creator of pkg and poudriere (Baptiste Daroussin) has been brewing up a new modern service manager daemon for FreeBSD. From what I can tell; it's functionally similar to SMF but relies on FreeBSD features/interfaces instead of mangling the kernel.

From the original post;
Key features:

- Parallel boot via dependency DAG (no more serial rc.d execution)
- Process tracking via pdfork(2) descriptors (no PID file races)
- Subreaper via procctl(2) (no orphaned process escape)
- Socket activation (pre-bound sockets passed via fd inheritance)
- Resource control per service via rctl(2)
- Service isolation via native jail(2) integration
- OOM protection via procctl(2) PROC_SPROTECT
- UCL-based unit files (JSON Schema validated)
- Embedded Lua interpreter for inline service hooks
- Template units for per-instance services (e.g., dhclient@em0)
- Safe in-place binary upgrade (SIGUSR1: save state, re-exec)
- Per-service access control on the control socket
- Suspend/resume support
Click to expand...

I'm really excited to try this out. Particularly it's UCL based unit files, and native jail integration (ie. Zone SMF Instances). I wonder how the unit files will be stored; in some sort of repository or in the base system path?

And most importantly... it's NOT replacing init! (I'm looking at YOU systemd)
 
lanin said:
The ideas of Solaris from the turn of the century (zfs, zones, smf...) remain an inexhaustible source of inspiration for FreeBSD....and there is nothing wrong with that. :-/
Click to expand...

Well...

and vice versa; Jails inspired Zones, kqueue inspired Event Ports to name a couple.

Also, as a reminder. The creator of BSD UNIX was a co-founder of SUN. :) But I digress.

I'm just glad FreeBSD is finally adopting something like SMF manifests. It's way more consistent and streamlined than a bunch of scripts - although backwards compatible with legacy rc.d scripts.
 
if it's basically a wrapper around init/rc, jails and some other standard tools I'm all ears.
But if it replaces and heavily interferes with sane and working parts of the base system, especially init and rc-scripts, so you always have to wade through layers of abstractions, then I'm not interested (I.e. I will even make an effort to keep it out of any system I run)
 
siladi said:
So actually (😄) rcd is a Very Good Thing. Get educated here: rcd(8): modern service manager the FreeBSD way
Click to expand...
Thanks, I'll definitely watch that presentation later. But this description already sounds like it might become a good thing:
It leverages all native features of FreeBSD: process descriptors, jails, resource management, cpuset, kqueue, and process reaper.
Click to expand...

If it also brings an equivalent of OpenBSD rcctl's 'ls' command ( rcctl ls failed/started/stopped/...) and stays out of your way if you dont need it, I'll give it a go. (But I'll stay sceptical for now - just so I can't be disappointed...)
 
sko said:
Thanks, I'll definitely watch that presentation later. But this description already sounds like it might become a good thing:


If it also brings an equivalent of OpenBSD rcctl's 'ls' command ( rcctl ls failed/started/stopped/...) and stays out of your way if you dont need it, I'll give it a go. (But I'll stay sceptical for now - just so I can't be disappointed...)
Click to expand...
At least, the one abandoned on review was NOT to fully replace current rc framework (if I recall correctly, current one is rcNG from the time it start to support rc.d and service(8)) and works in parrarrel with current rc framework.
And its config files are UCL-based, NOT in binary form, thus, readable.
 
sko said:
if it's basically a wrapper around init/rc, jails and some other standard tools I'm all ears.
But if it replaces and heavily interferes with sane and working parts of the base system, especially init and rc-scripts, so you always have to wade through layers of abstractions, then I'm not interested (I.e. I will even make an effort to keep it out of any system I run)
Click to expand...

The presentation goes more in depth on the implementation. It’s practically SMF done the FreeBSD way. With full backwards compatibility with classic rc.d scripts.

rcd is awesome. Service instances are going to be a breeze for many different use cases.
 
I watched the talk yesterday and peeked at some of the code.
First things first: it is *somewhat* replacing rcNG, e.g. because it uses its own unit files for services - *if* you want to specifically want that service to be a native rcd service. However, it is fully backwards compatible in that a) it is (and will always be as I understood) started from init, so it's not replacing it, and b) it completely ingests rc.conf and all rc.d scripts and runs them as legacy services (i.e. it will just run the script just as rcNG does). It might be even possible to have a unit file AND a classic rc.d file in place so you can boot with rcd enabled or via rcNG, or rcd can use the rc.d file as a fallback. Also core rcNG parts like the .subr scripts will remain in place, which I highly anticipate (they work and they work very reliably - no need to replace anything here or reinvent the wheel).
I really hope rcd won't suffer from feature creep and seep into many other aspects of the boot process (or worse), because as outlined in the talk it might really be a nice addition/complement to rcNG. And even if the lingo of the talk was to one day replacing rcNG, I don't see why we couldn't keeping it completely optional. For a small, slim system where you don't need any service supervision, no jails and no daemon resource/permission restrictions, just stay with rcNG and if you want/need more control over services or use some of the extra features, just enable rcd.

The fact that it exclusively uses existing tools and mechanisms is great and IMHO that's the only way something like that should be done. If it were pure shell scripts I would be even more happy, but Lua it is... (could be way worse - like python with a sh*t-ton of dependencies and json everywhere...)
 
sko said:
The fact that it exclusively uses existing tools and mechanisms is great and IMHO that's the only way something like that should be done.
Click to expand...
This is a very important point. TrueOS when it was alive and FreeBSD based was using OpenRC. No problem with that decision, there are other distributions using it, it's reasonably well tested.
The downside is every single unit file had to be touched/rewritten. If you only think about the base system, not such a big deal BUT you need to see how many ports provide unit files. I don't know the count, but quick "ls /usr/local/etc/rc.d | wc -l" gives me 24 on my system. Granted not all are actually in use (openntpd, webcamd actually used) but if rcd mandated new files, every port would have to be touched before releasing rcd, port maintainers would need to carry both versions for a while and choose the file based on what version it's being built for. That inflates amount of work by the maintainer and inflates the amount of stuff in git repos.

I think rcd having a new format while maintaining backwards comaptibility is key to getting it adopted.
 
mer said:
This is a very important point. TrueOS when it was alive and FreeBSD based was using OpenRC. No problem with that decision, there are other distributions using it, it's reasonably well tested.
The downside is every single unit file had to be touched/rewritten. If you only think about the base system, not such a big deal BUT you need to see how many ports provide unit files.
Click to expand...
I once looked after 3-4 TrueOS installations @family/friends. Their DE and tools were quite nice for non-technical people, so it was a viable solution back then.
I even had a fleet of ~10 TrueOS clients running at work to evaluate it as a replacement for bare-metal Windows; with full automated deployment, central user management, nfs-mounted user profiles and a unified, 'immutable' windows-VM that was maintained/updated via zfs send|recv'd snapshots. TrueOS was only chosen because it covered all the GUI stuff OOTB I didn't wan't to deal with back then.
But OpenRC and its unit files were the cause of many problems back then and I had to fight various race conditions and edge cases that simply weren't covered by the provided unit files. I upstreamed most of my patches, but TrueOS development pretty much stalled at that time and it was quickly obvious that iXsystems was done milking BSD and would drop it.
At one point I even was ~80% done replacing OpenRC with rcNG, but since all the UI management tools relied on OpenRC in the background (and I didn't want to touch those), it just wasn't sensible to follow down that rabbit hole any further and just move to vanilla FreeBSD and so many things became much saner (although the TrueOS installer back then was very easiy to instrument for automated/unattended deployment).

So yes, I had my fair share of dealing with init/rc related problems and the rcd approach IMHO is really the only sensible way of not breaking anything while still introducing new features.
 
You must log in or register to reply here.
Back
Top