Cluster synchronization issues in one of the three due to bad time
search cancel

Cluster synchronization issues in one of the three due to bad time

book

Article ID: 442360

calendar_today

Updated On:

Products

CA Privileged Access Manager (PAM)

Issue/Introduction

You see that one node is showing synch issues, you realize is because the date time is incorrect in that node, in NTP it show one day ahead of the rest.

Environment

PAM 4.3.1

Cause

The time change can be done or manual, or by synching with NTP or taken from the vmware where PAM node is linked.

You did setting manual the time, rebooting the PAM node, and time was wrong again showing one day more.

Resolution

The problem clock jumps did NOT come from a PAM administrator updating the time on the Configuration > Date/Time page. We would have seen the corresponding web service call in the logs.

The fact that after the reboot the very first kernel message has the bad time stamp strongly suggests that there was a problem with the clock on the physical server that the PAM VM was running on at the time. The time offset is too large for NTP to auto-correct it and the service eventually panics and exits, with all following restarts failing the same way until the clock is corrected by the PAM admin:

2026-05-05T08:45:35.545066+00:00 <server> ntpd[2723152]: CLOCK: Panic: offset too big: -85997.914
2026-05-05T08:45:35.546165+00:00 <server> systemd[1]: ntpsec.service: Main process exited, code=exited, status=1/FAILURE

Based on the PAM logs we conclude that this was an environment problem that is out of our control.

One item to investigate by you would be if there was any VMotion going on during the time frame of interest.