Working from old rc scripts

The rc scripts used with the van Smoorenburg rc, Mewburn rc, OpenRC, and OpenBSD rc systems are a very rough guide to what the start, run, restart, and stop programs should do in a service bundle that you are writing yourself.

These systems are all written in general purpose scripting languages that can do anything, and there is no general process for converting scripts for such systems. The scope for wild variations exists and occurs with depressing regularity in the world. There are also three major sub-dialects of van Smoorenburg rc that rely upon blatantly (or, worse, subtly) different helper toolsets.

Converting a van Smoorenburg rc script is usually the least preferable option. More preferable options include converting the equivalent Mewburn rc or OpenBSD rc scripts, which factor out a lot of the chaff that van Smoorenburg rc scripts do longhand. Similarly more preferable is converting from a systemd service or socket unit and not working from an old rc script at all. It can be done with tools; and can be plumbed in to build procedures. As of 2017, the FreeBSD ports tree already has a couple of hundred ports (ranging from Puppet through iodine to Wildfly) that have systemd service and socket units in their distfiles that could be automatically converted by the port.

milestones

The standard targets are akin to the Solaris SMF milestones, including having distinct "server", "workstation", "static-networking", "users", and "multi-user" targets instead of one single target that mixes all five. Some other SMF non-milestone services have similar standard target equivalents: "system/filesystem/local" being equivalent to local-fs for example.

The Mewburn rc system has some milestones that do not really correspond well; in part because this package's standard targets are intended to promote more parallelism than mewburn rc. A rough guide for converting from Mewburn rc is:

FILESYSTEMS

BEFORE FILESYSTEMS does not occur out of the box in BSDs but would be equivalent to before/ the local-fs-pre target. REQUIRES FILESYSTEMS is equivalent to wants/ and after/ the local-fs standard target.

SERVERS

This is rarely used out of the box in BSDs. BEFORE SERVERS usually means being wanted-by/ one of the workstation, server, or sysinit standard targets. There's little distinction in practice beween REQUIRES SERVERS and REQUIRES DAEMON; with how to convert the latter usually also applying to the former.

DAEMON

A service that REQUIRES DAEMON usually simply wants/ the basic standard target and is stopped-by/ the shutdown standard target. However basic is not an ordering milestone. On the gripping hand, a service that is BEFORE DAEMON is usually actually expressing the notion that it is wanted-by/ a standard target within basic such as sysinit.

NETWORKING

The idea of "networking" is a very woolly one that doesn't really admit of one single description. Rather than relate things to such an ill-defined milestone, relate them to the more specific things that they in reality relate to, such as a default route becoming available, static networking being initialized, individual interfaces coming up, any interface heving carrier, or all networking interfaces having carrier.

LOGIN

This is somewhat woolly, like NETWORKING. Deferring things until "after the system is secure" should be done by ordering them with respect to services such as securelevel if it should be done at all. Moreover, the fact that "login services" are held off until the system has waited for pretty much everything else to finish, including services that take a long time to initialize but that would not actually prohibit log-on, is a significant problem with the very idea of this ordering milestone.

TTY login services order themselves after/ the multi-user-pre standard target. A very few services, that actually directly affect multi-user login (such as the production of the message of the day or setting the dynamic hostname) are ordered before this target, equivalent to BEFORE LOGIN. Most services should not be.