sntpclock, taiclock, and fake-hwclock services

# The `sntpclock`, `taiclock`, `taiclockd`, and `fake-hwclock` services

The Bernstein `sntpclock`, `taiclock`, and `taiclockd` tools from clockspeed can be run as services. These provide a much simpler alternative for keeping a system's clock accurate, to `ntpd` or even to the likes of `chrony`. The `fake-hwclock` service is an augmentation for use on systems without an actual hardware clock chip, that can be used in conjunction.

## Synchcronizing to external clocks

The `sntpclock` and `taiclock` service bundles are mutually exclusive and are ordered to be brought up after the `persistent-clock-loaded` standard target and before the `system-time-synchronized` one. (See the `service-bundle` manual page.) This system is intentionally a simple one that is simpler than the systems that synchronize to multiple external time sources. Only one time source, SNTP or TAICLOCK, can be used with these services at any given point.

By default these two services look for time servers on the anycast IP address 224.0.1.1. This usually is not present on small-office/home-office networks. So the service bundles can be hand-configured in the conventional ways with substitute IP addresses in an `IPADDR` envirment variable stored in an environment variable directory in the conventional place for a service. This variable can be accessed and modified in the conventional ways:

-     rcctl set sntpclock IPADDR 203.0.113.123

-     system-control print-service-env sntpclock IPADDR

The `sntpclock` and `taiclock` services synchronize once per day. To see how they will synchronize at the next run, you can simulate the service environment but with `clockview` instead of `clockadd` at the end of the pipeline. For example:

>     envdir "`system-control find sntpclock`/service/env" pipe --inwards sh -c 'sntpclock "${IPADDR:-224.0.1.1}"' \| clockview

## Providing an external clock to other systems

The `taiclockd` just serves the current time to other systems via the TAICLOCK protocol, and does not conflict with any of these other services.

For each of the network addresses listed as `taiclockd_network_addresses` in `/etc/rc.conf` the external formats import subsystem generates a `taiclockd@`address service. If is no network address setting, it generates `taiclockd@::0`, serving time to the world. (To not set up any such taiclockd services at all, the `taiclockd_network_addresses` setting must exist and be blank.)

Note: This requires the improved Bernstein `taiclockd` tools from the djbwares toolset, which can speak TAICLOCK over IPv4. The original Bernstein `taiclockd` (retained in the djbwares toolset as `taiclock4d`) only speaks IPv4. The improved `taiclockd` works with combined IPv6-and-IPv4 network stacks, and can serve both IPv6 and IPv4 clients.

## Retaining the date and time over system restarts

The `fake-hwclock` service simply persists a clock value across system shutdown and reboot. It does this by simple dint of regularly recording the system clock into a file at approximately hourly intervals whilst the system is running, and updating the system clock from the value in the file (but only if that means adjusting it forwards) in the system startup before the `persistent-clock-loaded` standard target becomes ready.

It does not require any additional toolsets, as it is a very basic implementation of the mechanism using a shell script and the standard `date` command. It is designed for systems that have no persistent, battery-powered, clock of their own. It can be run on systems that do have such hardware, but it will just log errors about the system clock being ahead of its last persisted value (which will be the case because actual battery-powered clock hardware "ticks" forward when the system is powered off).

TianoCore EFI firmware provides a similar kind of mechanism, which operating systems such as NetBSD will pick up automatically as their "hardware clock"; but its persistent clock, which it stores in a file in the EFI System Partition, does not "tick" whilst the operating system is running, only when the EFI firmware is in "boot services" mode. This can result in TianoCore's fake clock becoming weeks, months, or even years behind; which usually causes a warning message at boot time as operating systems sanity-check hardware clock values (against, ironically, datestamps on the root filesystem). Whilst `fake-hwclock` does not actually "tick" per se, its persistent clock value does get updated and will not (after a system restart) lag the actual time by such extreme amounts if a system happens to remain up for a long time.