Managing time synchronisation with NTP and ntpdate
Accurate time is an operating-system responsibility, not a cosmetic setting. Clock drift disrupts log correlation, TLS certificate validation, password expiry and scheduled jobs. Local applications in Sydney and Melbourne also need consistent handling of daylight-saving changes.
Network Time Protocol (NTP) keeps hosts aligned with UTC. The traditional ntpd daemon adjusts the clock gradually, while ntpdate performs a one-shot correction. Modern RHEL releases usually favour chronyd, and lightweight Debian-based systems often use systemd-timesyncd.
Why clock accuracy matters operationally
A host with the wrong time can reject valid credentials, renew certificates at the wrong moment and place events in the wrong order. This becomes expensive during incident response, when investigators compare application, firewall and authentication logs.
For teams maintaining Nginx reverse proxy setups, trustworthy timestamps simplify certificate checks and request tracing. Set time zones separately from synchronisation, and monitor clock offsets instead of discovering errors through failed logins.
Choosing a time service for your distribution
RHEL 8 and 9 ship with chronyd, and Fedora follows the same modern approach. Australia’s hosting market also mixes CentOS Stream, AlmaLinux and Rocky Linux, so check the service and package names on each image instead of assuming every CentOS-derived host behaves identically.
RHEL 7 and older estates may still use ntpd from the ntp package. Ubuntu and Debian commonly provide systemd-timesyncd; on those systems, sudo timedatectl set-ntp true enables time synchronisation and timedatectl status confirms the active client.
Installing and configuring NTP safely
For a legacy ntpd installation, a minimal /etc/ntp.conf can point to Australian and international peers. The iburst option sends several packets at startup, shortening initial acquisition time.
server au.pool.ntp.org iburst
server time.cloudflare.com iburst
driftfile /var/lib/ntp/ntp.drift
On chronyd, place the same server directives in /etc/chrony.conf; its usual drift file is /var/lib/chrony/drift. Then install and start the appropriate daemon:
sudo dnf install chrony
sudo systemctl enable --now chronyd
chronyc sources -v
Use yum install ntp and systemctl enable --now ntpd on an older RHEL host. Check peer state with ntpq -p for ntpd or chronyc tracking for chronyd, and ensure only one synchronisation daemon controls the clock.
Comparing the main synchronisation options
Choose a daemon that matches the distribution and its monitoring tools. Use the one-shot client for diagnosis or controlled recovery, not as a substitute for continuous correction.
| Approach | Best suited to | Key commands | Main limitation |
|---|---|---|---|
ntpd |
Legacy RHEL and CentOS systems | ntpq -p |
Superseded by chronyd in current RHEL |
chronyd |
Current RHEL, Fedora and precision-sensitive servers | chronyc tracking, chronyc sources -v |
Separate chrony-specific tooling |
systemd-timesyncd |
Simple Ubuntu, Debian and container hosts | timedatectl status |
Limited peer detail and no local server |
ntpdate |
One-off checks or recovery on legacy systems | ntpdate -q -v au.pool.ntp.org |
Deprecated or removed; clock steps can disrupt services |
Never schedule ntpdate to step a production clock repeatedly. A sudden backward adjustment can confuse running applications, while continuous daemons can track peer quality and oscillator drift.
Coping with outages and remote sites
Field installations in the Pilbara or near Kalgoorlie can depend on intermittent satellite links. When upstream servers become unreachable, let the local oscillator maintain time between successful peer updates, review peer status after reconnection and limit makestep to controlled startup rather than surprise jumps.
In Australian operations chat, an arvo check or a quick have a squiz is a useful prompt to inspect the service. For staff who also maintain Android-based devices, the Android system tutorials provide useful platform background, but handsets should consume network time rather than act as trusted peers.
A dependable routine for Linux administrators
Use a repeatable inspection routine so silent failures do not become visible outages.
- Identify the active client with
timedatectl statusand inspect the relevant systemd unit. - Check reachable peers using
chronyc sources -vorntpq -p; a running process alone proves little. - Track offset and frequency drift with
chronyc tracking, and alert on sustained errors. - Keep
ntpd,chronydandsystemd-timesyncdfrom competing on the same host. - Review service logs after network changes and investigate every unexpected clock step.
- Verify certificate checks, cron schedules, log rotation and database timestamps after maintenance.
Record the chosen peer set, expected offsets and recovery procedure in the host documentation.
Time discipline that outlasts the server
Clock accuracy belongs in the same operational routine as patching, backups and certificate renewal. Document the daemon, configuration path, upstream sources and acceptable offset, then monitor each host so loss of synchronisation is detected before authentication fails.
The lesson to remember is to maintain one continuous time service, verify both peer selection and measured offset, and treat unexplained clock jumps as significant incidents. Trustworthy timestamps make logs, certificates and scheduled work dependable.