How to synchronize the time of AIX server from the time server

— ny_wk

To synchronize the time on an AIX server with a network time server, first confirm the upstream NTP source is reachable with ntpdate -d, perform a one-time step with ntpdate, then configure the persistent xntpd daemon in /etc/ntp.conf and start it so the clock stays disciplined automatically. This guide walks through every step on IBM AIX, explains the diagnostic output, covers the common pitfalls, and notes the modern equivalent for AIX 7.x and later.

Accurate time is not optional on an AIX system. Kerberos and Active Directory authentication, TLS certificate validation, database transaction ordering, log correlation across hosts, and clustered services (PowerHA, GPFS) all break or behave unpredictably when clocks drift. The Network Time Protocol (NTP) keeps the system clock locked to an authoritative reference, and on AIX the long-standing client is the xntpd daemon paired with the ntpdate one-shot utility.

Prerequisites before you synchronize AIX time

Before touching the clock, gather a few facts. A rushed time jump on a production server can corrupt time-sensitive workloads, so plan it like any other change.

Root access to the AIX host (or a user with the right RBAC role).
The hostname or IP address of one or more reachable NTP servers. In many enterprises these sit behind friendly aliases (for example scctime and bcctime) that resolve to the real time hosts.
UDP port 123 open end to end. NTP uses UDP/123 in both directions; a firewall that blocks it is the single most common cause of failure.
The bos.net.tcp.client fileset installed, which provides xntpd, ntpdate, and ntpq on AIX.

If your time servers are published under DNS aliases, resolve them first so you know the actual IP you are dialing. From any client you can confirm the alias chain:

nslookup scctime
nslookup bcctime

An alias such as scctime may resolve through a CNAME (for example ntp-sprap1) to an IP like 10.33.37.19, while bcctime points to a second, geographically separate server such as 10.225.227.57. Keeping a primary and a secondary source is good practice: if one site is unreachable, the daemon falls back to the other.

Step 1: Verify the time server is suitable for synchronization

Never synchronize blindly. Run ntpdate in debug mode (-d) first. Debug mode queries the server and reports what it would do without actually changing the clock, which makes it the safest possible test.

Check the current system clock so you have a baseline:
```
date
```
Probe the primary time server in debug mode:
```
ntpdate -d 10.33.37.19
```
Probe the secondary time server the same way:
```
ntpdate -d 10.225.227.57
```

A healthy server returns a block of timing data. The fields that matter most are highlighted below.

Field	What it tells you
`stratum 1`	Distance from the reference clock. Stratum 1 means the server is directly attached to a reference (here, `refid [GPS]`). Lower is better; stratum 16 means unsynchronized.
`refid [GPS]`	The reference source. `GPS` indicates a satellite-disciplined clock — an authoritative source.
`delay`	Round-trip network delay in seconds. A small, stable value (for example 0.028) signals a clean path.
`offset`	How far your clock is from the server. A large offset (for example 396.6 seconds) means your AIX clock is badly out of sync and needs correcting.

In a real out-of-sync scenario the probe reported offset 396.611321 — the AIX clock was over six minutes behind the GPS-backed source. That is exactly the kind of drift NTP exists to fix.

A bad or unreachable server looks very different. Watch for these warning signs:

stratum 0 with refid [0.0.0.0] and a huge dispersion (for example 61.0) — the server has nothing useful to offer.
A reference time showing an absurd date such as Feb 7 2036 (the all-zeros NTP timestamp) — the server never actually responded with real data.
The fatal message: no server suitable for synchronization found.

If you see that last message, do not retry endlessly. It almost always means UDP/123 is being blocked by a firewall, the time daemon on the server is down, or you are pointing at the wrong IP.

Step 2: Perform the one-time time synchronization on AIX

Once a server checks out, do a single immediate correction with ntpdate (no -d flag). This steps the clock right now so the daemon you start next has a sane starting point.

Note the time before:
```
date
```
Run the one-shot sync against the verified server:
```
ntpdate 10.33.37.19
```
Expect a line like step time server 10.33.37.19 offset 396.611147. The word step means the clock was jumped to the correct value.
Confirm the clock moved:
```
date
```
Re-run the debug probe to confirm the offset has collapsed to near zero:
```
ntpdate -d 10.33.37.19
```
Now you should see something like adjust time server 10.33.37.19 offset 0.000240. The word adjust (rather than step) and a tiny offset confirm the clock is already very close to correct.

Important: ntpdate alone is not a lasting fix. It corrects the clock once and exits. Without a running daemon, the hardware clock will slowly drift again. That is why Step 3 is mandatory for any server you care about.

Step 3: Configure and start the xntpd daemon

The xntpd daemon keeps the clock continuously disciplined — making small, gradual corrections rather than disruptive jumps. Configure it in /etc/ntp.conf.

Edit the configuration file:
```
vi /etc/ntp.conf
```
Define your server(s) and the drift/trace files. A minimal, working /etc/ntp.conf looks like this:
```
#broadcastclient
server 10.33.37.19
server 10.225.227.57
driftfile /etc/ntp.drift
tracefile /etc/ntp.trace
```
List more than one server line for redundancy. The driftfile lets the daemon remember your clock's natural frequency error across restarts so it re-converges quickly.
Start the daemon through the AIX System Resource Controller (SRC):
```
startsrc -s xntpd
```
You should see The xntpd Subsystem has been started. Subsystem PID is <pid>.

Database and production servers — read this. If the host runs a database (Oracle, Db2) or any workload that must never see time move backward, start the daemon with the -x flag. This tells xntpd to slew the clock (speed it up or slow it down gradually) instead of stepping it backward, which prevents the wall clock from ever jumping into the past:

startsrc -s xntpd -a "-x"

Finally, make the daemon survive a reboot. Uncomment the xntpd start line in /etc/rc.tcpip:

Edit the TCP/IP startup file:
```
vi /etc/rc.tcpip
```
Find and uncomment this line (remove the leading #), adding -x here too if you used it above:
```
start /usr/sbin/xntpd "$src_running" "-x"
```

With that line active, AIX restarts xntpd automatically every time the system boots.

Step 4: Verify the AIX client is synchronized

Starting the daemon is not the same as being synchronized. xntpd needs time to lock on. Verify the state with lssrc:

lssrc -ls xntpd

Read the output carefully. The fields that prove synchronization are:

Sys peer — should show the IP or name of your NTP server (for example 10.33.37.19). If it is blank or 0.0.0.0, the client has not locked on yet.
Sys stratum — should be your server's stratum plus one. Synchronizing to a stratum-1 server makes your AIX host stratum 2, which is the clearest sign it has accepted the source.
Leap indicator — 00 (No leap second today.) is the normal, healthy value.
Peer flags — the chosen server should be tagged (configured)(sys peer).

Confirm the subsystem itself is running, too:

lssrc -s xntpd

A Status of active means the daemon is up. Be patient: it can take up to about 12 minutes for xntpd to select a peer, fill its filter registers, and report a non-empty Sys peer. An empty Sys peer immediately after startup is normal, not a failure.

If you have the ntpq utility (it ships with the same fileset), the billboard view is the quickest health check:

ntpq -p

An asterisk (*) in the first column next to a server marks the currently selected peer; a plus (+) marks acceptable candidates. The reach column should climb toward 377 (octal for eight consecutive good polls).

Common pitfalls when synchronizing AIX time

Most NTP problems on AIX come down to a short list of recurring mistakes. Check these before opening a support case.

"No server suitable for synchronization found." This is a connectivity problem 90% of the time. Confirm UDP/123 is open through every firewall, that the time server's daemon is actually running, and that you are using the correct IP. A stratum 0 / dispersion 61 response in debug mode is the tell-tale of a blocked or dead source.
Stepping the clock backward on a database server. Always use the -x flag on such hosts. A backward time jump can violate transaction ordering and crash some database engines.
Forgetting /etc/rc.tcpip. If you start xntpd by hand but never uncomment the startup line, the daemon vanishes after the next reboot and the clock silently drifts again.
Expecting instant sync. Declaring failure 30 seconds after startsrc is the classic error. Give it the full settling window before judging.
Single point of failure. Configuring only one server line means an outage of that host leaves you unsynchronized. List at least two.
Huge initial offset with the daemon only. xntpd will refuse to step a very large offset gracefully and can take a long time to converge. Always run the one-shot ntpdate first (Step 2) so the daemon starts from a near-correct clock.

Modern equivalent: AIX 7.x and the NTP v4 / chrony era

The xntpd/ntpdate workflow above is the classic, widely deployed NTP v3 toolset and it still works on production AIX. However, it is worth knowing where the technology has moved, because ntpdate is deprecated upstream and AIX now ships newer options.

NTP v4 (ntpd4) on AIX. Modern AIX (7.1 and later) includes the NTP version 4 daemon, often invoked as ntpd4 with its own /etc/ntp.conf and richer security and IPv6 support. The SRC subsystem and verification commands remain familiar.
Replace one-shot ntpdate with ntpd -gq. The upstream-recommended replacement for a one-time correction is ntpd -gq (or ntpdate only where still provided). The -g allows a large initial step and -q exits after setting the clock.
chrony. On Linux, chronyd has largely superseded the reference NTP daemon and handles intermittent connectivity and virtualized clocks better. AIX administrators managing mixed estates should standardize their upstream NTP servers accordingly even while AIX clients keep using xntpd or ntpd4.

The concepts — verify the source, step once, then run a disciplining daemon and confirm a non-empty peer — are identical regardless of which binary you use.

Key Takeaways

Always verify the time source first with ntpdate -d; look for stratum 1, a real refid such as [GPS], and a sane offset before touching the clock.
Use a one-shot ntpdate <server> to step the clock, then run the xntpd daemon to keep it disciplined — one without the other is incomplete.
Define your server(s) plus a driftfile in /etc/ntp.conf, and uncomment the start line in /etc/rc.tcpip so NTP survives reboots.
On database or production hosts, start with startsrc -s xntpd -a "-x" so the clock is slewed, never stepped backward.
Confirm success with lssrc -ls xntpd — a populated Sys peer and stratum 2 mean success; allow up to about 12 minutes to lock on.

Frequently Asked Questions

Why does my AIX server say "no server suitable for synchronization found"?

This message means ntpdate could not get a usable reply from the time server. The most frequent cause is a firewall blocking UDP port 123; other causes are the time daemon being down on the server or pointing at the wrong IP address. Run ntpdate -d — if you see stratum 0 and a large dispersion, the source is unreachable or not serving time.

What is the difference between ntpdate and xntpd on AIX?

ntpdate performs a single, immediate clock correction and then exits, which makes it ideal for the initial sync. xntpd is the long-running daemon that continuously and gradually keeps the clock locked to the NTP source. Use ntpdate once to set the clock, then run xntpd to maintain it.

How long does it take for xntpd to synchronize?

It can take up to about 12 minutes for xntpd to select a peer and report a non-empty Sys peer in lssrc -ls xntpd. An empty Sys peer right after startup is normal. Running ntpdate beforehand shortens convergence by giving the daemon a near-correct starting clock.

How do I stop the AIX clock from moving backward on a database server?

Start the daemon with the -x option: startsrc -s xntpd -a "-x", and add -x to the xntpd line in /etc/rc.tcpip. This forces the daemon to slew (gradually speed up or slow down) the clock instead of stepping it backward, protecting transaction ordering in databases like Oracle and Db2.

Found this AIX NTP walkthrough useful? Subscribe to @explorenystream on YouTube for more hands-on system administration and DevOps guides.