AW: AW: [chrony-users] chrony: Use of RTC trimming together with ntpdate: A Bad Thing ?

[ Thread Index | Date Index | More chrony.tuxfamily.org/chrony-users Archives ]


>> Hi Bill,
>>
>> OK, more explanation is needed:
>> 1) The system *may* have its BIOS battery removed, been put to storage, taken out of storage, has gotten a new
>> battery and is now starting up with the BIOS (and then system time) off by hours. For this I want to run ntpdate, which
>> would bring the system time very close to the real time.
>You could run chrony with initstepslew some small number and with the remote
>server you want to get the time from initstepslew 30 142.103.1.1 says, go to 142.103.1.1
>and ask for the time. If the system time is more than 30 sec off, jump the clock to the right 
>time. If less, slew the clock to the right time. If you wanted you could make that 1 second instead
>(or maybe even 0, but I am not sure that will work.)
I understand, but as this happens during bootup, I *need* a way to find out when chronyd's
"initistepslew"  has finished, to allow me to remove the temporary route to the NTP server 
(in reality it is a temporary default route). 
So the chrony startup script has run, chronyd was started and the bootup continues to start
more services on the system. And I *need* to have this temporary route removed *before* 
the routing services of my system are started in the bootup.
Right now I don't see how I could pick the right moment to remove the route; chronyc cannot 
be run (no terminal) and I don't want to rely on looking for clues in syslog.
    
>But you can then use chronyc to tell the system to set the rtc to the right time.
True.

>> 2) The system now runs for a while, the external network is disconnected, and the system rebooted. At reboot, chrony
>rebooted? Why rebooted?
>Just bring down the old network and bring up the new.
More explanation: The system is a customer system, installed in a vehicle. A very possible
scenario is this:
- on monday, the vehicle and the router system are fetched from storage, batteries are
put in, cables to the network (a customer intranet) are connected, and the router system
is started up. Here we have the situation that the RTC is bad and we would need a time
step during the bootup process to bring the system close to real time.
- On monday evening, cables are disconnected, the router system is shut down, the vehicle
moves to another place, and the router system is started up agagin, but the network cables
will be connected only next day. Here we have a good RTC, but no network connectivity yet.

>> shall use the RTC to set up the system time, as ntpdate will have failed due to the missing network connections.
>ntpdate is a one shot thing. It will connect that once, and then stop.
That is my intended use: Use the "one-shot" ntpdate in combination with the "tracking" chrony.

>> So I want to have it both ways, but would a possible way be:
>> run ntpdate
>> if ntpdate == OK
>>   run chronyd (without '-s')
>> else
>>   run chronyd -s
>> fi
>Just run chronyd to do everything you want?
Again the problem is to find out *when* I can remove the temporary default route which
facilitates the access to the NTP servers when using chronyd's "initstepslew".

>> Because I have no control about when the RTC contains valid data or not (Battery remove/change).
>OK, then do not use the rtc at all.
Hm, I did not want to go that far...

Thanks for the answers,
Thomas Schmid

---
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.


Mail converted by MHonArc 2.6.19+ http://listengine.tuxfamily.org/