Hi Bill,
So why not delay chrony startup until network access IS available? Clearly
chrony trying to slew 45 years of offset is an exercise in futility.
So true ;-) For this initial startup (BIOS battery inserted, system starts for the first time)
we have a user program where the user is supposed to set the time roughly to the current
(real) time. After this manual setup, the system is restarted again.
The problem is that once the system was running on a specific system time (time A), and
chrony is taking and saving its measurements. Then the system restarts and comes up
with system time B with may be -1h to the previous time A. At such a situation chronyd dies
after about 60s runtime, which (may) coincidence with a possible first contact to one of the
configured servers.
If I remove the "time A"-based chrony-measurements between such a restart, chronyd survives
and starts working on system time B.
I have not yet saved the measurements, and the system is currently busy running other tests,
but I will redo such a test and post the measurements.
Some details:
- System is a combination of a PC and a router, which form a routing unit for IP data integrating
a number of proprietary network interfaces.
- Routing exchange is via OSPF, so a default route (which allows access to the configured NTP
servers) on the PC only becomes available once the OSPF connection between PC and router
has been successfully established.
- PC part of system is running Linux kernel 2.6.27.48
- chrony 1.2.6 installed.
Note: We had to use 'CFLAGS="-O2 -g -DRTC_UF=0x10" ./configure' to enable a working access
to the RTC for chronyd. The chrony-associated Linux kernel header files miss this #define.
It sure should not crash. That is clearly a bug in chrony. When did this crash
happen? .. How far off was the system time when it happened?
I found a difference in system time of 1h is enough most of the time.
When it finally found a time source?
Very much possible, the system is still starting up, but routing had been started and the associated
router should have sent a default route by then.
Do you have logs from before that crach and during that crash ( /var/log/chrony/measurements for example)
Unfortunately no, but I can try to get them.
Regards,
Thomas Schmid
Von: Listengine [listengine@xxxxxxxxxxxxxxxxx]" im Auftrag von "Bill Unruh [unruh@xxxxxxxxxxxxxx]
Gesendet: Samstag, 27. August 2011 18:38
Bis: chrony-users@xxxxxxxxxxxxxxxxxxxx
Betreff: Re: [chrony-users] Chronyd aborts when system time differs too much from chrony's measurements
On Sat, 27 Aug 2011, thomas.schmid@xxxxxxxxx wrote:
Hi all,
I run into the problem mentioned in the FAQ "10. Problems with isolated networks". We have the situation where the computer system in question might come up quite frequently with a large time offset (due to BIOS battery removal, or bad batteries etc) and network access is not available just at boot respectively at chrony startup time (so "initstepslew" can not help).
So why not delay chrony startup until network access IS available? Clearly
chrony trying to slew 45 years of offset is an exercise in futility. So that
fact that chrony is running while your system is way way off time is useless.
chrony needs a time source to sync you system to. Having absolutely none makes
running chrony during that time pointless. Either that or you could get a gps
receiver (eg the Sure receiver) which would give you ms accuracy right off the
bat.
What is the exact amount of time difference chrony still can handle ?
Not sure what you mean by this? Chrony should not care-- it will simply
attempt to slew the time. But far better is
When I tested this, I found that chronyd dies with a SIGABRT, and leaves no traces in syslog about what had happened. Is there a way to configure chrony to handle such a situation in a more benign way, ie leaving a last message ? Or chronyd being kept alive, so it could be questioned by chronyc about such a condition ?
It sure should not crash. That is clearly a bug in chrony. When did this crash
happen? When it finally found a time source? How far off was the system time
when it happened? Do you have logs from before that crach and during that
crash ( /var/log/chrony/measurements for example)
[Note: I hope this problem has not already been discussed to dead before, but I could not find an answer in the mailing list archive].
---
To unsubscribe email chrony-users-request@xxxxxxxxxxxxxxxxxxxx
with "unsubscribe" in the subject.
For help email chrony-users-request@xxxxxxxxxxxxxxxxxxxx
with "help" in the subject.
Trouble? Email listmaster@xxxxxxxxxxxxxxxxxxxx.
---
To unsubscribe email chrony-users-request@xxxxxxxxxxxxxxxxxxxx
with "unsubscribe" in the subject.
For help email chrony-users-request@xxxxxxxxxxxxxxxxxxxx
with "help" in the subject.
Trouble? Email listmaster@xxxxxxxxxxxxxxxxxxxx.