Working from old rc scripts

# 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.