System clock stops on N4000 with eTrust AccessControl

[Plank Guenther]

Hi!

We have 2 N4000 with multible CPU's running HP-UX 11.00 and eTrust AccessControl (SEOS).

Under not really reproducable circumstances, the system clock stops for some hours (6-9, varies). Than the clock begins to run again.

Now CA (eTrust) says HP (HP-UX) Problem - HP says CA Problem.

Anyone else ever seen clock hanging

Günthe

[Steven E. Protter]

Your system board probably has a battery to keep the internal clock going. My feeling is that this battery is dead.

You might also want to connect these servers to an ntp server and see if that keeps the clocks moving along as they should.

HP and CA probably have a liason group that should be able to work out this issue. Contact the support center and tell them you want them to work with CA to solve the problem. If you have a software contact.

SEP

[Plank Guenther]

Hi Steven!

Hardware was checked by HP - We've a 24/7 contract for the machines.

We tried almost everything to get rid at this problem, but now we need a fix for our customer in the next three days.

So one of my last hopes was that anyone in this forum encountert simmilar problems.

Thks

Guenther

[Bill Hassell]

Are you sure that the clock stops? How do you detect this condition? DO cron jobs fail to run? How about at jobs? Is the clock outage always off by hours (minutes are always correct, just the hours are wrong)? If you are checking the time of day clock with the date command among different users, you may have various values for TZ that are translating the actual time to different timezone settings. You can verify that cron and the timeclock are running just fine by logging the time of day in syslog every 15 mins:

0,15,30,45 * * * * logger -p local5.warn $(date)

By doing this in cron, you can verify that the system is working correctly and that the symptom you are seeing is due to enviroment settings and changes.

[Plank Guenther]

Hi all

@Bill
As Etrus (SEOS) has built in a kernel-module wich is able to do process intercetions on kernel-level, we can't exactly say that the clock stops, or the access to the time-calls ist blocked.
We did run scripts like

while true
echo `date` >> x.x
echo `remsh remotehost date` >> x.x
sleep 60
done

The output showed a 9 hour delay between the local and the remote time. 10 hours later again 6 hours more delay.
Cron jobs are not executed when this happens.

We got a script from HP that additionaly reads "ticks_since_boot" variable and we are keeping the systems under heavy load, to reproduce the problem.

So you can see, we have done our lessons in monitoring.

At the moment we only can wait for the Problem to appear - to get HP and CA on the machine when things happen.

Thx

Guenther

[J Busch]

We also use HPUX 11.00 with eTrust. I have not had a problem with system time just printing.

Is there any entries in the eTrust audit logs??

I would look there, there maybe a eTrust rules problem.

[Plank Guenther]

Hi all!

Interesting News!

One of the machines crashed, leaving a dump, that shows the time ticks stopping on one cpu, and continuos running on two other cpu's, for one hour - than the crash occured (spinlock/deadlock).

HP says, that und certain circumstances, the lock maybe release (not by panic), and this would be the explanation for the loss of time.

After install SEOS patch that solves the spinlock/deadlock Problem, we couldn't see any timedrift for 6 days now.

Thx4help

Guenther

[Plank Guenther]

So finaly this thread has to be closed