UNIX for Advanced & Expert Users

Hi, I've got an issue which I've been 'google-fu'ing without much luck. We have a legacy program which has been plagued by an issue for a long time and I've been tasked to investigate/fix.

The program uses XMotif2.1 (required due to dependency on an old GUI designer) and runs on a RHEL7 machine (previously RHEL 5 and before that RHEL4). Normal GUI event processing relies on a re-entrant Xt callback using the XtAppAddTimeout call. This works fine, unless the system clock is set backwards, which occurs due during an NTP sync of the system (which can happen at any point during the program). When this occurs, it appears as though the program is frozen. According to my research, the way Xt handles timeouts is by determining the expiration time (system time + expiration interval) and waiting until that absolute time is reached, rather than using a monotonic clock. So, if the timer is waiting for a second to elapse, but during the wait the system time is set backwards by 18 minutes, the timer will wait for 18 minutes and 1 second before going off (i.e. reach the original expected expiration time).

I've found very little information on the web about others experiencing this issue and any suggestions for a solution. We've tried detecting the time jump in a separate thread and then attempting to cancel, via XtRemoveTimeout, and then restart the timer. But, we haven't had much luck. The best solution I've heard so far was to manage the timer outside the X event loop and use XtAppAddWorkProc instead.

This might be a long shot. But, does anyone have any experience with this that could provide some insight. TIA

Maybe a slightly different question will resolve your current problem... Why not run ntpd to keep your clock in sync with an NTP server? That should keep jumps in time to jumps of less than a second instead of jumps of more than a quarter of an hour.

Or are you saying that the clock circuit on your system is so screwed up that it is bouncing forwards and backwards by large amounts and ntpd can't keep up?

That's a good question. The system is connected to an ntp server. The user sets their IP address from within the application at which time it connects to the server and the time jump can occur. The time jump isn't happening constantly; just on that initial connection. But, if the time jump is significant, it's a show stopper, where the only remedy is to restart the box/application.

I repeat my question. Why isn't ntpd running on this client all of the time? Why is any application using NTP when it runs instead of the system running ntpd to keep its clock in sync all of the time?

When the system starts up it doesn't have an IP address, so it can't connect to the ntp server. The application requires the user to select the IP address, based on the physical connection point
of the system on the network. At that point, the system connects to the network and the time jump can occur.