Chrony on an Isolated Machine

I'm doing fairly well with getting Chrony operational, but have some
questions. I installed it on two machines. On the test machine, I have no
trouble executing rtcdata. On the rtl-op (realtime) machine, it reports
back "503 error -- no rtc device". Both machines have almost identical
conf.rtc files, and I've up/downed chronyd to make sure it catches the conf
file data. The order of directives might be different. /dev/rtc is on both
machines.

I have the chronyd script suggested in the chrony.txt file installed on the
rtl-op machine, and thought I'd try to see what happens to the time when I
brought it down with a reboot command (not shutdown). I lost/gained five
seconds on the clock bringing it back up. That led me to believe that I
need to provide dump and writertl in the chrony.conf file. Is that correct?
It looks like I might also need log tracking ... there too. Is that correct?

Otherwise, after a few settime synchs it looks like the time the rtl-op
machine is doing well at keeping time these days.

BTW, by isolated, I mean I'm using a wristwatch in place of ntp.
--
Wayne T. Watson (Watson Adventures, Prop., Nevada City, CA)
(121.015 Deg. W, 39.262 Deg. N) GMT-8 hr std. time)
Obz Site: 39° 15' 7" N, 121° 2' 32" W, 2700 feet

Web Page: <home.earthlink.net/~mtnviews>

"W. Wat son" <(E-Mail Removed)> writes:

>I'm doing fairly well with getting Chrony operational, but have some
>questions. I installed it on two machines. On the test machine, I have no
>trouble executing rtcdata. On the rtl-op (realtime) machine, it reports
>back "503 error -- no rtc device". Both machines have almost identical

You do not tell us what machine is running or what kernel it is running.

kernels later than 2.6.7 or so have the HPET times support. If it is
enabled it messes with rtc (basically disables it and chrony handles it
very very very badly)

If you have these kernels
a) disable HPET support.
b) Make sure that CONFIG_HPET_RTC_IRQ=n
c) If you want make the rtc module part of the kernel rather than a module.
If you do you can enable rtc emulation.
CONFIG_HPET_EMULATE_RTC=y
or
d) use the genrtc module instead.


>conf.rtc files, and I've up/downed chronyd to make sure it catches the conf
chrony.rtc is the more usual name. What does it say in chrony.conf?

>file data. The order of directives might be different. /dev/rtc is on both
>machines.

>I have the chronyd script suggested in the chrony.txt file installed on the
>rtl-op machine, and thought I'd try to see what happens to the time when I
>brought it down with a reboot command (not shutdown). I lost/gained five
>seconds on the clock bringing it back up. That led me to believe that I

You must start chrony with the -r -s options if you want to make use of the
rtc on bootup.

>need to provide dump and writertl in the chrony.conf file. Is that correct?
>It looks like I might also need log tracking ... there too. Is that correct?

>Otherwise, after a few settime synchs it looks like the time the rtl-op
>machine is doing well at keeping time these days.

>BTW, by isolated, I mean I'm using a wristwatch in place of ntp.

Comments mixed in below.
Bill Unruh wrote:

> "W. Wat son" <(E-Mail Removed)> writes:
>
>
>>I'm doing fairly well with getting Chrony operational, but have some
>>questions. I installed it on two machines. On the test machine, I have no
>>trouble executing rtcdata. On the rtl-op (realtime) machine, it reports
>>back "503 error -- no rtc device". Both machines have almost identical
>
>
> You do not tell us what machine is running or what kernel it is running.
RHL 9.0. RTL kernel is Linux 2.4.20.
>
> kernels later than 2.6.7 or so have the HPET times support. If it is
> enabled it messes with rtc (basically disables it and chrony handles it
> very very very badly)
>
> If you have these kernels
> a) disable HPET support.
> b) Make sure that CONFIG_HPET_RTC_IRQ=n
> c) If you want make the rtc module part of the kernel rather than a module.
> If you do you can enable rtc emulation.
> CONFIG_HPET_EMULATE_RTC=y
> or
> d) use the genrtc module instead.
It doesn't look I need to worry about them, 2.4.20 for me. Both my machines
use the same brands of RHL 9. What is HPET?
>
>
>
>>conf.rtc files, and I've up/downed chronyd to make sure it catches the conf
>
> chrony.rtc is the more usual name. What does it say in chrony.conf?
>
>
>>file data. The order of directives might be different. /dev/rtc is on both
>>machines.
>
>
>>I have the chronyd script suggested in the chrony.txt file installed on the
>>rtl-op machine, and thought I'd try to see what happens to the time when I
>>brought it down with a reboot command (not shutdown). I lost/gained five
>>seconds on the clock bringing it back up. That led me to believe that I
>
>
> You must start chrony with the -r -s options if you want to make use of the
> rtc on bootup.
The local.rc file uses this (from chrony.txt):
To start `chronyd' during the boot sequence, I have the following in
`/etc/rc.d/rc.local' (this is a Slackware system)

if [ -f /usr/local/sbin/chronyd -a -f /etc/chrony.conf ]; then
/usr/local/sbin/chronyd -r -s
echo "Start chronyd"
fi
I have my doubts about -a. I do not believe it is mentioned in my man page.
What is it? Whatever, it certainly did start when I did the reboot.

I did the last restart (down/up) without -r -s. I'll try that again.
>
>
>>need to provide dump and writertl in the chrony.conf file. Is that correct?
>>It looks like I might also need log tracking ... there too. Is that correct?
Any the answers are?

>
>
>>Otherwise, after a few settime synchs it looks like the time the rtl-op
>>machine is doing well at keeping time these days.
>
>
>>BTW, by isolated, I mean I'm using a wristwatch in place of ntp.



--
Wayne T. Watson (Watson Adventures, Prop., Nevada City, CA)
(121.015 Deg. W, 39.262 Deg. N) GMT-8 hr std. time)
Obz Site: 39° 15' 7" N, 121° 2' 32" W, 2700 feet

Web Page: <home.earthlink.net/~mtnviews>

"W. Wat son" <(E-Mail Removed)> writes:


>>>I'm doing fairly well with getting Chrony operational, but have some
>>>questions. I installed it on two machines. On the test machine, I have no
>>>trouble executing rtcdata. On the rtl-op (realtime) machine, it reports
>>>back "503 error -- no rtc device". Both machines have almost identical
>>
>>
>> You do not tell us what machine is running or what kernel it is running.
>RHL 9.0. RTL kernel is Linux 2.4.20.

OK, those should be fine.

cat /dev/rtc
do you get some output?
Also look in the file where you dump output from daemon.* (syslogd) tht is
where chronyd puts its error etc stuff.


>>
>> kernels later than 2.6.7 or so have the HPET times support. If it is
>> enabled it messes with rtc (basically disables it and chrony handles it
>> very very very badly)
>It doesn't look I need to worry about them, 2.4.20 for me. Both my machines
>use the same brands of RHL 9. What is HPET?

High Performace Event Timer-- it replaces the old timer chip on new
motherboards. However it really is not compatible with rtc. Thus if you
enable HPET, rtc has problems.
Most distros now are enabling HPET. rtc has problems. chrony is going to
HAVE to be rewritten.


>>
>> You must start chrony with the -r -s options if you want to make use of the
>> rtc on bootup.
>The local.rc file uses this (from chrony.txt):
>To start `chronyd' during the boot sequence, I have the following in
>`/etc/rc.d/rc.local' (this is a Slackware system)

> if [ -f /usr/local/sbin/chronyd -a -f /etc/chrony.conf ]; then
> /usr/local/sbin/chronyd -r -s
> echo "Start chronyd"
> fi
>I have my doubts about -a. I do not believe it is mentioned in my man page.

That is an option to test ==> [ ([ is a command which is the same command
as the command test.) the -a option to test is "and". -f is an option to
test which reads "does_file_exist". Thus the above line reads

if test ( does_file_exist(/usr/local/sbin/chronyd) AND does_file_exist
(/etc/chrony.conf) ) ; then ....

>What is it? Whatever, it certainly did start when I did the reboot.

>I did the last restart (down/up) without -r -s. I'll try that again.

That is fine. the -r is only for the very first time chrony is started up.
It then reads teh real time clock, reads the chrony.rtc file to see how
much the rtc must be corrected, and then sets the system time to the
correct time. Thereafter system time is already correct and you should not
use the -r again, until the next time you boot up.

Note that you MUST remove the line in /etc/init.c/halt which resets the
hardware clock. That completely messes up chrony.
Under Mandrake the line is
runcmd "Syncing hardware clock to system time" /sbin/hwclock $CLOCKFLAGS

Put a # at the beginning of that line. It is trying to do the same thing as
the chrony -r is, but badly. chronyd -r is far far better. But that line
completely messes up chrony if it is in the halt script.


>>
>>
>>>need to provide dump and writertl in the chrony.conf file. Is that correct?
>>>It looks like I might also need log tracking ... there too. Is that correct?
>Any the answers are?

No, none are needed. chrony writes to the chrony.rtc file periodically
(actually when it is stopped). If
you want it to at some time-- eg just before your system crashes:-), by all means use the writertc command.

s

Bill Unruh wrote:

> "W. Wat son" <(E-Mail Removed)> writes:
>
....

>> You do not tell us what machine is running or what kernel it is
>> running.
>>
>> RHL 9.0. RTL kernel is Linux 2.4.20.
>
>
> OK, those should be fine.
>
> cat /dev/rtc do you get some output? Also look in the file where you
> dump output from daemon.* (syslogd) tht is where chronyd puts its error
> etc stuff.
cat on rtl-op gives
cat: rtc: No such device

ls -l rtc on both machines gives the same response
cat on the test machine gives: device busy

file on rtl-op gives: character special 10/35
Same on test machine.

....
>> It doesn't look I need to worry about them, 2.4.20 for me. Both my
>> machines use the same brands of RHL 9. What is HPET?
>
>
> High Performace Event Timer-- it replaces the old timer chip on new
> motherboards. However it really is not compatible with rtc. Thus if you
> enable HPET, rtc has problems. Most distros now are enabling HPET. rtc
> has problems. chrony is going to HAVE to be rewritten.
>
>
>
>>> You must start chrony with the -r -s options if you want to make use
>>> of the rtc on bootup.
>>
>> The local.rc file uses this (from chrony.txt): To start `chronyd'
>> during the boot sequence, I have the following in `/etc/rc.d/rc.local'
>> (this is a Slackware system)
>
>
>> if [ -f /usr/local/sbin/chronyd -a -f /etc/chrony.conf ]; then
>> /usr/local/sbin/chronyd -r -s echo "Start chronyd" fi I have my doubts
>> about -a. I do not believe it is mentioned in my man page.
>
>
> That is an option to test ==> [ ([ is a command which is the same
> command as the command test.) the -a option to test is "and". -f is an
> option to test which reads "does_file_exist". Thus the above line reads
>
> if test ( does_file_exist(/usr/local/sbin/chronyd) AND does_file_exist
> (/etc/chrony.conf) ) ; then ....
>
>
>> What is it? Whatever, it certainly did start when I did the reboot.
>
>
>> I did the last restart (down/up) without -r -s. I'll try that again.
>
>
> That is fine. the -r is only for the very first time chrony is started
> up. It then reads teh real time clock, reads the chrony.rtc file to see
> how much the rtc must be corrected, and then sets the system time to the
> correct time. Thereafter system time is already correct and you should
> not use the -r again, until the next time you boot up.
>
> Note that you MUST remove the line in /etc/init.c/halt which resets the
> hardware clock. That completely messes up chrony.
There's a init.d but no init.c. It has a halt in it.
> Under Mandrake the line is runcmd "Syncing hardware clock to system
> time" /sbin/hwclock $CLOCKFLAGS
>
> Put a # at the beginning of that line. It is trying to do the same thing
> as the chrony -r is, but badly. chronyd -r is far far better. But that
> line completely messes up chrony if it is in the halt script.
>
>
>
>>>
>>>> need to provide dump and writertl in the chrony.conf file. Is that
>>>> correct? It looks like I might also need log tracking ... there
>>>> too. Is that correct?
>>
>> Any the answers are?
>
>
> No, none are needed. chrony writes to the chrony.rtc file periodically
> (actually when it is stopped). If you want it to at some time-- eg just
> before your system crashes:-), by all means use the writertc command.
I'll practice. :-)
>
> s

I rebooted into op instead of rtl-o on the same machine and ran chronyc.
rtcdata works over there. Looks like some peculiarity of rtl is the problem.

--
Wayne T. Watson (Watson Adventures, Prop., Nevada City, CA)
(121.015 Deg. W, 39.262 Deg. N) GMT-8 hr std. time)
Obz Site: 39° 15' 7" N, 121° 2' 32" W, 2700 feet

Web Page: <home.earthlink.net/~mtnviews>

Here's the output from using the -d option on the rtl-op boot:
=================
[root@MeteorPC chrony-1.20]# man chronyd
[root@MeteorPC chrony-1.20]# /usr/local/sbin/chronyd -d -r -s
sys_linux.c:649get_version_specific_details)[19-03:42:15] Initial
txc.tick=1000 txc.freq=-6961718 (-106.22738647) txc.offset=0 => hz=1024
shift_hz=10
sys_linux.c:665get_version_specific_details)[19-03:42:15] set_config_hz=0
hz=1024 shift_hz=10 basic_freq_scale=1.00000000 nominal_tick=977
slew_delta_tick=81 max_tick_bias=97
sys_linux.c:703get_version_specific_details)[19-03:42:15] Linux kernel
major=2 minor=4 patch=20
sys_linux.c:787get_version_specific_details)[19-03:42:15]
calculated_freq_scale=1.00000000 freq_scale=1.00000000
rtc_linux.c:617RTC_Linux_Initialise)[19-03:42:15] Could not open
/dev/rtc, No such device
rtc.c:106RTC_Initialise)[19-03:42:15] Real time clock not supported on
this operating system
rtc.c:144RTC_TimeInit)[19-03:42:15] Can't initialise from real time
clock, driver not loaded
==========================
I believe this was the response to rtcdata rather than just output from the
startup. I had originally compiled chrony on the rtl boot, but before
running this recompiled on the non-rtl boot. It ran fine on the non-rtl
boot. It just doesn't like rtl for some reason.

--
Wayne T. Watson (Watson Adventures, Prop., Nevada City, CA)
(121.015 Deg. W, 39.262 Deg. N) GMT-8 hr std. time)
Obz Site: 39° 15' 7" N, 121° 2' 32" W, 2700 feet

Web Page: <home.earthlink.net/~mtnviews>

"W. Wat son" <(E-Mail Removed)> writes:

>Here's the output from using the -d option on the rtl-op boot:
>=================
>[root@MeteorPC chrony-1.20]# man chronyd
>[root@MeteorPC chrony-1.20]# /usr/local/sbin/chronyd -d -r -s
>sys_linux.c:649get_version_specific_details)[19-03:42:15] Initial
>txc.tick=1000 txc.freq=-6961718 (-106.22738647) txc.offset=0 => hz=1024
>shift_hz=10
>sys_linux.c:665get_version_specific_details)[19-03:42:15] set_config_hz=0
>hz=1024 shift_hz=10 basic_freq_scale=1.00000000 nominal_tick=977
>slew_delta_tick=81 max_tick_bias=97
>sys_linux.c:703get_version_specific_details)[19-03:42:15] Linux kernel
>major=2 minor=4 patch=20
>sys_linux.c:787get_version_specific_details)[19-03:42:15]
>calculated_freq_scale=1.00000000 freq_scale=1.00000000
>rtc_linux.c:617RTC_Linux_Initialise)[19-03:42:15] Could not open
>/dev/rtc, No such device
>rtc.c:106RTC_Initialise)[19-03:42:15] Real time clock not supported on
>this operating system
>rtc.c:144RTC_TimeInit)[19-03:42:15] Can't initialise from real time
>clock, driver not loaded

This may mean that the rtc driver is not loaded when chronyd loads.

After it has come up do
service chronyd stop
lsmod|grep rtc
If it does not exist, do
modprobe rtc
Then do
service chronyd start

See if /dev/rtc exists.See if rtc module is loaded.

Look at the logs again.

Bill Unruh wrote:

> "W. Wat son" <(E-Mail Removed)> writes:
>
>
>>Here's the output from using the -d option on the rtl-op boot:
>>=================
>>[root@MeteorPC chrony-1.20]# man chronyd

....
>>rtc.c:144RTC_TimeInit)[19-03:42:15] Can't initialise from real time
>>clock, driver not loaded
>
>
> This may mean that the rtc driver is not loaded when chronyd loads.
>
> After it has come up do
> service chronyd stop
> lsmod|grep rtc
> If it does not exist, do
> modprobe rtc
> Then do
> service chronyd start
>
> See if /dev/rtc exists.See if rtc module is loaded.
>
> Look at the logs again.
>
lsmod doesn't exist on the rtl side, nor does modprobe. On the non-rtl
side, they both exist; however, modprobe rtc finds nothing. Nevertheless,
when I run chronyc on the non-rtl side, it operates rtcdata.

I would guess chrony is not going to work in reboot situations on the rtl
side without rtc. It kept pretty accurate time last night for 12 hours. I
can rebuild the rtl boot and hopefully configure it with the module
containing rtc, lsmod, etc.

I was correct in removing (with #) halt in the init.d file, right?
--
Wayne T. Watson (Watson Adventures, Prop., Nevada City, CA)
(121.015 Deg. W, 39.262 Deg. N) GMT-8 hr std. time)
Obz Site: 39° 15' 7" N, 121° 2' 32" W, 2700 feet

Web Page: <home.earthlink.net/~mtnviews>

"W. Wat son" <(E-Mail Removed)> writes:

>Bill Unruh wrote:

>> "W. Wat son" <(E-Mail Removed)> writes:
>>
>>
>>>Here's the output from using the -d option on the rtl-op boot:
>>>=================
>>>[root@MeteorPC chrony-1.20]# man chronyd

>...
>>>rtc.c:144RTC_TimeInit)[19-03:42:15] Can't initialise from real time
>>>clock, driver not loaded
>>
>>
>> This may mean that the rtc driver is not loaded when chronyd loads.
>>
>> After it has come up do
>> service chronyd stop
>> lsmod|grep rtc
>> If it does not exist, do
>> modprobe rtc
>> Then do
>> service chronyd start
>>
>> See if /dev/rtc exists.See if rtc module is loaded.
>>
>> Look at the logs again.
>>
>lsmod doesn't exist on the rtl side, nor does modprobe. On the non-rtl
>side, they both exist; however, modprobe rtc finds nothing. Nevertheless,
>when I run chronyc on the non-rtl side, it operates rtcdata.

I do not know what "rtl" side means. (Real Time Liniux?) The absense of
modprobe and lsmod may mean that the system has everything built into the
kernel-- no modules at all. Which is fine. But makes it harder to debug.



>I would guess chrony is not going to work in reboot situations on the rtl
>side without rtc. It kept pretty accurate time last night for 12 hours. I
>can rebuild the rtl boot and hopefully configure it with the module
>containing rtc, lsmod, etc.

rtc is the module. lsmod is a command, as is modprobe. lsmod lists all
modules loaded onto the system. modprobe actually loads teh modules ( and
their dependencies). But if they are compiled into the system, then there
is nothing to load or list. If /dev/rtc exists, that is pretty good
evidence that that the rtc is built in (unless you or someone else created
that ) You could also see if /proc/driver/rtc exists to see if rtc is
enabled.

Also look in the config file for your kernel ( some put it into
/boot/config) to see if there is anything regarding RTC in there.


>I was correct in removing (with #) halt in the init.d file, right?

By that I hope you mean placing a # at the begining of the line resetting
the clock in
/etc/init.d/halt
You do not want to remove halt altogether. Just that one line.