Quick shoutout to this paper on the OpenBSD
rc.d system from 2016. I chanced upon it while trying to read up on the
rc.d system and it was a pleasure. :) It’s very clearly written with a lot of fun stuff sprinkled over …
This is a good one – on the difference between a daemon and a service. I like how they clarified that right off the bat and how
rc.d only manages daemons. Simple!
…it is needed to understand and differentiate the concept of daemon and service. A daemon is just your usual evil program configured to run in the background (e.g. sshd, ntpd) while a service is a “facility” (e.g. pf, ipsec, check_quotas); rc.d only handles daemons
FreeBSD and NetBSD rc.d and rcorder could have been the obvious choice but again, they provided too much. The rc.d scripts are also too flexible (which can be a feature but not in our case) and the framework provides a dependency-based dynamic start-up ordering which was against our goals because we wanted tokeep full control over the start-up sequence. It is our opinion that automatic determination of daemon start-up is pointless because if a machine is running a very large number of services in production, that’s a bad system design in the first place and it’s easier to order a small number by hand than to debug issues with automatic ordering.
The first rule we enforced upon ourselves was to use the already available and standard facility for signaling daemons: kill(1). The use of PID files was discarded for the usual reasons (racy, left-over files…). We knew it would not be enough for everything out there (some daemons require a helper to cleanly shutdown…) but it was good enough that we could make it a default. That’s the reason why something like start-stop-daemon(8) to control creation and termination of the daemon processes was not considered. Since the whole rc framework was just a bunch of shell scripts, extending it meant that we had to keep using shell, for better or worse.