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:

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.