[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Potential issue with Linux emulation?
- To: "'Andrey Smagin'" <andrey_(_at_)_smagin_(_dot_)_com>, <tech_(_at_)_openbsd_(_dot_)_org>
- Subject: Re: Potential issue with Linux emulation?
- From: "Pierre-Yves Dampure" <pierre-yves_(_dot_)_dampure_(_at_)_westmarsh_(_dot_)_com>
- Date: Sat, 23 Aug 2003 23:51:45 +0100
- Organization: Westmarsh Consulting Ltd
I did NOT have NTP running (or installed for that matter) in either case.
Simply executing the following reset the date to the epoch (you need to have
at least tried a make install of the redhat base package, which will reset
the date too, so don't forget to adjust it before running the following):
This is why I think it's a problem with the Linux emulation. Thing is, I
don't know how to go about tracking the system call that is responsible for
From: owner-tech_(_at_)_openbsd_(_dot_)_org [mailto:owner-tech_(_at_)_openbsd_(_dot_)_org] On Behalf Of
Sent: 23 August 2003 22:36
Subject: Re: Potential issue with Linux emulation?
On Sat, 23 Aug 2003 22:17:07 +0100
Andreas Kähäri <ak_(_at_)_freeshell_(_dot_)_org> wrote:
> I wonder if this has anything at all to do with my problem in the
> "ntpd doesn't keep good time" thread on misc@ from the 20th & 21st
> this month? I also saw my clock warp back to 1970, but didn't really
> think that the Linux emulation had anything to do with it.
Hmm, I had similar problem just a few days ago. After upgrading two servers
to -current and installing ntp package, my date gets reset to September 22,
1944 about five minutes after reboot (well, that's the time that 'date'
reports, but if I reboot and check the date in BIOS, it's <something> in
Both servers are i386 (Gateway Server 6400 and 7200, dmesg avl. upon
request), one was upgraded from source and had ntp-4.1.1 installed, another
one was a clean install from snapshot and had ntp-4.1.74. Both servers were
running ntp with the same settings without problems before. I uninstalled
ntp from both of them and the date does not get reset now.
Also, cron really was not happy with the date changing like that - it would
start using 25-35% of the CPU while doing nothing.