* [gentoo-amd64] Problem with latest timezone update?
@ 2008-01-15 15:22 Mark Haney
2008-01-15 16:45 ` Beso
2008-01-15 17:01 ` Drake Donahue
0 siblings, 2 replies; 17+ messages in thread
From: Mark Haney @ 2008-01-15 15:22 UTC (permalink / raw
To: gentoo-amd64
Okay, here's something I can't seem to figure out. My laptop time
doesn't want to stay sync'd. I always run ntpd at boot time to keep it
in sync, but now, when I boot without an ethernet cable hooked up, it's
over 5 hours off. It didn't do this until I updated the timezone just
after Christmas. /etc/conf.d/clock is set to my timezone (EST5EDT) and
/etc/localtime is symlinked to the correct timezone.
I thought maybe the BIOS clock was wrong, but it's not 5 hours off,
maybe a minute or so. I tried setting the HWclock to system time and
that didn't fix it. Any ideas on what else to try?
--
Recedite, plebes! Gero rem imperialem!
Mark Haney
Sr. Systems Administrator
ERC Broadband
(828) 350-2415
Call (866) ERC-7110 for after hours support
--
gentoo-amd64@lists.gentoo.org mailing list
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [gentoo-amd64] Problem with latest timezone update?
2008-01-15 15:22 [gentoo-amd64] Problem with latest timezone update? Mark Haney
@ 2008-01-15 16:45 ` Beso
2008-01-15 17:01 ` Drake Donahue
1 sibling, 0 replies; 17+ messages in thread
From: Beso @ 2008-01-15 16:45 UTC (permalink / raw
To: gentoo-amd64
[-- Attachment #1: Type: text/plain, Size: 1239 bytes --]
well, do this:
add to ntpd a dependence of net.ethx so that it doesn't starts if it this
service didn't start. after that go to http://wwp.greenwichmeantime.com and
sync your time, and put to 0.000000 the first number in the /etc/adjtime
file. after that if our pc doesn't automatically sync it would be have been
sync.
2008/1/15, Mark Haney <mhaney@ercbroadband.org>:
>
> Okay, here's something I can't seem to figure out. My laptop time
> doesn't want to stay sync'd. I always run ntpd at boot time to keep it
> in sync, but now, when I boot without an ethernet cable hooked up, it's
> over 5 hours off. It didn't do this until I updated the timezone just
> after Christmas. /etc/conf.d/clock is set to my timezone (EST5EDT) and
> /etc/localtime is symlinked to the correct timezone.
>
> I thought maybe the BIOS clock was wrong, but it's not 5 hours off,
> maybe a minute or so. I tried setting the HWclock to system time and
> that didn't fix it. Any ideas on what else to try?
>
> --
> Recedite, plebes! Gero rem imperialem!
>
>
> Mark Haney
> Sr. Systems Administrator
> ERC Broadband
> (828) 350-2415
>
> Call (866) ERC-7110 for after hours support
> --
> gentoo-amd64@lists.gentoo.org mailing list
>
>
--
dott. ing. beso
[-- Attachment #2: Type: text/html, Size: 1750 bytes --]
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [gentoo-amd64] Problem with latest timezone update?
2008-01-15 15:22 [gentoo-amd64] Problem with latest timezone update? Mark Haney
2008-01-15 16:45 ` Beso
@ 2008-01-15 17:01 ` Drake Donahue
2008-01-16 13:09 ` Mark Haney
1 sibling, 1 reply; 17+ messages in thread
From: Drake Donahue @ 2008-01-15 17:01 UTC (permalink / raw
To: gentoo-amd64
----- Original Message -----
From: "Mark Haney" <mhaney@ercbroadband.org>
To: <gentoo-amd64@lists.gentoo.org>
Sent: Tuesday, January 15, 2008 10:22 AM
Subject: [gentoo-amd64] Problem with latest timezone update?
> Okay, here's something I can't seem to figure out. My laptop time
> doesn't want to stay sync'd. I always run ntpd at boot time to keep it
> in sync, but now, when I boot without an ethernet cable hooked up, it's
> over 5 hours off. It didn't do this until I updated the timezone just
> after Christmas. /etc/conf.d/clock is set to my timezone (EST5EDT) and
> /etc/localtime is symlinked to the correct timezone.
>
> I thought maybe the BIOS clock was wrong, but it's not 5 hours off,
> maybe a minute or so. I tried setting the HWclock to system time and
> that didn't fix it. Any ideas on what else to try?
>
Could it be this simple? Quoting:
# /etc/conf.d/clock
# Set CLOCK to "UTC" if your system clock is set to UTC (also known as
# Greenwich Mean Time). If your clock is set to the local time, then
# set CLOCK to "local". Note that if you dual boot with Windows, then
# you should set it to "local".
CLOCK="local"
> --
> Recedite, plebes! Gero rem imperialem!
>
>
> Mark Haney
> Sr. Systems Administrator
> ERC Broadband
> (828) 350-2415
>
> Call (866) ERC-7110 for after hours support
> --
> gentoo-amd64@lists.gentoo.org mailing list
>
--
gentoo-amd64@lists.gentoo.org mailing list
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [gentoo-amd64] Problem with latest timezone update?
2008-01-15 17:01 ` Drake Donahue
@ 2008-01-16 13:09 ` Mark Haney
2008-01-16 17:49 ` Mark Knecht
0 siblings, 1 reply; 17+ messages in thread
From: Mark Haney @ 2008-01-16 13:09 UTC (permalink / raw
To: gentoo-amd64
Drake Donahue wrote:
>
> ----- Original Message ----- From: "Mark Haney" <mhaney@ercbroadband.org>
> To: <gentoo-amd64@lists.gentoo.org>
> Sent: Tuesday, January 15, 2008 10:22 AM
> Subject: [gentoo-amd64] Problem with latest timezone update?
>
>
>> Okay, here's something I can't seem to figure out. My laptop time
>> doesn't want to stay sync'd. I always run ntpd at boot time to keep
>> it in sync, but now, when I boot without an ethernet cable hooked up,
>> it's over 5 hours off. It didn't do this until I updated the timezone
>> just after Christmas. /etc/conf.d/clock is set to my timezone
>> (EST5EDT) and /etc/localtime is symlinked to the correct timezone.
>>
>> I thought maybe the BIOS clock was wrong, but it's not 5 hours off,
>> maybe a minute or so. I tried setting the HWclock to system time and
>> that didn't fix it. Any ideas on what else to try?
>>
> Could it be this simple? Quoting:
>
> # /etc/conf.d/clock
>
> # Set CLOCK to "UTC" if your system clock is set to UTC (also known as
> # Greenwich Mean Time). If your clock is set to the local time, then #
> set CLOCK to "local". Note that if you dual boot with Windows, then #
> you should set it to "local".
>
> CLOCK="local"
>
Yeah it could very well be. I didn't notice that before, but for some
reason this file was changed. It's possible I did it and not realize
it, but I was almost certain that I didn't update that file when I ran
dispatch-conf. But then again, one of my other personalities might have
done it. I'll have to ask around and see which one could have been the
perp. Thanks for picking that up.
--
Libenter homines id quod volunt credunt -- Caius Julius Caesar
Mark Haney
Sr. Systems Administrator
ERC Broadband
(828) 350-2415
Call (866) ERC-7110 for after hours support
--
gentoo-amd64@lists.gentoo.org mailing list
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [gentoo-amd64] Problem with latest timezone update?
2008-01-16 13:09 ` Mark Haney
@ 2008-01-16 17:49 ` Mark Knecht
2008-01-16 17:57 ` Mark Knecht
0 siblings, 1 reply; 17+ messages in thread
From: Mark Knecht @ 2008-01-16 17:49 UTC (permalink / raw
To: gentoo-amd64
On Jan 16, 2008 5:09 AM, Mark Haney <mhaney@ercbroadband.org> wrote:
> Drake Donahue wrote:
> >
> > ----- Original Message ----- From: "Mark Haney" <mhaney@ercbroadband.org>
> > To: <gentoo-amd64@lists.gentoo.org>
> > Sent: Tuesday, January 15, 2008 10:22 AM
> > Subject: [gentoo-amd64] Problem with latest timezone update?
> >
> >
> >> Okay, here's something I can't seem to figure out. My laptop time
> >> doesn't want to stay sync'd. I always run ntpd at boot time to keep
> >> it in sync, but now, when I boot without an ethernet cable hooked up,
> >> it's over 5 hours off. It didn't do this until I updated the timezone
> >> just after Christmas. /etc/conf.d/clock is set to my timezone
> >> (EST5EDT) and /etc/localtime is symlinked to the correct timezone.
> >>
> >> I thought maybe the BIOS clock was wrong, but it's not 5 hours off,
> >> maybe a minute or so. I tried setting the HWclock to system time and
> >> that didn't fix it. Any ideas on what else to try?
> >>
> > Could it be this simple? Quoting:
> >
> > # /etc/conf.d/clock
> >
> > # Set CLOCK to "UTC" if your system clock is set to UTC (also known as
> > # Greenwich Mean Time). If your clock is set to the local time, then #
> > set CLOCK to "local". Note that if you dual boot with Windows, then #
> > you should set it to "local".
> >
> > CLOCK="local"
> >
>
> Yeah it could very well be. I didn't notice that before, but for some
> reason this file was changed. It's possible I did it and not realize
> it, but I was almost certain that I didn't update that file when I ran
> dispatch-conf. But then again, one of my other personalities might have
> done it. I'll have to ask around and see which one could have been the
> perp. Thanks for picking that up.
>
I'm having problems after an emerge -DuN system this morning. What's
the proper solution to this?
dragonfly ~ # date
Wed Jan 16 17:45:44 Local time zone must be set--see zic manual page 2008
dragonfly ~ #
My mythbackend server is Linux only. The clock line is currently set
to UTC. timezone is Los Angeles as it's always been. It's 9:45 as I
write this but the clock thinks it's 17:45. 8 hours ahead is GMT,
right?
The hardware clock seems to be on GMT:
dragonfly ~ # hwclock -r
Wed Jan 16 17:46:35 2008 -0.584758 seconds
dragonfly ~ #
It seems the localtime file is messed up?
dragonfly ~ # cat /usr/share/zoneinfo/localtime
TZif21Local time zone must be set--see zic manual pageTZif21Local time
zone must be set--see zic manual page
<Local time zone must be set--see zic manual page>0
dragonfly ~ #
Isn't that supposed to be a link to Los_Angeles in my case? Going to
check the latest install docs.
- Mark
--
gentoo-amd64@lists.gentoo.org mailing list
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [gentoo-amd64] Problem with latest timezone update?
2008-01-16 17:49 ` Mark Knecht
@ 2008-01-16 17:57 ` Mark Knecht
2008-01-16 19:33 ` Beso
0 siblings, 1 reply; 17+ messages in thread
From: Mark Knecht @ 2008-01-16 17:57 UTC (permalink / raw
To: gentoo-amd64
On Jan 16, 2008 9:49 AM, Mark Knecht <markknecht@gmail.com> wrote:
>
> On Jan 16, 2008 5:09 AM, Mark Haney <mhaney@ercbroadband.org> wrote:
> > Drake Donahue wrote:
> > >
> > > ----- Original Message ----- From: "Mark Haney" <mhaney@ercbroadband.org>
> > > To: <gentoo-amd64@lists.gentoo.org>
> > > Sent: Tuesday, January 15, 2008 10:22 AM
> > > Subject: [gentoo-amd64] Problem with latest timezone update?
> > >
> > >
> > >> Okay, here's something I can't seem to figure out. My laptop time
> > >> doesn't want to stay sync'd. I always run ntpd at boot time to keep
> > >> it in sync, but now, when I boot without an ethernet cable hooked up,
> > >> it's over 5 hours off. It didn't do this until I updated the timezone
> > >> just after Christmas. /etc/conf.d/clock is set to my timezone
> > >> (EST5EDT) and /etc/localtime is symlinked to the correct timezone.
> > >>
> > >> I thought maybe the BIOS clock was wrong, but it's not 5 hours off,
> > >> maybe a minute or so. I tried setting the HWclock to system time and
> > >> that didn't fix it. Any ideas on what else to try?
> > >>
> > > Could it be this simple? Quoting:
> > >
> > > # /etc/conf.d/clock
> > >
> > > # Set CLOCK to "UTC" if your system clock is set to UTC (also known as
> > > # Greenwich Mean Time). If your clock is set to the local time, then #
> > > set CLOCK to "local". Note that if you dual boot with Windows, then #
> > > you should set it to "local".
> > >
> > > CLOCK="local"
> > >
> >
> > Yeah it could very well be. I didn't notice that before, but for some
> > reason this file was changed. It's possible I did it and not realize
> > it, but I was almost certain that I didn't update that file when I ran
> > dispatch-conf. But then again, one of my other personalities might have
> > done it. I'll have to ask around and see which one could have been the
> > perp. Thanks for picking that up.
> >
>
> I'm having problems after an emerge -DuN system this morning. What's
> the proper solution to this?
>
> dragonfly ~ # date
> Wed Jan 16 17:45:44 Local time zone must be set--see zic manual page 2008
> dragonfly ~ #
>
> My mythbackend server is Linux only. The clock line is currently set
> to UTC. timezone is Los Angeles as it's always been. It's 9:45 as I
> write this but the clock thinks it's 17:45. 8 hours ahead is GMT,
> right?
>
> The hardware clock seems to be on GMT:
>
> dragonfly ~ # hwclock -r
> Wed Jan 16 17:46:35 2008 -0.584758 seconds
> dragonfly ~ #
>
> It seems the localtime file is messed up?
>
> dragonfly ~ # cat /usr/share/zoneinfo/localtime
> TZif21Local time zone must be set--see zic manual pageTZif21Local time
> zone must be set--see zic manual page
> <Local time zone must be set--see zic manual page>0
> dragonfly ~ #
>
> Isn't that supposed to be a link to Los_Angeles in my case? Going to
> check the latest install docs.
>
> - Mark
>
OK, the timezone update wiped out the /etc/localtime file. From the
kernel config page:
http://www.gentoo.org/doc/en/handbook/handbook-x86.xml?part=1&chap=7
it tells me to copy Los_Angeles to /etc/localtime. After I did that I
see this with date:
dragonfly ~ # date
Wed Jan 16 09:55:51 PST 2008
dragonfly ~ #
- Mark
--
gentoo-amd64@lists.gentoo.org mailing list
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [gentoo-amd64] Problem with latest timezone update?
2008-01-16 17:57 ` Mark Knecht
@ 2008-01-16 19:33 ` Beso
2008-01-16 23:01 ` Steev Klimaszewski
0 siblings, 1 reply; 17+ messages in thread
From: Beso @ 2008-01-16 19:33 UTC (permalink / raw
To: gentoo-amd64
[-- Attachment #1: Type: text/plain, Size: 3672 bytes --]
that's one reason to use dispatch-conf over etc-update... at least you have
the diff on the files that are to be modified and you can chose what to do
file per file...
2008/1/16, Mark Knecht <markknecht@gmail.com>:
>
> On Jan 16, 2008 9:49 AM, Mark Knecht <markknecht@gmail.com> wrote:
> >
> > On Jan 16, 2008 5:09 AM, Mark Haney <mhaney@ercbroadband.org> wrote:
> > > Drake Donahue wrote:
> > > >
> > > > ----- Original Message ----- From: "Mark Haney" <
> mhaney@ercbroadband.org>
> > > > To: <gentoo-amd64@lists.gentoo.org>
> > > > Sent: Tuesday, January 15, 2008 10:22 AM
> > > > Subject: [gentoo-amd64] Problem with latest timezone update?
> > > >
> > > >
> > > >> Okay, here's something I can't seem to figure out. My laptop time
> > > >> doesn't want to stay sync'd. I always run ntpd at boot time to
> keep
> > > >> it in sync, but now, when I boot without an ethernet cable hooked
> up,
> > > >> it's over 5 hours off. It didn't do this until I updated the
> timezone
> > > >> just after Christmas. /etc/conf.d/clock is set to my timezone
> > > >> (EST5EDT) and /etc/localtime is symlinked to the correct timezone.
> > > >>
> > > >> I thought maybe the BIOS clock was wrong, but it's not 5 hours off,
> > > >> maybe a minute or so. I tried setting the HWclock to system time
> and
> > > >> that didn't fix it. Any ideas on what else to try?
> > > >>
> > > > Could it be this simple? Quoting:
> > > >
> > > > # /etc/conf.d/clock
> > > >
> > > > # Set CLOCK to "UTC" if your system clock is set to UTC (also known
> as
> > > > # Greenwich Mean Time). If your clock is set to the local time,
> then #
> > > > set CLOCK to "local". Note that if you dual boot with Windows, then
> #
> > > > you should set it to "local".
> > > >
> > > > CLOCK="local"
> > > >
> > >
> > > Yeah it could very well be. I didn't notice that before, but for some
> > > reason this file was changed. It's possible I did it and not realize
> > > it, but I was almost certain that I didn't update that file when I ran
> > > dispatch-conf. But then again, one of my other personalities might
> have
> > > done it. I'll have to ask around and see which one could have been
> the
> > > perp. Thanks for picking that up.
> > >
> >
> > I'm having problems after an emerge -DuN system this morning. What's
> > the proper solution to this?
> >
> > dragonfly ~ # date
> > Wed Jan 16 17:45:44 Local time zone must be set--see zic manual page
> 2008
> > dragonfly ~ #
> >
> > My mythbackend server is Linux only. The clock line is currently set
> > to UTC. timezone is Los Angeles as it's always been. It's 9:45 as I
> > write this but the clock thinks it's 17:45. 8 hours ahead is GMT,
> > right?
> >
> > The hardware clock seems to be on GMT:
> >
> > dragonfly ~ # hwclock -r
> > Wed Jan 16 17:46:35 2008 -0.584758 seconds
> > dragonfly ~ #
> >
> > It seems the localtime file is messed up?
> >
> > dragonfly ~ # cat /usr/share/zoneinfo/localtime
> > TZif21Local time zone must be set--see zic manual pageTZif21Local time
> > zone must be set--see zic manual page
> > <Local time zone must be set--see zic manual page>0
> > dragonfly ~ #
> >
> > Isn't that supposed to be a link to Los_Angeles in my case? Going to
> > check the latest install docs.
> >
> > - Mark
> >
> OK, the timezone update wiped out the /etc/localtime file. From the
> kernel config page:
>
> http://www.gentoo.org/doc/en/handbook/handbook-x86.xml?part=1&chap=7
>
> it tells me to copy Los_Angeles to /etc/localtime. After I did that I
> see this with date:
>
> dragonfly ~ # date
> Wed Jan 16 09:55:51 PST 2008
> dragonfly ~ #
>
> - Mark
> --
> gentoo-amd64@lists.gentoo.org mailing list
>
>
--
dott. ing. beso
[-- Attachment #2: Type: text/html, Size: 5083 bytes --]
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [gentoo-amd64] Problem with latest timezone update?
2008-01-16 19:33 ` Beso
@ 2008-01-16 23:01 ` Steev Klimaszewski
2008-01-17 0:56 ` Drake Donahue
0 siblings, 1 reply; 17+ messages in thread
From: Steev Klimaszewski @ 2008-01-16 23:01 UTC (permalink / raw
To: gentoo-amd64
On Wed, 2008-01-16 at 19:33 +0000, Beso wrote:
> that's one reason to use dispatch-conf over etc-update... at least you
> have the diff on the files that are to be modified and you can chose
> what to do file per file...
Except that neither etc-update nor dispatch-conf touch
the /etc/localtime file...
--
gentoo-amd64@lists.gentoo.org mailing list
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [gentoo-amd64] Problem with latest timezone update?
2008-01-16 23:01 ` Steev Klimaszewski
@ 2008-01-17 0:56 ` Drake Donahue
2008-01-17 1:37 ` Mark Knecht
0 siblings, 1 reply; 17+ messages in thread
From: Drake Donahue @ 2008-01-17 0:56 UTC (permalink / raw
To: gentoo-amd64
----- Original Message -----
From: "Steev Klimaszewski" <steev@gentoo.org>
To: <gentoo-amd64@lists.gentoo.org>
Sent: Wednesday, January 16, 2008 6:01 PM
Subject: Re: [gentoo-amd64] Problem with latest timezone update?
<snip>
> Except that neither etc-update nor dispatch-conf touch
> the /etc/localtime file...
>
True, but...
The files that are (maybe) affected directly by etc-update and/or
dispatch-conf are /etc/conf.d/clock and /etc/init.d/clock. ('maybe' is used
because: an emerge update must have affected one or both files; etc-update
and/or dispatch-conf must have been invoked by the user; the user must have
chosen action that resulted in a change to one or both files.
/etc/conf.d/clock is the configuration file for /etc/init.d/clock.
When /etc/init.d/clock runs (normally at boot), /etc/conf.d/clock is read.
If CLOCK="UTC" is not set in /etc/conf.d/clock, the option --localtime is
used and TBLURB="Local Time" is set.
The /etc/localtime file is a copy of one of the binary files in
/usr/share/zoneinfo made by the system installer initially; it is subject to
update by repeating the manual copy process anytime after system install.
Thus etc-update and/or dispatch-conf can't change localtime; but can change
whether localtime runs or not.
--
> gentoo-amd64@lists.gentoo.org mailing list
>
--
gentoo-amd64@lists.gentoo.org mailing list
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [gentoo-amd64] Problem with latest timezone update?
2008-01-17 0:56 ` Drake Donahue
@ 2008-01-17 1:37 ` Mark Knecht
2008-01-17 10:15 ` Nicolas Litchinko
2008-01-17 15:24 ` Drake Donahue
0 siblings, 2 replies; 17+ messages in thread
From: Mark Knecht @ 2008-01-17 1:37 UTC (permalink / raw
To: gentoo-amd64
On Jan 16, 2008 4:56 PM, Drake Donahue <donahue95@comcast.net> wrote:
>
> ----- Original Message -----
> From: "Steev Klimaszewski" <steev@gentoo.org>
> To: <gentoo-amd64@lists.gentoo.org>
> Sent: Wednesday, January 16, 2008 6:01 PM
> Subject: Re: [gentoo-amd64] Problem with latest timezone update?
>
>
> <snip>
>
> > Except that neither etc-update nor dispatch-conf touch
> > the /etc/localtime file...
> >
>
> True, but...
> The files that are (maybe) affected directly by etc-update and/or
> dispatch-conf are /etc/conf.d/clock and /etc/init.d/clock. ('maybe' is used
> because: an emerge update must have affected one or both files; etc-update
> and/or dispatch-conf must have been invoked by the user; the user must have
> chosen action that resulted in a change to one or both files.
> /etc/conf.d/clock is the configuration file for /etc/init.d/clock.
> When /etc/init.d/clock runs (normally at boot), /etc/conf.d/clock is read.
> If CLOCK="UTC" is not set in /etc/conf.d/clock,
UTC was set...
> the option --localtime is
> used and TBLURB="Local Time" is set.
> The /etc/localtime file is a copy of one of the binary files in
> /usr/share/zoneinfo made by the system installer
installer == Mark, me the guy who built the system, correct?
> initially; it is subject to
> update by repeating the manual copy process anytime after system install.
Which is what I did today to fix this problem.
> Thus etc-update and/or dispatch-conf can't change localtime; but can change
> whether localtime runs or not.
Humm...seems like what you say is true but doesn't explain how emerge
-DuN system changed the file. It was clearly changed since I could
look inside with vi and compare to the Los_Angeles file and see that
they were clearly different...
Thanks,
Mark
--
gentoo-amd64@lists.gentoo.org mailing list
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [gentoo-amd64] Problem with latest timezone update?
2008-01-17 1:37 ` Mark Knecht
@ 2008-01-17 10:15 ` Nicolas Litchinko
2008-01-17 12:36 ` Peter Humphrey
2008-01-17 15:08 ` Mark Knecht
2008-01-17 15:24 ` Drake Donahue
1 sibling, 2 replies; 17+ messages in thread
From: Nicolas Litchinko @ 2008-01-17 10:15 UTC (permalink / raw
To: gentoo-amd64
Hi,
On Wed, Jan 16, 2008 at 05:37:21PM -0800, Mark Knecht wrote:
> On Jan 16, 2008 4:56 PM, Drake Donahue <donahue95@comcast.net> wrote:
> > Thus etc-update and/or dispatch-conf can't change localtime; but can change
> > whether localtime runs or not.
>
> Humm...seems like what you say is true but doesn't explain how emerge
> -DuN system changed the file. It was clearly changed since I could
> look inside with vi and compare to the Los_Angeles file and see that
> they were clearly different...
There's a variable in /etc/conf.d/clock that controls whether or not
/etc/localtime should be updated when a new version of
sys-libs/timezone-data is merged: TIMEZONE. If this variable is set, the
specified timezone data file is copied over /etc/localtime.
as you can read in /etc/conf.d/clock:
# Select the proper timezone. For valid values, peek inside of the
# /usr/share/zoneinfo/ directory. For example, some common values are
# "America/New_York" or "EST5EDT" or "Europe/Berlin". If you want to
# manage /etc/localtime yourself, set this to "".
If TIMEZONE is not set, /etc/localtime is not updated by
sys-libs/timezone-data. However, if TIMEZONE is set to an invalid value,
then /etc/localtime is overwritten by the "Factory" timezone data file.
etc-update has probably changed the value of this variable after a
baselayout update. Then a timezone-data update used the wrong value to
update /etc/localtime. In your, case, the value of TIMEZONE should be
TIMEZONE="America/Los_Angeles".
--
Nicolas Litchinko
BOFH excuse #348:
We're on Token Ring, and it looks like the token got loose.
--
gentoo-amd64@lists.gentoo.org mailing list
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [gentoo-amd64] Problem with latest timezone update?
2008-01-17 10:15 ` Nicolas Litchinko
@ 2008-01-17 12:36 ` Peter Humphrey
2008-01-17 15:08 ` Mark Knecht
1 sibling, 0 replies; 17+ messages in thread
From: Peter Humphrey @ 2008-01-17 12:36 UTC (permalink / raw
To: gentoo-amd64
On Thursday 17 January 2008 10:15:12 Nicolas Litchinko wrote:
> There's a variable in /etc/conf.d/clock that controls whether or not
> /etc/localtime should be updated when a new version of
> sys-libs/timezone-data is merged: TIMEZONE. If this variable is set, the
> specified timezone data file is copied over /etc/localtime.
>
> as you can read in /etc/conf.d/clock:
> # Select the proper timezone. For valid values, peek inside of the
> # /usr/share/zoneinfo/ directory. For example, some common values are
> # "America/New_York" or "EST5EDT" or "Europe/Berlin". If you want to
> # manage /etc/localtime yourself, set this to "".
>
> If TIMEZONE is not set, /etc/localtime is not updated by
> sys-libs/timezone-data. However, if TIMEZONE is set to an invalid value,
> then /etc/localtime is overwritten by the "Factory" timezone data file.
That's useful - thanks.
Now, how do I prevent /etc/init.d/clock being run at boot time? If I
command "rc-update del clock" it gets put back again at shutdown time.
My reason is that I want to run chrony on my network, for its smooth
adjustment of system time, and it can't work properly if another program
also changes the system time.
--
Rgds
Peter
--
gentoo-amd64@lists.gentoo.org mailing list
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [gentoo-amd64] Problem with latest timezone update?
2008-01-17 10:15 ` Nicolas Litchinko
2008-01-17 12:36 ` Peter Humphrey
@ 2008-01-17 15:08 ` Mark Knecht
2008-01-17 15:53 ` Drake Donahue
1 sibling, 1 reply; 17+ messages in thread
From: Mark Knecht @ 2008-01-17 15:08 UTC (permalink / raw
To: gentoo-amd64
On Jan 17, 2008 2:15 AM, Nicolas Litchinko <nicolas@litchinko.fr> wrote:
> Hi,
>
> On Wed, Jan 16, 2008 at 05:37:21PM -0800, Mark Knecht wrote:
> > On Jan 16, 2008 4:56 PM, Drake Donahue <donahue95@comcast.net> wrote:
> > > Thus etc-update and/or dispatch-conf can't change localtime; but can change
> > > whether localtime runs or not.
> >
> > Humm...seems like what you say is true but doesn't explain how emerge
> > -DuN system changed the file. It was clearly changed since I could
> > look inside with vi and compare to the Los_Angeles file and see that
> > they were clearly different...
>
> There's a variable in /etc/conf.d/clock that controls whether or not
> /etc/localtime should be updated when a new version of
> sys-libs/timezone-data is merged: TIMEZONE. If this variable is set, the
> specified timezone data file is copied over /etc/localtime.
>
> as you can read in /etc/conf.d/clock:
> # Select the proper timezone. For valid values, peek inside of the
> # /usr/share/zoneinfo/ directory. For example, some common values are
> # "America/New_York" or "EST5EDT" or "Europe/Berlin". If you want to
> # manage /etc/localtime yourself, set this to "".
>
> If TIMEZONE is not set, /etc/localtime is not updated by
> sys-libs/timezone-data. However, if TIMEZONE is set to an invalid value,
> then /etc/localtime is overwritten by the "Factory" timezone data file.
>
> etc-update has probably changed the value of this variable after a
> baselayout update. Then a timezone-data update used the wrong value to
> update /etc/localtime. In your, case, the value of TIMEZONE should be
> TIMEZONE="America/Los_Angeles".
>
> --
> Nicolas Litchinko
> BOFH excuse #348:
> We're on Token Ring, and it looks like the token got loose.
> --
> gentoo-amd64@lists.gentoo.org mailing list
>
>
OK, I buy it. My setup was missing the underscore:
dragonfly ~ # cat /etc/conf.d/clock | grep TIMEZONE
TIMEZONE="America/LosAngeles"
dragonfly ~ #
However time on the machine has been fine for the 2 years we've had
the machine. Has this been wrong the whole time and I jsut got lucky
or did someone possibly change the formatting?
Thanks for the clarification!
Cheers,
Mark
--
gentoo-amd64@lists.gentoo.org mailing list
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [gentoo-amd64] Problem with latest timezone update?
2008-01-17 1:37 ` Mark Knecht
2008-01-17 10:15 ` Nicolas Litchinko
@ 2008-01-17 15:24 ` Drake Donahue
1 sibling, 0 replies; 17+ messages in thread
From: Drake Donahue @ 2008-01-17 15:24 UTC (permalink / raw
To: gentoo-amd64
----- Original Message -----
From: "Mark Knecht" <markknecht@gmail.com>
To: <gentoo-amd64@lists.gentoo.org>
Sent: Wednesday, January 16, 2008 8:37 PM
Subject: Re: [gentoo-amd64] Problem with latest timezone update?
> On Jan 16, 2008 4:56 PM, Drake Donahue <donahue95@comcast.net> wrote:
>>
>> ----- Original Message -----
>> From: "Steev Klimaszewski" <steev@gentoo.org>
>> To: <gentoo-amd64@lists.gentoo.org>
>> Sent: Wednesday, January 16, 2008 6:01 PM
>> Subject: Re: [gentoo-amd64] Problem with latest timezone update?
>>
>>
>> <snip>
>>
>> > Except that neither etc-update nor dispatch-conf touch
>> > the /etc/localtime file...
>> >
>>
>> True, but...
>> The files that are (maybe) affected directly by etc-update and/or
>> dispatch-conf are /etc/conf.d/clock and /etc/init.d/clock. ('maybe' is
>> used
>> because: an emerge update must have affected one or both files;
>> etc-update
>> and/or dispatch-conf must have been invoked by the user; the user must
>> have
>> chosen action that resulted in a change to one or both files.
>> /etc/conf.d/clock is the configuration file for /etc/init.d/clock.
>> When /etc/init.d/clock runs (normally at boot), /etc/conf.d/clock is
>> read.
>> If CLOCK="UTC" is not set in /etc/conf.d/clock,
>
> UTC was set...
Now CLOCK="LOCAL" ?
>
>> the option --localtime is
>> used and TBLURB="Local Time" is set.
>> The /etc/localtime file is a copy of one of the binary files in
>> /usr/share/zoneinfo made by the system installer
>
> installer == Mark, me the guy who built the system, correct?
yes.
>
>> initially; it is subject to
>> update by repeating the manual copy process anytime after system install.
>
> Which is what I did today to fix this problem.
>
>> Thus etc-update and/or dispatch-conf can't change localtime; but can
>> change
>> whether localtime runs or not.
>
> Humm...seems like what you say is true but doesn't explain how emerge
> -DuN system changed the file. It was clearly changed since I could
> look inside with vi and compare to the Los_Angeles file and see that
> they were clearly different...
>
Probably the previous /etc/localtime file was a copy of PST8PDT.
IIRC the geographic file names are relatively recent in origin.
If the old localtime had PST8PDT and the new had Los_Angeles in the few
readable characters the difference is explained.
Alternatively:
The start and end of US daylight savings time changed effective 2007-2008.
This resulted in an update to PST8PDT and its cousins ( to Los_Angeles and
its geographic cousins also, if they existed before the change). The
timezone-data ebuild also has a series of more recent bugfixes.
As Nicholas explains the /sys-libs/timezone-data update ebuild should have
updated /usr/share/zoneinfo files to new versions.
The /sys-libs/timezone-data update ebuild should then have copied the new
version of the file named in /etc/conf/clock's TIMEZONE= statement from
/usr/share/zoneinfo to /etc/localtime.
If it did not succeed in updating /etc/localtime because TIMEZONE= was
blank, invalid, or not set, the old /etc/localtime would have contained
readable characters: ' Local time zone must be set -- see zic manual page'.
> Thanks,
> Mark
> --
> gentoo-amd64@lists.gentoo.org mailing list
>
--
gentoo-amd64@lists.gentoo.org mailing list
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [gentoo-amd64] Problem with latest timezone update?
2008-01-17 15:08 ` Mark Knecht
@ 2008-01-17 15:53 ` Drake Donahue
2008-01-17 17:20 ` Drake Donahue
0 siblings, 1 reply; 17+ messages in thread
From: Drake Donahue @ 2008-01-17 15:53 UTC (permalink / raw
To: gentoo-amd64
----- Original Message -----
From: "Mark Knecht" <markknecht@gmail.com>
To: <gentoo-amd64@lists.gentoo.org>
Sent: Thursday, January 17, 2008 10:08 AM
Subject: Re: [gentoo-amd64] Problem with latest timezone update?
> On Jan 17, 2008 2:15 AM, Nicolas Litchinko <nicolas@litchinko.fr> wrote:
>> Hi,
>>
>> On Wed, Jan 16, 2008 at 05:37:21PM -0800, Mark Knecht wrote:
>> > On Jan 16, 2008 4:56 PM, Drake Donahue <donahue95@comcast.net> wrote:
>> > > Thus etc-update and/or dispatch-conf can't change localtime; but can
>> > > change
>> > > whether localtime runs or not.
>> >
>> > Humm...seems like what you say is true but doesn't explain how emerge
>> > -DuN system changed the file. It was clearly changed since I could
>> > look inside with vi and compare to the Los_Angeles file and see that
>> > they were clearly different...
>>
>> There's a variable in /etc/conf.d/clock that controls whether or not
>> /etc/localtime should be updated when a new version of
>> sys-libs/timezone-data is merged: TIMEZONE. If this variable is set, the
>> specified timezone data file is copied over /etc/localtime.
>>
>> as you can read in /etc/conf.d/clock:
>> # Select the proper timezone. For valid values, peek inside of the
>> # /usr/share/zoneinfo/ directory. For example, some common values are
>> # "America/New_York" or "EST5EDT" or "Europe/Berlin". If you want to
>> # manage /etc/localtime yourself, set this to "".
>>
>> If TIMEZONE is not set, /etc/localtime is not updated by
>> sys-libs/timezone-data. However, if TIMEZONE is set to an invalid value,
>> then /etc/localtime is overwritten by the "Factory" timezone data file.
>>
>> etc-update has probably changed the value of this variable after a
>> baselayout update. Then a timezone-data update used the wrong value to
>> update /etc/localtime. In your, case, the value of TIMEZONE should be
>> TIMEZONE="America/Los_Angeles".
>>
>> --
>> Nicolas Litchinko
>> BOFH excuse #348:
>> We're on Token Ring, and it looks like the token got loose.
>> --
>> gentoo-amd64@lists.gentoo.org mailing list
>>
>>
>
> OK, I buy it. My setup was missing the underscore:
>
> dragonfly ~ # cat /etc/conf.d/clock | grep TIMEZONE
> TIMEZONE="America/LosAngeles"
> dragonfly ~ #
>
> However time on the machine has been fine for the 2 years we've had
> the machine. Has this been wrong the whole time and I jsut got lucky
> or did someone possibly change the formatting?
Postulated sequence:
2 years ago, most probably, TIMEZONE="PST8PDT" was used.
All went well until a recent oops with etc-update or dispatch-conf, an
inadvertent CLOCK="UTC", which caused the clock to start keeping universal
time.
A similar problem discussed here reported a solution which included using
TIMEZONE="America/New_York" (I think, maybe America/Los_Angeles, maybe ...).
Having the same universal time problem, you adopted the geographic idea but
were then bitten by a typo.
Of note, the old TIMEZONE="EST5EDT" continues to work fine here.
>
> Thanks for the clarification!
>
> Cheers,
> Mark
> --
> gentoo-amd64@lists.gentoo.org mailing list
>
--
gentoo-amd64@lists.gentoo.org mailing list
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [gentoo-amd64] Problem with latest timezone update?
2008-01-17 15:53 ` Drake Donahue
@ 2008-01-17 17:20 ` Drake Donahue
2008-01-17 20:02 ` Beso
0 siblings, 1 reply; 17+ messages in thread
From: Drake Donahue @ 2008-01-17 17:20 UTC (permalink / raw
To: gentoo-amd64
OOPS and duh!
Just reread your original!
You want to be on universal time!
Abject apologies and nevermind.
As I read /etc/init.d/clock, setting CLOCK="UTC" should make /etc/localtime
irrelevant and unused.
If you are still having problems after the Los_Angeles change maybe
TIMEZONE="UTC" ?
--
gentoo-amd64@lists.gentoo.org mailing list
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [gentoo-amd64] Problem with latest timezone update?
2008-01-17 17:20 ` Drake Donahue
@ 2008-01-17 20:02 ` Beso
0 siblings, 0 replies; 17+ messages in thread
From: Beso @ 2008-01-17 20:02 UTC (permalink / raw
To: gentoo-amd64
[-- Attachment #1: Type: text/plain, Size: 897 bytes --]
i personally have the clock set to UTC and have kde clock set to local. this
in my opinion is the best choice and i think that every hw clock should be
set to UTC since it represents the computers' time in my opinion. every date
calculation is made converting to UTC and calculating the difference between
the UTC and the impute date converted. this is the right way to handle dates
and this, in my opinion, is the reason to why set the clock to the UTC.
2008/1/17, Drake Donahue <donahue95@comcast.net>:
>
> OOPS and duh!
> Just reread your original!
> You want to be on universal time!
> Abject apologies and nevermind.
>
> As I read /etc/init.d/clock, setting CLOCK="UTC" should make
> /etc/localtime
> irrelevant and unused.
> If you are still having problems after the Los_Angeles change maybe
> TIMEZONE="UTC" ?
>
> --
> gentoo-amd64@lists.gentoo.org mailing list
>
>
--
dott. ing. beso
[-- Attachment #2: Type: text/html, Size: 1251 bytes --]
^ permalink raw reply [flat|nested] 17+ messages in thread
end of thread, other threads:[~2008-01-17 20:02 UTC | newest]
Thread overview: 17+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2008-01-15 15:22 [gentoo-amd64] Problem with latest timezone update? Mark Haney
2008-01-15 16:45 ` Beso
2008-01-15 17:01 ` Drake Donahue
2008-01-16 13:09 ` Mark Haney
2008-01-16 17:49 ` Mark Knecht
2008-01-16 17:57 ` Mark Knecht
2008-01-16 19:33 ` Beso
2008-01-16 23:01 ` Steev Klimaszewski
2008-01-17 0:56 ` Drake Donahue
2008-01-17 1:37 ` Mark Knecht
2008-01-17 10:15 ` Nicolas Litchinko
2008-01-17 12:36 ` Peter Humphrey
2008-01-17 15:08 ` Mark Knecht
2008-01-17 15:53 ` Drake Donahue
2008-01-17 17:20 ` Drake Donahue
2008-01-17 20:02 ` Beso
2008-01-17 15:24 ` Drake Donahue
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox