I have 1 server which will not set the system time at all. Here is an
example. I set the time to 10 minutes earlier, but when I run the date
command again, the date hasn't changed.

[root@S141-141 ~]# date
Sun Sep 3 03:30:51 EDT 2006
[root@S141-141 ~]# date -s "Sun Sep 3 03:20:51 EDT 2006"
Sun Sep 3 03:20:51 EDT 2006
[root@S141-141 ~]# date
Sun Sep 3 03:31:04 EDT 2006


Trying to set it to a future time also does nothing:

[root@S141-141 ~]# date -s "Sun Sep 3 03:50:51 EDT 2006"
Sun Sep 3 03:50:51 EDT 2006
[root@S141-141 ~]# date
Sun Sep 3 03:33:40 EDT 2006
[root@S141-141 ~]#


If I run the ntpdate on this machine twice in a row, it makes no change
to the system clock.

[root@S141-141 ~]# /usr/sbin/ntpdate ntp2.usno.navy.mil
3 Sep 03:32:37 ntpdate[17446]: step time server 192.5.41.209 offset
-43786.809017 sec
[root@S141-141 ~]# /usr/sbin/ntpdate ntp2.usno.navy.mil
3 Sep 03:32:39 ntpdate[17447]: step time server 192.5.41.209 offset
-43786.809177 sec
[root@S141-141 ~]#

I uploaded a different binary for 'date' and that too does not work.

Any idea what is wrong?

ppc@cheapbooks.com wrote:
> I have 1 server which will not set the system time at all. Here is an
> example. I set the time to 10 minutes earlier, but when I run the date
> command again, the date hasn't changed.
>
> [root@S141-141 ~]# date
> Sun Sep 3 03:30:51 EDT 2006
> [root@S141-141 ~]# date -s "Sun Sep 3 03:20:51 EDT 2006"
> Sun Sep 3 03:20:51 EDT 2006
> [root@S141-141 ~]# date
> Sun Sep 3 03:31:04 EDT 2006

> Trying to set it to a future time also does nothing:

> [root@S141-141 ~]# date -s "Sun Sep 3 03:50:51 EDT 2006"
> Sun Sep 3 03:50:51 EDT 2006
> [root@S141-141 ~]# date
> Sun Sep 3 03:33:40 EDT 2006
> [root@S141-141 ~]#

> If I run the ntpdate on this machine twice in a row, it makes no change
> to the system clock.

> [root@S141-141 ~]# /usr/sbin/ntpdate ntp2.usno.navy.mil
> 3 Sep 03:32:37 ntpdate[17446]: step time server 192.5.41.209 offset
> -43786.809017 sec
> [root@S141-141 ~]# /usr/sbin/ntpdate ntp2.usno.navy.mil
> 3 Sep 03:32:39 ntpdate[17447]: step time server 192.5.41.209 offset
> -43786.809177 sec
> [root@S141-141 ~]#

> I uploaded a different binary for 'date' and that too does not work.

> Any idea what is wrong?

In /etc/cron.hourly/ I run
rdate -s 128.118.25.3
and it works. The ip is a public ntp server. I remember years ago the UNSO
stoppped working for me and haven't retried it since them.

As to the manual entry I presume it ignores an incorrect string format. Other
than that is the internal clock working? Getting the same date/time twice in a
row suggests it is not. Defective? Old and battery dead?

--
Israel: A land filled with panic-stricked cockroaches in fear for their
existence.
-- The Iron Webmaster, 3685

nizkor http://www.giwersworld.org/nizkook/nizkook.phtml
Zionism http://www.giwersworld.org/disinfo/disinfo.phtml a4

Matt Giwer wrote:
> ppc@cheapbooks.com wrote:
>> I have 1 server which will not set the system time at all. Here is an
>> example. I set the time to 10 minutes earlier, but when I run the date
>> command again, the date hasn't changed.
>>
>> [root@S141-141 ~]# date
>> Sun Sep 3 03:30:51 EDT 2006
>> [root@S141-141 ~]# date -s "Sun Sep 3 03:20:51 EDT 2006"
>> Sun Sep 3 03:20:51 EDT 2006
>> [root@S141-141 ~]# date
>> Sun Sep 3 03:31:04 EDT 2006
>
>> Trying to set it to a future time also does nothing:
>
>> [root@S141-141 ~]# date -s "Sun Sep 3 03:50:51 EDT 2006"
>> Sun Sep 3 03:50:51 EDT 2006
>> [root@S141-141 ~]# date
>> Sun Sep 3 03:33:40 EDT 2006
>> [root@S141-141 ~]#
>
>> If I run the ntpdate on this machine twice in a row, it makes no change
>> to the system clock.
>
>> [root@S141-141 ~]# /usr/sbin/ntpdate ntp2.usno.navy.mil
>> 3 Sep 03:32:37 ntpdate[17446]: step time server 192.5.41.209 offset
>> -43786.809017 sec
>> [root@S141-141 ~]# /usr/sbin/ntpdate ntp2.usno.navy.mil
>> 3 Sep 03:32:39 ntpdate[17447]: step time server 192.5.41.209 offset
>> -43786.809177 sec
>> [root@S141-141 ~]#
>
>> I uploaded a different binary for 'date' and that too does not work.
>
>> Any idea what is wrong?
>
> In /etc/cron.hourly/ I run
> rdate -s 128.118.25.3
> and it works. The ip is a public ntp server. I remember years ago the
> UNSO stoppped working for me and haven't retried it since them.
>
> As to the manual entry I presume it ignores an incorrect string
> format. Other than that is the internal clock working? Getting the same
> date/time twice in a row suggests it is not. Defective? Old and battery
> dead?
>
I am fairly sure that date doesn't read the hardware clock - it never
used to anyway. It just used to pick it up at boot time and then run its
own clock from thereon in.

I think setclock is the command to adjust the hardware clock. If this
particular installation is using it.

In comp.os.linux.setup The Natural Philosopher <a@b.c>:
> Matt Giwer wrote:
>> ppc@cheapbooks.com wrote:

[ problems setting system time ]

>> In /etc/cron.hourly/ I run
>> rdate -s 128.118.25.3
>> and it works. The ip is a public ntp server. I remember years ago the
>> UNSO stoppped working for me and haven't retried it since them.

I'd use ntpd to keep clock in sync. Use 'ntpq' to check if ntp is
working as expected after configuring and starting. Though it
takes some time to sync probably and ntp will not set the clock
if it's off to much. There are tons of public ntp server. It is
best practice to sync only one/two systems from public servers
and let all other in your network use those one/two as ntp
server.

Alternatively you can setup your own stratum server(s) if you have
the device to obtain correct time information. In Europe you can
use rather cheapo DCF77 receiver. GPS might work, albeit it
doesn't iirc use leap seconds since it is not important to GPS
functionality, though it might be for your local time.

>> As to the manual entry I presume it ignores an incorrect string
>> format. Other than that is the internal clock working? Getting the same
>> date/time twice in a row suggests it is not. Defective? Old and battery
>> dead?

> I am fairly sure that date doesn't read the hardware clock - it never
> used to anyway. It just used to pick it up at boot time and then run its
> own clock from thereon in.

> I think setclock is the command to adjust the hardware clock. If this
> particular installation is using it.

Never heard about this command.

Hint:
man hwclock

--
Michael Heiming (X-PGP-Sig > GPG-Key ID: EDD27B94)
mail: echo zvpunry@urvzvat.qr | perl -pe 'y/a-z/n-za-m/'
#bofh excuse 271: The kernel license has expired

The Natural Philosopher wrote:
> Matt Giwer wrote:
....
>> In /etc/cron.hourly/ I run
>> rdate -s 128.118.25.3
>> and it works. The ip is a public ntp server. I remember years ago the
>> UNSO stoppped working for me and haven't retried it since them.

>> As to the manual entry I presume it ignores an incorrect string
>> format. Other than that is the internal clock working? Getting the
>> same date/time twice in a row suggests it is not. Defective? Old and
>> battery dead?

> I am fairly sure that date doesn't read the hardware clock - it never
> used to anyway. It just used to pick it up at boot time and then run its
> own clock from thereon in.

Way back when the system clock had to be set manually. I don't remember when I
stopped seeing a need to do that it has been so long, on the order of 15 years.
You can boot a computer today without a network connection and get the correct
time. That is from the system wristwatch type clock.

> I think setclock is the command to adjust the hardware clock. If this
> particular installation is using it.

I do not have a program called setclock, never heard of it. There is ntpdate
and rdate that I know of. I checked the ntpdate man and "too hard" to guess so I
included what works for me.

Also instead of an ip number set often ntp.yourisp.com works.

--
All news coming from Israel is under strict military censorship. Why would
anyone believe a word? This includes all foreign news services.
-- The Iron Webmaster, 3682
nizkor http://www.giwersworld.org/nizkook/nizkook.phtml
antisemitism http://www.giwersworld.org/antisem/ a1

The Natural Philosopher <a@b.c> did eloquently scribble:
> I think setclock is the command to adjust the hardware clock. If this
> particular installation is using it.

hwclock I think you're thinking of.
hwclock --set --date="<date/time string here>"
hwclock --hctosys
to update system clock to hardware clock

--
__________________________________________________ ____________________________
| spike1@freenet.co.uk | |
|Andrew Halliwell BSc(hons)| "The day Microsoft makes something that doesn't |
| in | suck is probably the day they start making |
| Computer science | vacuum cleaners" - Ernst Jan Plugge |
------------------------------------------------------------------------------

Michael Heiming wrote:
> In comp.os.linux.setup The Natural Philosopher <a@b.c>:
>> Matt Giwer wrote:
>>> ppc@cheapbooks.com wrote:
>
> [ problems setting system time ]
>
>>> In /etc/cron.hourly/ I run
>>> rdate -s 128.118.25.3
>>> and it works. The ip is a public ntp server. I remember years ago the
>>> UNSO stoppped working for me and haven't retried it since them.
>
> I'd use ntpd to keep clock in sync. Use 'ntpq' to check if ntp is
> working as expected after configuring and starting. Though it
> takes some time to sync probably and ntp will not set the clock
> if it's off to much. There are tons of public ntp server. It is
> best practice to sync only one/two systems from public servers
> and let all other in your network use those one/two as ntp
> server.
>
> Alternatively you can setup your own stratum server(s) if you have
> the device to obtain correct time information. In Europe you can
> use rather cheapo DCF77 receiver. GPS might work, albeit it
> doesn't iirc use leap seconds since it is not important to GPS
> functionality, though it might be for your local time.
>
>>> As to the manual entry I presume it ignores an incorrect string
>>> format. Other than that is the internal clock working? Getting the same
>>> date/time twice in a row suggests it is not. Defective? Old and battery
>>> dead?
>
>> I am fairly sure that date doesn't read the hardware clock - it never
>> used to anyway. It just used to pick it up at boot time and then run its
>> own clock from thereon in.
>
>> I think setclock is the command to adjust the hardware clock. If this
>> particular installation is using it.
>
> Never heard about this command.
>
> Hint:
> man hwclock
>
Ah. Setclock might be an old SCO unix one.