Re: rcd(8) - new service manager daemon

Monday, June 15, 2026, 11:52:32 AM, you wrote:

> Baptiste Daroussin <[email protected]> writes:
>> - 2 (later): Commit init(8) changes to call rcd when present (falling
>>   back to /etc/rc otherwise).  Provide a /etc/rc wrapper that invokes
>>   rcd for systems that want to switch.

> I think that ultimately rcd should _be_ init, and should support
> systemd-style services (where the service doesn't daemonize and logs to
> stderr).  I haven't looked at the code, but I suspect that very little
> is missing to make that possible: rcd needs to be prepared to reap
> processes it didn't fork, and it needs to be able to read /etc/ttys and
> manage ttys (which aren't much different from any other service).

I'm an expert of loosing (remote) control over production servers due to FreeBSD startup caveats.
The most shame that technically there was no problem to get sshd up and runing but rc sequence bring server to singleuser. The server leaved alone somewhere with only (disconnected) physical console available for interaction.

There is a need to be aware that 'require' and other things in rc scripts obviously insufficient to ensure that services started up "as good as it can" in the current case.  Each boot of a system  really a separate case. 
Some problems during boot that affect startup sequence:
- DNS not responding/available;
- errors on some disk partitions;
- some geom module hangs;
- no space  left on some partition;
- some network servers (LDAP for example) not responding;
- some changes in a network interfaces.
etc.

All those things affect "fail" of startup bringing server out of order. While strictly technically they only constrain a functionality of a server.

"rcd should _be_ init" seems to me as a shrink of a gap between kernel initialization and rc startup fail.


P.S. Startup inside a jail is a very different proposition.

-- 
Best regards,
Anthony Pankov