Recurring NTP Sync Issue on Avaya IPO Server Edition – Time Drift and Manual Restart Required

[William C290]

Hello Tek-Tips Community,

​

I’m facing a recurring NTP synchronization issue on an Avaya IP Office Server Edition 11.1 setup that is impacting critical telephony services for a banking client.

Issue Description:​

• The system time drifts over time and loses synchronization with the NTP server.
• The NTP service (ntpd) stops syncing automatically.
• To fix the time, we currently run the following commands manually:

sudo systemctl restart ntpd
sudo ntpdate -u x.x.x.x

​

• After about 5 minutes, the ntpq -p command shows * next to the server indicating sync is restored.
• However, this fix is temporary and the problem recurs after some time, requiring repeated manual intervention.

What We’ve Tried:​

• Ensured only valid NTP servers are in the configuration (removed local clock).
• Checked system time with timedatectl and NTP status with ntpq -p.
• Restarting the NTP service and forcing update as a workaround.

Impact:​

• Time drift causes issues with call center operations, reporting accuracy, and call recording synchronization.
• The issue has persisted despite multiple attempts to stabilize NTP sync.

Request for Advice:​

• Has anyone encountered similar recurring NTP sync failures on Avaya IPO environments?
• Are there recommended best practices or configuration tweaks to prevent this?
• Could there be underlying system or network issues causing the NTP service to lose sync?
• Any suggestions on how to enforce continuous NTP sync or automated recovery without manual restart?

Thanks in advance for your insights and help!

 

[Mo. Abdullah]

I faced this issue once, and Avaya told me it is a Linux corruption and recommended rebuilding the machine from scratch and restoring the configurations.
But I am using the following commands for any issues with the NTP service.
I hope it might help:

systemctl restart ntpd

systemctl enable ntpd

timedatectl set-ntp true

timedatectl set-local-rtc 1

systemctl enable --now chronyd

restart ntpd

ntpdate -q pool.ntp.org

vi /etc/ntp.conf

 

[derfloh]

Probably easier to run a script with cron instead of rebuilding the whole server.

 

[William C290]

I faced this issue once, and Avaya told me it is a Linux corruption and recommended rebuilding the machine from scratch and restoring the configurations.
But I am using the following commands for any issues with the NTP service.
I hope it might help:

systemctl restart ntpd

systemctl enable ntpd

timedatectl set-ntp true

timedatectl set-local-rtc 1

systemctl enable --now chronyd

restart ntpd

ntpdate -q pool.ntp.org

vi /etc/ntp.conf

Thanks a lot for sharing your experience and for taking the time to write the commands — really appreciated.


I’m currently working on an Avaya IP Office Server Edition running on VMware, and I actually faced a similar issue recently where the timezone unexpectedly changed and NTP sync stopped working properly.


Your input helped me revisit my NTP handling logic. I just wanted to point out a few things in case it helps others reading this thread:

• chronyd and ntpd should not be running at the same time — they will conflict. It’s better to stick to one (in my case, ntpd is preferred since it's the default used by Avaya).
• Also, using timedatectl set-local-rtc 1 might cause problems with daylight saving and time drift, especially on VMware. I’d recommend keeping the hardware clock in UTC with:
  
  timedatectl set-local-rtc 0 --adjust-system-clock
  

Other than that, your checklist is super useful. I’ve added a cron job to auto-sync the time every night at 2 AM just in case the NTP sync fails silently.


Thanks again!

 

[William C290]

Probably easier to run a script with cron instead of rebuilding the whole server.

Hi,


You're absolutely right — in most cases, setting up a robust cron job with proper ntpdate or ensuring ntpd runs correctly can save a lot of headache, and definitely easier than rebuilding the entire server.


That being said, I suspect some edge-case behavior here — maybe a conflict between VMware Tools time sync and NTP, especially after vMotion or host migrations. So I’ve now disabled time sync from the ESXi host side and added cron-based sync as fallback.


So far it’s holding up well — fingers crossed. Appreciate the input!


Best regards,

 

[William C290]

Hi All,

We recently opened a support case with Avaya due to unexplained time synchronization failures on our IP Office system.
The assigned engineer developed and implemented a full monitoring and recovery solution, including automatic checks, ping gap detection, and intelligent NTP switching logic.

We’re currently testing it in production.

Once confirmed stable, I’ll be sharing full details and scripts as a best practice reference for anyone facing similar NTP issues.


Stay tuned.

 

[derfloh]

Sounds like you had one of the few engineers that is really knowing the system and the underlying Linux.

 

[William C290]

Sounds like you had one of the few engineers that is really knowing the system and the underlying Linux.

Absolutely — and in this case, the engineer really showed deep understanding of both the NTP stack and Linux internals.
He didn’t just apply a generic fix, but tailored a proactive monitoring and correction mechanism, covering:

• Time drift detection via monotonic clock comparison
• Intelligent failover between primary and secondary NTP servers
• Validation of NTP server offsets before switching
• Alerting when ntpd syncs to unreachable peers
• Daily forced sync + timezone enforcement
• Full log and report generation

Definitely one of those rare solutions that both solves the issue and teaches you something.

If you’re sharing this as a best practice, this one deserves to be highlighted.