Time errors

[bad sector]

I keep getting time errors and they're always equal to the timezone
offset in one direction or another. The BIOS is set to GMT and in Yast
GMT is set for the hardware clock while Eastern time is set for system.

For a while I was suspecting windows which is booted once a month but
this has nothing to do with windows. It happens between some reboots of
all my 12.2 and earlier systems, most often it results in the hardware
clock somehow getting reset. I even changed batteries but then realized
that the error was always equal to the zone offset so it cannot be a
battery issue either.

What could I investigate or keep an eye on to nail the culprit?

[John Bowling]

Have you set up a connection with NTP? Hardware clocks are still
identical to the very first ones put in when IBM created the AT, and they
drift. Having NTP setup will correct the time on boot and periodically
when you have a connection with the Internet.

If you do not have a valid Internet connection with NTP setup, it may
cause it to be way off.

John

[Sioux C. Queue]

On 10/26/2012 06:04 PM, bad sector wrote:
>
> I keep getting time errors

My date/time gizmo at the bottom right has gotten the incorrect time several
times. The timezone its set to somehow ends up wrong. I suspect that something
that's being patched is resetting it. Peeved me the first couple of times, but
now I know what to look at.

FWIW, oddly enough, I have a 64bitter 12.1 machine which has done it. Whereas
my wife has a 32bitter 12.1 machine which hasn't done it.

[unruh]

His symptoms are not of a drifting clock, but of one with a wrong
timezone setup.

Recall that if you have no time zone file (/etc/localtime) the clock
reverts to UTC. Thus you may want to make sure that /etc/localtime is a
copy of the correct tzdata file rather than a link.

[graham]

On Fri, 26 Oct 2012 22:04:14 -0400, bad sector wrote:

From forums.opensuse.org help.applications the thread
localtime,UTC,yast:"date and time"weirdness

quote
Before I start reading your long, long story, did you read: 'What is UTC
or GMT Time & a possible issue with openSUSE 12.2 and its solution. -
Blogs - openSUSE Forums' (http://tinyurl.com/8pjo2rg) ?
end quote

Hope this helps

[Dave Royal]

On Fri, 26 Oct 2012 22:04:14 -0400, bad sector wrote:

> I keep getting time errors and they're always equal to the timezone
> offset in one direction or another. The BIOS is set to GMT and in Yast
> GMT is set for the hardware clock while Eastern time is set for system.
>

I installed 12.2 on a machine that had been dual-boot, so the clock was
set to local time. SUSE defaulted to setting the clock to UT, which
should have been OK. But on reboot the time was always 1 hour out (BST=UT
+1 here in the UK). I concluded that SUSE was either setting the clock to
local time or not setting it at all.

So I went into the BIOS and changed the time to UT. That fixed it.

(Don't do what I did and accidentally change the date backwards; it was
in American Format and it went from 9th Ocober to 10th September. The
SUSE boot sequence crashed.)

Dave
--
(Remove any numerics from my email address.)

[ray]

On Fri, 26 Oct 2012 22:04:14 -0400, bad sector wrote:

How long has it been happening? It sounds to me like it might be bad
timezone data for DST.

[bad sector]

At times only the local time is messed up but at others something is
resetting my BIOS clock and it looks like by the exact zone offset
number of hours. This is what's perplexing, no OS has any business in
the BIOS except to read (last I heard). A wrong time zone setting should
just give me the equivalent of some other local time.

And it's not just a 12.2 issue, I've seen it before on 12.1 maybe even
earlier. I also boot different versions of linux back and forth but up
to now 80% of it has been different versions of OpenSUSE.

[Aragorn]

On Saturday 27 October 2012 18:39, houghi conveyed the following to
alt.os.linux.suse...

> ray wrote:
>
>> How long has it been happening? It sounds to me like it might be bad
>> timezone data for DST.
>

> Probably related to the fact that the timezone is GMT and not UCT.

Uhh, for all intents and purposes, GMT and UTC are the same thing. I'm
simply guessing that the OP chose to have the hardware clock set to
UTC/GMT in one distribution but to local time in another distribution.

OP is dual-booting between Windows and GNU/Linux. Windows expects the
hardware clock to be in local time, and if GNU/Linux considers the
hardware clock to be set in UTC/GMT, then there will always be an offset
after booting Windows, or another GNU/Linux distribution in which the
hardware clock is set up to be in local time.

--
= Aragorn =
(registered GNU/Linux user #223157)

[unruh]

Sure it does. The resetting of the RTC time is a job of the operating
system. Linux has lots of programs to do that (hwclock, ntpd,
chrony,....).

However at this point you have provided far too little information to
figure out what it is that you are doing or running for anyone to help.

Do you run ntpd, chrony, hwclock,....? What do you run?

> just give me the equivalent of some other local time.

And that is what you described.

>
> And it's not just a 12.2 issue, I've seen it before on 12.1 maybe even
> earlier. I also boot different versions of linux back and forth but up
> to now 80% of it has been different versions of OpenSUSE.

I have no idea where suse stores its info as to what timezone the rtc is
set for. Under Mandriva/mageia/redhat it is in /etc/sysconfig/clock
What do you have? What do you have for your /etc/localtime file? Is it a
link or a copy? etc.

>
>
>
>
>
>
>
>

[David]

You mentioned Windows. That likes the RTC to read local time, not
UTC/GMT and is your most likely culprit.
--
Regards
David Simpson
Sunday, 28 October 2012

%

Please, help defeat spammers!
Do not share your friends' email addresses.
Delete all old addresses.
Send bulk emails as BCC:
Many thanks.

[bad sector]

Thanks for all the wisdom gang, appreciate it !!!!!

I've been kind of busy with this needles to say..

I had seen this in conjunction with windows before but
as I said this time around windows was not involved.


Search for TIMEZONE= or UTC etc.
Sofar I have found:

Partition-1 = wXP

Partition-2 = w7

Partition-3 was w8 ..upgraded to Suse-12.2


Partition-8 Suse-12.2
=============
Yast, clock: hardware GMT, TZ=US-Eastern

/etc/sysconfig/clock
SYSTOHC=""
FORCE_SYSTOHC="no"
BADYEAR="no"
HCTOSYS_DEVICE=""
USE_HWCLOCK="yes"
USE_ADJUST="no"
TIMEZONE="America/New_York"
DEFAULT_TIMEZONE="US/Eastern"


Partition-9 Debian-6.0.5
========================
/etc/timezone
US/Eastern


Partition-10 Slackware-13.37
============================
haven't read into these yet
/usr/bin/mysqld_safe
/usr/sbin/timeconfig
/usr/lib64/build/acinclude.m4
/usr/share/apps/plasma_applet_ruby_clock/clockapplet.rb
/usr/doc/git-1.7.4.4/contrib/p4import/git-p4import.py
/usr/share/zsh/4.3.11/functions/_bzr
/usr/src/linux-2.6.37.6/drivers/sbus/char/uctrl.c



Partition-11 Suse-12.1
======================
/etc/sysconfig/clock
HWCLOCK="-u"
SYSTOHC=""
TIMEZONE="America/Montreal"
DEFAULT_TIMEZONE="US/Eastern"



Partition-13 Ubuntu-Studio-12.04
================================

/etc/init/hwclock.conf
# hwclock - adjust system clock and timezone
# The hwclock task adjusts the system clock when the hardware clock is
# set to localtime (e.g. when dual-booting with Windows), and also
# ensures that the system timezone is set so that timestamps
# are written to FAT devices.
description "adjust system clock and timezone"
start on starting mountall
task
script
. /etc/default/rcS
[ "$UTC" = "yes" ] && tz="--utc" || tz="--localtime"
[ "$BADYEAR" = "yes" ] && badyear="--badyear"
exec hwclock --systz $tz --noadjfile $badyear
end script



This last one looked guilty as sin just from looking at it
so I booted the bugger.

As soon as any time was shown I spotted 6:51 PM in the
top right on the panel, which should be 18:51 GMT if
all was right. It next became 2:51PM which "is" my
local time for 18:51 GMT. I remembered that some POS
was backing my BIOS clock (set to GMT) by zone offset
and THIS cought my eye. So I booted and sure enought,
THERE's a reset BIOS clock to 14:52 from 18:52.

So I reset the BIOS clock to GMT and rebooted but this
time pulled the wifi dongle (nice to have instant positive
physical control over such things). This time the time
shown was the same as GMT ..UNTIL I let the thing connect
with the net within seconds of which i backed the time down
to GMT-TZ-offset. I still don't have a problem with that
but I do have a biofg problem with software resetting my
BIOS clock to anything unless I asked for it.

I installed this thing ONLY to get rosegarden working &
don't remember what I set though I usually go for GMT
on hardware and local on system. I tried to find some
post-install time setting dialog but didn't see any so
I have no idea what the settings are or why it's doing
what it's doing.




what do you think of THIS (on alt.guitar)?

"Gibson is getting ready to release several exciting new
guitar lines, and so they've just *discontinued the majority
of their current USA-made* electric guitars".

I have a feeling curent means previous as in a renaming
orgy and little elese...

[bad sector]

On 10/27/2012 12:52 PM, Aragorn wrote:

Dept. of Corrections:

"within seconds of which _it_ backed the time down"

[Aragorn]

On Saturday 27 October 2012 21:26, bad sector conveyed the following to

alt.os.linux.suse...

> Thanks for all the wisdom gang, appreciate it !!!!!
>
> I've been kind of busy with this needles to say..
>
> On 10/27/2012 12:52 PM, Aragorn wrote:
>
>> On Saturday 27 October 2012 18:39, houghi conveyed the following to
>> alt.os.linux.suse...
>>
>>> ray wrote:
>>>
>>>> How long has it been happening? It sounds to me like it might be
>>>> bad timezone data for DST.
>>>
>>> Probably related to the fact that the timezone is GMT and not UCT.
>>
>> Uhh, for all intents and purposes, GMT and UTC are the same thing.
>> I'm simply guessing that the OP chose to have the hardware clock set
>> to UTC/GMT in one distribution but to local time in another
>> distribution.
>>
>> OP is dual-booting between Windows and GNU/Linux. Windows expects
>> the hardware clock to be in local time, and if GNU/Linux considers
>> the hardware clock to be set in UTC/GMT, then there will always be an
>> offset after booting Windows, or another GNU/Linux distribution in
>> which the hardware clock is set up to be in local time.
>
> I had seen this in conjunction with windows before but
> as I said this time around windows was not involved.
>

> [...]

>
> So I reset the BIOS clock to GMT and rebooted but this
> time pulled the wifi dongle (nice to have instant positive

> physical control over such things). [...]

Well, you seem to have found the culprit, but still, the golden rule is
to _not_ set the BIOS clock to GMT/UTC if you are dual-booting with
/any/ version of Windows, as Windows always expects the BIOS clock to be
in local time.

> what do you think of THIS (on alt.guitar)?
>
> "Gibson is getting ready to release several exciting new
> guitar lines, and so they've just *discontinued the majority
> of their current USA-made* electric guitars".

Uhh, I'm subscribed to Gibson's newsletters, and this is the first time
I hear something like that.

On the other hand, it is a sad fact that the quality of Gibson guitars
on the one hand and their MSRP on the other hand have been diverging for
several years now already, or to put it in layman's terms: the quality's
going down and the prices are going up.

For instance, you now get laminated fingerboards - due to Gibson's
trouble with the US DOJ and the resulting scarcity of rosewood in their
wood stocks - and acrylic fingerboard inlays instead of one-piece
fingerboards and real mother-of-pearl inlays. My Firebird VII was built
in 2001, and my Les Paul Standard Mahogany was built in 2002. My Pete
Townshend Signature SG Special was also built around that time. All
three still have real mother-of-pearl inlays. My Limited Edition SG
Standard and my SG-3 were built in 2007. They have acrylic inlays.

> I have a feeling curent means previous as in a renaming
> orgy and little elese...

I'm not sure what to make of it, but Gibson's management seems to have
taken a slide off the deep end a while ago already. It actually started
somewhere in 2004, when they sued PRS Guitars over an alleged plagiarism
of the Les Paul model in the PRS Single Cut. They lost that litigation.

Then, without any announcement whatsoever, they suddenly decided to
start chambering all Les Paul Standards, Classics and Studios as of mid
2006 - which effectively threw over 50 years of tradition and the legacy
of Les Paul himself out of the window - and then pretended like they had
been doing that all along since the 1980s, by deliberately blurring the
distinction between weight relief and dynamic sound chambers.

Then, they started issuing signature models for historically totally
insignificant artists like Chad Kroeger (of Nickelback) and the Jonas
Brothers. I can understand that they'd want to make a Pete Townshend
signature SG - there's a new one out now, but it's different from the
one I have, as this is an early 1960s model - or a Joan Jett signature
Melody Maker, or a Slash signature Les Paul, or an Ace Frehley signature
Les Paul Custom, or even a Buckethead Les Paul. But Chad Kroeger? The
Jonas Brothers? Come on guys, be serious! Who's next? Justin Bieber?
Shakira? <grin>

Another thing is that they're clearly outsourcing a lot of stuff now,
and automating a lot more too. They're now using TonePros bridges and
tailpieces, and Grover tuners - all quality stuff, no problem there -
and they're cutting the nuts and leveling, dressing and crowning the
frets with those expensive Plek machines - an investment they're
undoubtedly trying to earn back as fast as possible.

I've seen old documentaries of how Gibson guitars were built - and we're
talking Gibson USA production line guitars here, not Custom Shop guitars
- and only a few days ago, I've seen a more recent documentary. There's
very little stuff still done by hand anymore now. Most of it is done by
CNC machines now, and in genuine mass production style. They even put
RFID tags in them now.

I am proud, happy and fortunate that I own five Gibson guitars - all
Gibson USA models, no Custom Shop models - and those are all very fine
guitars, one by one - even the ones built in 2007. But the stuff
they're doing today, and the MSRPs on that... Well, let's just say that
I don't think I'll be buying a Gibson again anytime soon. Well, at the
moment I couldn't even afford one anymore, but I think you know what I
mean.

[Shmuel Metz]

In <CaudnSukib0rmRHN...@giganews.com>, on 10/27/2012

at 11:58 AM, bad sector <forgetski@postit_INVALID_.gov> said:

>This is what's perplexing, no OS has any business in
>the BIOS except to read

Resetting the CMOS clock is a legitimate OS function. Otherwise you'd
lose your time corrections after every power outage.

--
Shmuel (Seymour J.) Metz, SysProg and JOAT <http://patriot.net/~shmuel>

Unsolicited bulk E-mail subject to legal action. I reserve the
right to publicly post or ridicule any abusive E-mail. Reply to
domain Patriot dot net user shmuel+news to contact me. Do not
reply to spam...@library.lspace.org

[Paul J Gans]

Shmuel (Seymour J.) Metz <spam...@library.lspace.org.invalid> wrote:
>In <CaudnSukib0rmRHN...@giganews.com>, on 10/27/2012
> at 11:58 AM, bad sector <forgetski@postit_INVALID_.gov> said:

>>This is what's perplexing, no OS has any business in
>>the BIOS except to read

>Resetting the CMOS clock is a legitimate OS function. Otherwise you'd
>lose your time corrections after every power outage.

I believe that (at least in opensuse) that the hardware clock is
reset from the system clock on shutdown. I certainly get a message
to that effect on shutdown.

--
--- Paul J. Gans

[Shmuel Metz]

In <k6khc4$h4g$6...@reader1.panix.com>, on 10/29/2012

at 12:07 AM, Paul J Gans <gan...@panix.com> said:

>I believe that (at least in opensuse) that the hardware clock is
>reset from the system clock on shutdown.

Yes, and for good reason.

[Rajko M.]

On 10/26/2012 09:04 PM, bad sector wrote:
>
> I keep getting time errors and they're always equal to the timezone

> offset in one direction or another. ...

It is a bug that affects only those with dual boot with Windows prior to
version 7 that must use local time. Windows 7 is using UTC for hardware
clock. Vista has that option, but no user interface to set that. One
must dig in a registry to convince Vista to use UTC.

That can be explanation how this bug crept in a release. There is no
many XP and Vista computers around, users seldom boot Windows, so no one
noticed in time to fix thing.

Here is explanation:
https://bugzilla.novell.com/show_bug.cgi?id=779440

I used YaST clock settings, under Hardware menu, to set time right,
checked that time zone is right, OKed all, and when YaST was done, used
root console to issue command:

hwclock --systohc --localtime

this created file /etc/adjtime with necessary entry LOCAL that was
missing and ever since time does not jump around.

To add precision I activated ntpd that corrects clock for small drift
that each clock has.


--
Regards, Rajko.

[bad sector]

I don't use ntpd except exeptionaly :-) I could be wrong but seems to
me that the last time I tried it it just made things worse.

Thanks very much all the same, as I said in my OP windows was NOT
involved this time though it had been involved at other times. I'd love
to say it was windows but it's Ubuntu-Studio that was caught red handed
and I can duplicate the situation on demand (until I dump it or fix it).

It was interesting to watch that file being created though just
following your suggestion, how come yast doesn't create that file when
you set hardware to GMT and system to local?

And what does that file accomplish when OpenSuse is rebooted to a bios
clock that has already been reset to local by another (whichever) OS?
Won't it just compound the situation and slew local time off from what
is no longer GMT?

For my money the solution is for OS not to muck with hardware time at
all; if necessary as a result of nntp updates, which also should not
touch hardware, an alert could be fired at the user/admin suggesting the
hw clock be updated.

[bad sector]

It isn't new by any stretch of the imagination & I too have seen it lots
before but always attributed it to windows only because it was reputed
to do this. This time I nailed Ubuntu, it was resetting right before my
eyes on launching X. I'd like to get into Ubuntu to see why or how come
but I don't know it at all, don't see any immediately visible setting
facility, and my interest is even less (it won't be there for long now
that rosegarden works fine on os-12.2).

[Shmuel Metz]

In <m6GdnapM0bQU4BPN...@giganews.com>, on 10/29/2012

at 08:59 AM, bad sector <forgetski@postit_INVALID_.gov> said:

>For my money the solution is for OS not to muck with hardware time at
> all; if necessary as a result of nntp updates, which also should not
> touch hardware, an alert could be fired at the user/admin suggesting
>the hw clock be updated.

I can reset the time much more accurately with an NTP client than I
can with a wrist watch at boot time. Setting the clock is and ought to
be an OS function.

[unruh]

On 2012-10-30, Shmuel Metz <spam...@library.lspace.org.invalid> wrote:
> In <m6GdnapM0bQU4BPN...@giganews.com>, on 10/29/2012
> at 08:59 AM, bad sector <forgetski@postit_INVALID_.gov> said:
>
>>For my money the solution is for OS not to muck with hardware time at
>> all; if necessary as a result of nntp updates, which also should not
>> touch hardware, an alert could be fired at the user/admin suggesting
>>the hw clock be updated.

And since the OS is not to be able to touch the hardware clock, what in
the world is the user/admin supposed to do with that alert. They will
not be able to change the hardware clock because the OS cannot much with
hardware time.
If there is a user admin program to change the hardware time, then the
OS must have the ability to change it, and that ability can be used by
other programs as well.

>
> I can reset the time much more accurately with an NTP client than I
> can with a wrist watch at boot time. Setting the clock is and ought to
> be an OS function.
>

Either that or put up with the hardware time always being wrong.

[bad sector]

On 10/29/2012 08:44 PM, Shmuel (Seymour J.) Metz wrote:
> In <m6GdnapM0bQU4BPN...@giganews.com>, on 10/29/2012
> at 08:59 AM, bad sector <forgetski@postit_INVALID_.gov> said:
>
>> For my money the solution is for OS not to muck with hardware time at
>> all; if necessary as a result of nntp updates, which also should not
>> touch hardware, an alert could be fired at the user/admin suggesting
>> the hw clock be updated.
>
> I can reset the time much more accurately with an NTP client than I
> can with a wrist watch at boot time. Setting the clock is and ought to
> be an OS function.

How about this: anything on my computer should be what I want it to be?

The sysadmin who cannot reboot may want to opt for OS updating, but just
in passing how many of the OS'es in circulation are real multi user
systems as opposed to singles? These days I reboot 50 times a day easy
because I'm composing and whenever any member of the jack/zyn/rosegarden
trio flops its several reboots to straighten things out so resetting the
bios clock is not a problem. And if an OS were to ask me if I want to
fence the hardware clock out of bounds then the answer would be a
resounding yes. Second, who says that a computer is connected online as
a default condition at all?

Other than that I really don't give a fuck cause the time on my box can
be anything it wants to be, I ignore it anyway and have no real use for
it except when the Tor-bundle gets confused.

[unruh]

On 2012-10-30, bad sector <forgetski@postit_INVALID_.gov> wrote:
> On 10/29/2012 08:44 PM, Shmuel (Seymour J.) Metz wrote:
>> In <m6GdnapM0bQU4BPN...@giganews.com>, on 10/29/2012
>> at 08:59 AM, bad sector <forgetski@postit_INVALID_.gov> said:
>>
>>> For my money the solution is for OS not to muck with hardware time at
>>> all; if necessary as a result of nntp updates, which also should not
>>> touch hardware, an alert could be fired at the user/admin suggesting
>>> the hw clock be updated.
>>
>> I can reset the time much more accurately with an NTP client than I
>> can with a wrist watch at boot time. Setting the clock is and ought to
>> be an OS function.
>
> How about this: anything on my computer should be what I want it to be?

Well, yes, and that is what the the various rtc setting programs allow
you to do. Of course the probability that you come anywhere near your
claim is zero. That you actually know exactly what your video driver
does, or what your kernel does is or what the programs you run do is
zero. But fine.

>
> The sysadmin who cannot reboot may want to opt for OS updating, but just

ntpd by default resets the rtc every 11 minutes by telling the kernel
that the system time is good and the kernel resets the rtc in that mode.
If you want that not to happen, use chrony. Also make sure that you
never run Windows.

> in passing how many of the OS'es in circulation are real multi user
> systems as opposed to singles? These days I reboot 50 times a day easy

Most of them are, since the main feature of multiuser is the ability to
run multiple programs at once, and almost everyone wants that.

> because I'm composing and whenever any member of the jack/zyn/rosegarden
> trio flops its several reboots to straighten things out so resetting the

?????

> bios clock is not a problem. And if an OS were to ask me if I want to
> fence the hardware clock out of bounds then the answer would be a
> resounding yes. Second, who says that a computer is connected online as
> a default condition at all?

It is an extremely common condition. But you can tellit not to. It is
not at all clear who you think you are fighting.

>
> Other than that I really don't give a fuck cause the time on my box can
> be anything it wants to be, I ignore it anyway and have no real use for
> it except when the Tor-bundle gets confused.

Fine. Some people like to have their filesystems be consistant (ie later
created files have later timestamps) but if you do not care, that is
fine.

>
>

[bad sector]

On 10/30/2012 02:57 AM, unruh wrote:
> On 2012-10-30, bad sector <forgetski@postit_INVALID_.gov> wrote:

>> because I'm composing and whenever any member of the jack/zyn/rosegarden
>> trio flops its several reboots to straighten things out so resetting the
>
> ?????

I mean dozens of lockups per day if the referenced apps are used
together on 12.2 with all updates applied to date. No big deal, I'm used
to it, only cited the condition to show that rebooting is not the once a
month affair that would apply only to minoritary multi-(human)-user
systems. As far as I know most people reboot half a dozen or more times
every single day so there's ample opportunity for BIOS edits.

>> bios clock is not a problem. And if an OS were to ask me if I want to
>> fence the hardware clock out of bounds then the answer would be a
>> resounding yes. Second, who says that a computer is connected online as
>> a default condition at all?
>
> It is an extremely common condition. But you can tellit not to. It is
> not at all clear who you think you are fighting.

Being common is not a logical reason for it to be the default, most cars
come configured with the engine stopped by default. Anyway this
particular detail is of little significance IF the user has the choice.
I also advocate usb wifi because it gives the user nodelay positive
physical control over any and all network connection, something that's
increasingly hard to come by as time goes on.

>> Other than that I really don't give a fuck cause the time on my box can
>> be anything it wants to be, I ignore it anyway and have no real use for
>> it except when the Tor-bundle gets confused.
>
> Fine. Some people like to have their filesystems be consistant (ie later
> created files have later timestamps) but if you do not care, that is
> fine.

You might be over reacting, I see no problem with a few minutes of splay
as would possibly arise without continuous online updating nor do I know
of too many users who would. I have just demonstrated and can still
duplicate on demand what can and therefore did and will happen on my
Ubuntu installation i.e. the hardware clock being backed by several
hours. Argue it anyway you like THAT is what is and will always remain
totally UNACCEPTABLE.

[unruh]

On 2012-10-30, houghi <hou...@houghi.org.invalid> wrote:

> unruh wrote:
>> Either that or put up with the hardware time always being wrong.
>

> Define 'wrong'. ;-)

"Wrong" is a time different from the real time, or different from the
time you want the rtc to show.

> I know of a Unix sysadmin who needed almost identical times on two
> servers. Just using NTP made the time difference to much. No I do not
> know why anymore or what the solution was.

In which case the sysadmin was incompetent in his use of ntpd (which I
assume is what you meant).
>
> I just remember him telling that when they had identical times, they
> time was off to 'real' by about 30 minutes to an hour. But that was
> fine. They were not interested in 'real' time, just in identical times
> between the two machines.

Again, it sounds to me like incompetence. Note that I can keep two
machines on the same network to the same time and to UTC within 20 micro
seconds just using the network and to within 3 microseconds putting each
on a gps receiver. Anything better is impossible with commercial grade
computers. (and how in the world did he know that they had "almost
identical times"?)
The best way of ensuring identical times, is by ensuring that both show
UTC.


>
> houghi

[unruh]

On 2012-10-30, bad sector <forgetski@postit_INVALID_.gov> wrote:
> On 10/30/2012 02:57 AM, unruh wrote:
>> On 2012-10-30, bad sector <forgetski@postit_INVALID_.gov> wrote:
>
>>> because I'm composing and whenever any member of the jack/zyn/rosegarden
>>> trio flops its several reboots to straighten things out so resetting the
>>
>> ?????
>
> I mean dozens of lockups per day if the referenced apps are used
> together on 12.2 with all updates applied to date. No big deal, I'm used
> to it, only cited the condition to show that rebooting is not the once a
> month affair that would apply only to minoritary multi-(human)-user
> systems. As far as I know most people reboot half a dozen or more times
> every single day so there's ample opportunity for BIOS edits.

???? "Most people" do not reboot half a dozen times or more per day
unless they are using laptops, and if you are running rosegarden, etc on
a laptop, you deserve what you get:-)
All of my 9 machines of uptimes of months so clearly (by your logic)
most people have uptimes of months on their systems.

>
>>> bios clock is not a problem. And if an OS were to ask me if I want to
>>> fence the hardware clock out of bounds then the answer would be a
>>> resounding yes. Second, who says that a computer is connected online as
>>> a default condition at all?
>>
>> It is an extremely common condition. But you can tellit not to. It is
>> not at all clear who you think you are fighting.
>
> Being common is not a logical reason for it to be the default, most cars
> come configured with the engine stopped by default. Anyway this
> particular detail is of little significance IF the user has the choice.
> I also advocate usb wifi because it gives the user nodelay positive
> physical control over any and all network connection, something that's
> increasingly hard to come by as time goes on.

Your idea of computers and how to use them seems to me to have lost all
touch with reality. Yes, the user has a choice.
What does "gives the user nodelay positive physical control" mean? Usb
wireless devices are as variable as wifi cards,

>
>>> Other than that I really don't give a fuck cause the time on my box can
>>> be anything it wants to be, I ignore it anyway and have no real use for
>>> it except when the Tor-bundle gets confused.
>>
>> Fine. Some people like to have their filesystems be consistant (ie later
>> created files have later timestamps) but if you do not care, that is
>> fine.
>
> You might be over reacting, I see no problem with a few minutes of splay
> as would possibly arise without continuous online updating nor do I know
> of too many users who would. I have just demonstrated and can still
> duplicate on demand what can and therefore did and will happen on my
> Ubuntu installation i.e. the hardware clock being backed by several
> hours. Argue it anyway you like THAT is what is and will always remain
> totally UNACCEPTABLE.

Sorry, first you tell us that you do not care about the time on your
system, then you tell me you do.

The hardware clock is irrelevant to the running of the computer in
general. It is used to set the initial time only. However, some sound
software does use the rtc for music timing purposes. I have never
actually done so, so cannot advise on the details. This is becoming more
problematic as the rtc interrupt handling on linux has become very
flakey with the newer "rtc substitutes" like hpet.

>
>
>
>
>
>
>
>

[bad sector]

On 10/30/2012 12:37 PM, unruh wrote:
> On 2012-10-30, bad sector <forgetski@postit_INVALID_.gov> wrote:

>> I mean dozens of lockups per day if the referenced apps are used
>> together on 12.2 with all updates applied to date. No big deal,
>> I'm used to it, only cited the condition to show that rebooting is
>> not the once a month affair that would apply only to minoritary
>> multi-(human)-user systems. As far as I know most people reboot
>> half a dozen or more times every single day so there's ample
>> opportunity for BIOS edits.
>
> ???? "Most people" do not reboot half a dozen times or more per day

do a poll, it's that simple

> unless they are using laptops, and if you are running rosegarden,
> etc on a laptop, you deserve what you get:-)

I wouldn't say that my 17" i7/g73 with 8gb ram is superior to my desktop
mothership but it can certainly hold its own in terms of performance

> All of my 9 machines of uptimes of months so clearly (by your logic)
> most people have uptimes of months on their systems.

you're most people already? :-)

> Your idea of computers and how to use them seems to me to have lost
> all touch with reality. Yes, the user has a choice. What does "gives
> the user nodelay positive physical control" mean? Usb wireless
> devices are as variable as wifi cards,

It means that when you don't want connection you pull the dongle and the
connection is history. That may not be as easy with built-in wifi that
is mostly software controlled because there AGAIN the user has less and
less authority. Citing my g73 and another Asus portable as examples the
built-in wifi is Fn_key controlled HOWEVER the OS or other software can
AND DOES with INCREASING FREQUENCY override that so that, as most people
are unaware of, 'uncommanded network connection' which in my book is
always unacceptable is a daily occurrence which the user cannot easily
detect OR prevent.

> Sorry, first you tell us that you do not care about the time on your
> system, then you tell me you do.

Minor drift is of no consequence (to me) but hours' worth of software
clusterfucks are.

> The hardware clock is irrelevant to the running of the computer in
> general. It is used to set the initial time only.

If I set my hardware clock to GMT then *maybe* it's because I want it to
stay on GMT, but no matter how you look at it the cited backing of the
hardware clock to a time that isn't even on this planet from my
perspective is unacceptable. Address that issue instead.

> However, some sound software does use the rtc for music timing
> purposes. I have never actually done so, so cannot advise on the
> details. This is becoming more problematic as the rtc interrupt
> handling on linux has become very flakey with the newer "rtc
> substitutes" like hpet.

The lockups with rosegarden are related to rebootiong only, not to the
topic.

[unruh]

On 2012-10-30, houghi <hou...@houghi.org.invalid> wrote:
> unruh wrote:
>>> I know of a Unix sysadmin who needed almost identical times on two
>>> servers. Just using NTP made the time difference to much. No I do not
>>> know why anymore or what the solution was.
>>
>> In which case the sysadmin was incompetent in his use of ntpd (which I
>> assume is what you meant).
>

> No. NTP did not give enough identical times. I am not talking the same
> second here. Not sure what the acceptal error rate was. I do not even
> know what type of connection they had. I am not even sure if there was a
> network connection.

>
>> Again, it sounds to me like incompetence. Note that I can keep two
>> machines on the same network to the same time and to UTC within 20 micro
>> seconds just using the network and to within 3 microseconds putting each
>> on a gps receiver.
>

> I have no idea if they were on the same network. I know that GPS
> receiver was not an option. I do not know what the margin of acceptable
> error was.

I was giving you experimental facts. I also do not know what their
network topology was.

>
>> Anything better is impossible with commercial grade
>> computers. (and how in the world did he know that they had "almost
>> identical times"?)
>

> I have no idea.

>
>> The best way of ensuring identical times, is by ensuring that both show
>> UTC.
>

> In almost all cases it is. In this case it was not. In fact having UTC

I almost certainly do not believe that "in this case it was not".

> was irrelevant, apparently. What was of HIGHER importance was that they

Whether or not having utc is irrelevant is also irrelevant.

> had identical times. That was for them the right time.

As I said, in almost all cases, the best way to ensure that they have
identical times is to make sure that they are both synchronised to the
same time. The most convenient it UTC. But using A as an ntp server for
B would also work.


>
> Sure, it is easy to say what they should have done. Especialy if you
> (nor I) have any idea of the setup, of the hardware, of the goals.

Actually it is. both ntpd and chrony and the ntp protocol have been carefully designed to ensure
two computers have the same time to the greatest accuracy possible
(chrony is somewhat better than ntpd by factors of 3 or greater. This is
primarily because of the faster reaction of chrony to drift rate
changes.) . Any
other way of ensuring they have the same time is almost certainly going
to be much worse. So, I have no idea what he was talking about when he
says that "the same time" sacrificed synchronization with UTC.

IF his two systems were disconnected from the net or any other UTC time
source, then he could use ntp to synchronise them to each other, either
using orphan mode in ntpd, or having one act as a server for the other.




>
> houghi

[unruh]

On 2012-10-30, bad sector <forgetski@postit_INVALID_.gov> wrote:
> On 10/30/2012 12:37 PM, unruh wrote:
>> On 2012-10-30, bad sector <forgetski@postit_INVALID_.gov> wrote:
>
>>> I mean dozens of lockups per day if the referenced apps are used
>>> together on 12.2 with all updates applied to date. No big deal,
>>> I'm used to it, only cited the condition to show that rebooting is
>>> not the once a month affair that would apply only to minoritary
>>> multi-(human)-user systems. As far as I know most people reboot
>>> half a dozen or more times every single day so there's ample
>>> opportunity for BIOS edits.
>>
>> ???? "Most people" do not reboot half a dozen times or more per day
>
> do a poll, it's that simple

Go ahead. You made the claim. Back it up.

>
>> unless they are using laptops, and if you are running rosegarden,
>> etc on a laptop, you deserve what you get:-)
>
> I wouldn't say that my 17" i7/g73 with 8gb ram is superior to my desktop
> mothership but it can certainly hold its own in terms of performance
>
>> All of my 9 machines of uptimes of months so clearly (by your logic)
>> most people have uptimes of months on their systems.
>
> you're most people already? :-)

As much as you are.

>
>> Your idea of computers and how to use them seems to me to have lost
>> all touch with reality. Yes, the user has a choice. What does "gives
>> the user nodelay positive physical control" mean? Usb wireless
>> devices are as variable as wifi cards,
>
> It means that when you don't want connection you pull the dongle and the
> connection is history. That may not be as easy with built-in wifi that
> is mostly software controlled because there AGAIN the user has less and
> less authority. Citing my g73 and another Asus portable as examples the
> built-in wifi is Fn_key controlled HOWEVER the OS or other software can
> AND DOES with INCREASING FREQUENCY override that so that, as most people
> are unaware of, 'uncommanded network connection' which in my book is
> always unacceptable is a daily occurrence which the user cannot easily
> detect OR prevent.

On what system? I thought we were discussing linux.

>
>> Sorry, first you tell us that you do not care about the time on your
>> system, then you tell me you do.
>
> Minor drift is of no consequence (to me) but hours' worth of software
> clusterfucks are.

Ah so it is of importance.

>
>> The hardware clock is irrelevant to the running of the computer in
>> general. It is used to set the initial time only.
>
> If I set my hardware clock to GMT then *maybe* it's because I want it to
> stay on GMT, but no matter how you look at it the cited backing of the
> hardware clock to a time that isn't even on this planet from my
> perspective is unacceptable. Address that issue instead.

You apparently have the problem that you keep booting into Windows ( of
some unkown vintage) Since the assumptions about the rtc made by windows
and linux differ, you will have problems. You are also using sound
software, which may use the rtc for sound timing. You may also have
hardware problems with your rtc.

>
>> However, some sound software does use the rtc for music timing
>> purposes. I have never actually done so, so cannot advise on the
>> details. This is becoming more problematic as the rtc interrupt
>> handling on linux has become very flakey with the newer "rtc
>> substitutes" like hpet.
>
> The lockups with rosegarden are related to rebootiong only, not to the
> topic.

You know this how? The topic was the rtc. rosegarden I think uses the
rtc for sound timing purposes. rosegarden locks up. You know this is not
related to the rtc how?

>
>
>

[bad sector]

On 10/30/2012 03:35 PM, unruh wrote:
> On 2012-10-30, bad sector <forgetski@postit_INVALID_.gov> wrote:

>>> ???? "Most people" do not reboot half a dozen times or more per day
>> do a poll, it's that simple
> Go ahead. You made the claim. Back it up.

I don't need polls. I'm confident that there are many more computers in
the world that are not systems for several people to use but rather
household animals in the service of a single humanoid sometimes using
several user accounts.

>>> unless they are using laptops, and if you are running rosegarden,
>>> etc on a laptop, you deserve what you get:-)
>>
>> I wouldn't say that my 17" i7/g73 with 8gb ram is superior to my desktop
>> mothership but it can certainly hold its own in terms of performance
>>
>>> All of my 9 machines of uptimes of months so clearly (by your logic)
>>> most people have uptimes of months on their systems.
>>
>> you're most people already? :-)
>
> As much as you are.

I didn't base my opinion on what I do but what I observe around me;
within many km's I know of maybe a dozen multi-user systems and they're
all in the secondary schools or banks and such vs. tens of thousands in
homes in threes and fours in the same area.

>>> Your idea of computers and how to use them seems to me to have lost
>>> all touch with reality. Yes, the user has a choice. What does "gives
>>> the user nodelay positive physical control" mean? Usb wireless
>>> devices are as variable as wifi cards,
>>
>> It means that when you don't want connection you pull the dongle and the
>> connection is history. That may not be as easy with built-in wifi that
>> is mostly software controlled because there AGAIN the user has less and
>> less authority. Citing my g73 and another Asus portable as examples the
>> built-in wifi is Fn_key controlled HOWEVER the OS or other software can
>> AND DOES with INCREASING FREQUENCY override that so that, as most people
>> are unaware of, 'uncommanded network connection' which in my book is
>> always unacceptable is a daily occurrence which the user cannot easily
>> detect OR prevent.
>
> On what system? I thought we were discussing linux.

We are, read the OP, slowly this time for enlightment, I clearly state
that windows was NOT implicated in spite of its deservedly bad
reputation and later confirmed this once I discovered what (OS) the
cause was. One more time for the sake of harmony in the world and fewer
futile arguments:

I booted Ubuntu-Studio (not windows) and before my eyes it backed the
system time by some 4 hours as soon as it could connect to the net and
following shutdown it became evident that the hardware clock had also
been backed by the same amount. What's more I still have that
installation and can duplicate at any time for TS though at the moment I
feel no inclination to do so.

>> If I set my hardware clock to GMT then *maybe* it's because I want it to
>> stay on GMT, but no matter how you look at it the cited backing of the
>> hardware clock to a time that isn't even on this planet from my
>> perspective is unacceptable. Address that issue instead.
>
> You apparently have the problem that you keep booting into Windows ( of
> some unkown vintage) Since the assumptions about the rtc made by windows
> and linux differ, you will have problems. You are also using sound
> software, which may use the rtc for sound timing. You may also have
> hardware problems with your rtc.

3 versions of windows and a host of linux systems populate ALL of my
computers individually so any problem with the clock would have surfaced
by now not to mention that mechanical failure not being contagious it
would have done so only on the diseased machine.

>> The lockups with rosegarden are related to rebootiong only, not to the
>> topic.
>
> You know this how? The topic was the rtc. rosegarden I think uses the
> rtc for sound timing purposes. rosegarden locks up. You know this is not
> related to the rtc how?

No, the topic is *uncommanded time upset*, the hardware clock being the
component affected by *the problem*. If you have information to the
effect that beyond a tim-ING tool rosegarden actually cares about the
time of day or year then please don't hesitate to share with mortals :-)

[unruh]

On 2012-10-30, bad sector <forgetski@postit_INVALID_.gov> wrote:
> On 10/30/2012 03:35 PM, unruh wrote:
>> On 2012-10-30, bad sector <forgetski@postit_INVALID_.gov> wrote:
>
>>>> ???? "Most people" do not reboot half a dozen times or more per day
>>> do a poll, it's that simple
>> Go ahead. You made the claim. Back it up.
>
> I don't need polls. I'm confident that there are many more computers in
> the world that are not systems for several people to use but rather
> household animals in the service of a single humanoid sometimes using
> several user accounts.

OK, We then know what value to place on your gut feelings.

OK, so we have a reproducible problem. Please boot it into Ubuntu-Studio
with the network down. record the system time, the rtc time, and the
timezone. Now bring up the network. Report the system time, the rtc time
( using hwclock) and the timezone.

What network apps are you running? ntpd? chrony? what else.

>
>>> If I set my hardware clock to GMT then *maybe* it's because I want it to
>>> stay on GMT, but no matter how you look at it the cited backing of the
>>> hardware clock to a time that isn't even on this planet from my
>>> perspective is unacceptable. Address that issue instead.
>>
>> You apparently have the problem that you keep booting into Windows ( of
>> some unkown vintage) Since the assumptions about the rtc made by windows
>> and linux differ, you will have problems. You are also using sound
>> software, which may use the rtc for sound timing. You may also have
>> hardware problems with your rtc.
>
> 3 versions of windows and a host of linux systems populate ALL of my
> computers individually so any problem with the clock would have surfaced
> by now not to mention that mechanical failure not being contagious it
> would have done so only on the diseased machine.
>
>
>>> The lockups with rosegarden are related to rebootiong only, not to the
>>> topic.
>>
>> You know this how? The topic was the rtc. rosegarden I think uses the
>> rtc for sound timing purposes. rosegarden locks up. You know this is not
>> related to the rtc how?
>
> No, the topic is *uncommanded time upset*, the hardware clock being the
> component affected by *the problem*. If you have information to the
> effect that beyond a tim-ING tool rosegarden actually cares about the
> time of day or year then please don't hesitate to share with mortals :-)

no, I do not know. I do know (because you have told me) that you run
rosegarden on the affected machine and that it crashes often. That
machine also suffers from some sort of time instability. Are they
related? I have no idea. I cannot even try out ideas. You have to do
that.

The fact that the time instability appears to be related to network
connectivity is a clue (or perhaps a red herring).

[unruh]

On 2012-10-30, houghi <hou...@houghi.org.invalid> wrote:
> unruh wrote:
>> I was giving you experimental facts. I also do not know what their
>> network topology was.
>

> I am sure he was aware of those fact and they did not work.

>
>>> In almost all cases it is. In this case it was not. In fact having UTC
>>
>> I almost certainly do not believe that "in this case it was not".
>

> Well, that is what he specifiacly said. You can not believe it. Remains
> that that was the case. UTC or any other 'rel' time was irrelevant. The
> machines havving the identical times was essential.

>
>>> was irrelevant, apparently. What was of HIGHER importance was that they
>>
>> Whether or not having utc is irrelevant is also irrelevant.
>

> That is what I said.

>
>> As I said, in almost all cases, the best way to ensure that they have
>> identical times is to make sure that they are both synchronised to the
>> same time. The most convenient it UTC. But using A as an ntp server for
>> B would also work.
>

> No, that did not work.

>
>>> Sure, it is easy to say what they should have done. Especialy if you
>>> (nor I) have any idea of the setup, of the hardware, of the goals.
>>
>> Actually it is. both ntpd and chrony and the ntp protocol have been carefully designed to ensure
>> two computers have the same time to the greatest accuracy possible
>> (chrony is somewhat better than ntpd by factors of 3 or greater. This is
>> primarily because of the faster reaction of chrony to drift rate
>> changes.) . Any
>> other way of ensuring they have the same time is almost certainly going
>> to be much worse. So, I have no idea what he was talking about when he
>> says that "the same time" sacrificed synchronization with UTC.
>

> Greatest accuracy was not good enough, as far as I know. I have no idea
> what the project he was working on was.

>
>> IF his two systems were disconnected from the net or any other UTC time
>> source, then he could use ntp to synchronise them to each other, either
>> using orphan mode in ntpd, or having one act as a server for the other.
>

> Except that that did noty work in his case.
>
> But what I took away from it was that he solved some issue by looking
> not to the obvious (syncing with NTP servers) but looking at what the
> solution must be (servers having identical times).

Yes, I understand that. But, what you say does not make any sense. One
explanation is that he was incompetent. Another that he did not give you
enough detail to know what it was he did or what the problem really was.
Another is that after 20 years, your memory has failed you. Another is
that there really was something weird in his system.

You say he needed to make sure that the two had identical times.
Unfortunately that is an empty statement since you do not remember how
he determined that they had identical times. The way that I know is to
use ntp packet exchange to determine this, since that is precisely what
ntp packet exchange is designed to do. Most other ways of determining
that two computers have the same time are much worse at doing so.
>
> That is probably why I remember it after 20 years. If it was just about
> NTP, I would have forgotten about it already.
>
> houghi

[bad sector]

read my article of the 27th

just to repeat,

- I checked BIOS clock on GMT
departure condition:
00:5x.xx Zulu
20:5x:xx EDT

- booted 'buntu

- imediately observed clock showing
12:5x.xx AM i.e.
00:5x:xx

# date
Wed Oct 31 00:5x:xx EDT 2012

insert usb wifi transceiver

- clock goes to 8:51 PM

# date
Tue Oct 30 20:5x:xx EDT 2012

I know of no way to access a root CLI in Ubuntu-Studio
to do hwclock

The above makes it look as if the system

- starts off with BIOS time and considers it to
be local (EDT) because it shows it unchanged as
local time knowing that local is EDT

- when connected it obtains Zulu time from the net
which in this case is the same to begin with

- it then recalculates a new local time from net-Zulu
taking it to Z-4 and then slews the BIOS clock back
to Z-4 even if the BIOS clock was set to Zulu because
it thinks of it as being set to EDT.

- Such should be impossible with the proper algorithms

Maybe the default installation is BIOS set to Local, maybe
I gave it that when installing althought I never do (my
first ever 'buntu). Maybe there's another explanation, I
really don't care because the problem isn't the software
bug/mistake or any possible misconfifguration, those things
happen. The problem is that software should not edit the
hardware clock UNLESS the user wants it edited. For one
thing it doesn't NEED the BIOS clock after bootup, for another
it is no longer its freakin' business after shutdown!

Ditto BTW for WAN connections, no unauthorized traffic.

[unruh]

On 2012-10-30, bad sector <forgetski@postit_INVALID_.gov> wrote:
>

> read my article of the 27th
>
> just to repeat,
>
> - I checked BIOS clock on GMT
> departure condition:
> 00:5x.xx Zulu
> 20:5x:xx EDT
>
> - booted 'buntu
>
> - imediately observed clock showing
> 12:5x.xx AM i.e.
> 00:5x:xx
>
> # date
> Wed Oct 31 00:5x:xx EDT 2012
>
> insert usb wifi transceiver
>
> - clock goes to 8:51 PM
>
> # date
> Tue Oct 30 20:5x:xx EDT 2012
>
> I know of no way to access a root CLI in Ubuntu-Studio
> to do hwclock

sudo hwclock ....
I find the whole sudo thing rediculous, and I think that there is a way
to switch it off (ie to log into root) but do not know what it is.

>
> The above makes it look as if the system
>
> - starts off with BIOS time and considers it to
> be local (EDT) because it shows it unchanged as
> local time knowing that local is EDT

That sounds like and rc config file. I have no idea where ubuntu keeps
it, but you could check in /etc/init.d and
/etc/rc.{boot,sysconfig,local} for hwclock and read the surrounding
stuff to see which files it reads before setting the system time from
the rtc.

>
> - when connected it obtains Zulu time from the net
> which in this case is the same to begin with
>
> - it then recalculates a new local time from net-Zulu
> taking it to Z-4 and then slews the BIOS clock back
> to Z-4 even if the BIOS clock was set to Zulu because
> it thinks of it as being set to EDT.
>
> - Such should be impossible with the proper algorithms

No, just some bad configuration.

>
> Maybe the default installation is BIOS set to Local, maybe
> I gave it that when installing althought I never do (my
> first ever 'buntu). Maybe there's another explanation, I
> really don't care because the problem isn't the software
> bug/mistake or any possible misconfifguration, those things
> happen. The problem is that software should not edit the
> hardware clock UNLESS the user wants it edited. For one
> thing it doesn't NEED the BIOS clock after bootup, for another
> it is no longer its freakin' business after shutdown!

It is doing what you told it to do.

>
> Ditto BTW for WAN connections, no unauthorized traffic.
>
>

Are you running ntp or chrony?
ps -auxww|grep ntp|grep -v grep

[bad sector]

On 10/30/2012 10:15 PM, unruh wrote:
> On 2012-10-30, bad sector <forgetski@postit_INVALID_.gov> wrote:

> sudo hwclock ....

hwclock Tue 30 Oct 2012 10:44 PM EDT
date Wed Oct 31 02:45 EDT 2012

connect to net

hwclock Tue 30 Oct 2012 10:47 PM EDT
date Tue Oct 30 22:48 EDT 2012

normal shutdown, BIOS has been reset to 4 hrs less

but id I do a 3 g=hard shutdown then it isn't

which means that it can't even fuck something up intelligently and with
class i.e. do something it needs but otherwise according to native
wisdom "Leave the land as it had found it".

> I find the whole sudo thing rediculous, and I think that there is a way
> to switch it off (ie to log into root) but do not know what it is.

I tried assorted workarounds like edting the passwd and shadow files
from another system, all for naught.

>> The above makes it look as if the system
>>
>> - starts off with BIOS time and considers it to
>> be local (EDT) because it shows it unchanged as
>> local time knowing that local is EDT
>
> That sounds like and rc config file. I have no idea where ubuntu keeps
> it, but you could check in /etc/init.d and
> /etc/rc.{boot,sysconfig,local} for hwclock and read the surrounding
> stuff to see which files it reads before setting the system time from
> the rtc.

/etc/init/hwclock.conf
# hwclock - adjust system clock and timezone
# The hwclock task adjusts the system clock when the hardware clock is
# set to localtime (e.g. when dual-booting with Windows), and also
# ensures that the system timezone is set so that timestamps
# are written to FAT devices.
description "adjust system clock and timezone"
start on starting mountall
task
script
. /etc/default/rcS
[ "$UTC" = "yes" ] && tz="--utc" || tz="--localtime"
[ "$BADYEAR" = "yes" ] && badyear="--badyear"
exec hwclock --systz $tz --noadjfile $badyear
end script

>> Maybe the default installation is BIOS set to Local, maybe
>> I gave it that when installing althought I never do (my
>> first ever 'buntu). Maybe there's another explanation, I
>> really don't care because the problem isn't the software
>> bug/mistake or any possible misconfifguration, those things
>> happen. The problem is that software should not edit the
>> hardware clock UNLESS the user wants it edited. For one
>> thing it doesn't NEED the BIOS clock after bootup, for another
>> it is no longer its freakin' business after shutdown!
>
> It is doing what you told it to do.

I didn't tell it diddley, just did a lightning fast pretty standard
install to see what it's like cause I HAD to use rosegarden which was
at that time TOTALLY unusable on Suse, did the same with Musix. As I
said it "could be" that I told it to consider the BIOS clock as being
set to local eventhough I never do that. If I did so it was because I
didn't give a fuck about anything it could or would do other than
rosegarden. Maybe it was a default I clicked, whaaaaatever. I never
would have thought that one OS could screw up six others with such a
mickey mouse detail. But I cannot say that that is what hapened.

And that doesn't change any of what I claim; namely, that the OS has no
need for the BIOS clock once it has booted and after it has shut down
it's none of its goddam business what the BIOS clock reads so why bother
resettig it? As I have shown, it is reset only on a normal shutdown so
there's more proof/admission that there is NO NEED for resetting it. It
was linux fans who first considered it arrogantly presumtuous to think
that your OS will be the ONLY one used on a machine but now the're doing
the redmond thing themselves. There are more Tor users than Suse/Buntu
combined yet Tor coders didn't feel it would be below their stature to
simply advise users whose BIOS clock may be out without just resetting
it like they owned the computer!

Let's not take this OS infatuation with the selt too far, after all
OS'es are already just plugins for applications and come bundled a dozen
with a free ad in tarballs like soundfonts. More people have multi OS
single user machines than multi user single OS ones.

>> Ditto BTW for WAN connections, no unauthorized traffic.
>>
>>
>
> Are you running ntp or chrony?
> ps -auxww|grep ntp|grep -v grep

Nothing, I used the distro twice or thrice in all and the problem is now
not only isolated to one OS it is also fixed

dd if=/dev/zero of=/dev/sda13

[unruh]

On 2012-10-31, bad sector <forgetski@postit_INVALID_.gov> wrote:
> On 10/30/2012 10:15 PM, unruh wrote:
>> On 2012-10-30, bad sector <forgetski@postit_INVALID_.gov> wrote:
>
>> sudo hwclock ....
>
> hwclock Tue 30 Oct 2012 10:44 PM EDT
> date Wed Oct 31 02:45 EDT 2012

The last bit of data-- which of those is correct?

Let me assume that the oct 30 10:44 is correct. Then what it looks like
is that your system when it comes up thinks that the hardware clock is
on localtime when it is actually on utc.

>
> connect to net
>
> hwclock Tue 30 Oct 2012 10:47 PM EDT
> date Tue Oct 30 22:48 EDT 2012

Then you have ntpd running. It sets the hardware clock to the system
time once every 11 min. once it is sure that the system time is
synchronized.

>
> normal shutdown, BIOS has been reset to 4 hrs less

4 hours less than what?

What does "normal shutdown" and "hard shutdown" mean? I suspect the
former means that you tell the operating system to shutdown and it takes
about 3 min to finally shut down. "hard" means you use the power switch
to switch off power to the system. Note that on shutdown, the system
sets the hardware clock from the system time. Again it is confused as to
what time the clock is set to. Look in /etc/init.d/halt for the hwclock
line and see what it says.
Also look for the /etc/adjtime file and see what is in there.

>
> but id I do a 3 g=hard shutdown then it isn't
>
> which means that it can't even fuck something up intelligently and with
> class i.e. do something it needs but otherwise according to native
> wisdom "Leave the land as it had found it".

It looks very very much like a bad configuration.

bootup and shutdown systems think that the clock is on localtime, while
ntpd thinks it is on utc (which I think is the default). If you do not
want the ntpd to reset the hwclock, but want the system to keep your
system clock accurate, use chrony instead of ntpd. By default it does
not reset your rtc every 11 min.

>
>
>> I find the whole sudo thing rediculous, and I think that there is a way
>> to switch it off (ie to log into root) but do not know what it is.
>
> I tried assorted workarounds like edting the passwd and shadow files
> from another system, all for naught.

What happens if you do
su
Is su even a command available to you? (/usr/bin/su or /usr/sbin/su)

[bad sector]

On 10/31/2012 06:47 AM, unruh wrote:
> On 2012-10-31, bad sector <forgetski@postit_INVALID_.gov> wrote:
>> On 10/30/2012 10:15 PM, unruh wrote:
>>> On 2012-10-30, bad sector <forgetski@postit_INVALID_.gov> wrote:
>>
>>> sudo hwclock ....
>>
>> hwclock Tue 30 Oct 2012 10:44 PM EDT
>> date Wed Oct 31 02:45 EDT 2012
> The last bit of data-- which of those is correct?
>
> Let me assume that the oct 30 10:44 is correct. Then what it looks like
> is that your system when it comes up thinks that the hardware clock is
> on localtime when it is actually on utc.

That's what I said

>> normal shutdown, BIOS has been reset to 4 hrs less
> 4 hours less than what?

Less than what it was before

> What does "normal shutdown" and "hard shutdown" mean? I suspect the
> former means that you tell the operating system to shutdown and it takes
> about 3 min to finally shut down. "hard" means you use the power switch
> to switch off power to the system. Note that on shutdown, the system
> sets the hardware clock from the system time.

I knew that the system time was being reset upon contact with the
internet and that after a normal shutdown the HW clock had been reset
also. With a hard shutdown I could get to look into the BIOS and saw
that the hw clock had NOT been reset while running. What that means is
that the sytem, or any other system for that matter, obviously has NO
NEED for the bios clock at all during operation. It resets it after
operation without knowing so much as whether the computer will next be
run by windows, by another linux system, or will just serve as a planter
to grow 'spinach'. The ONLY event that could even remotely give it
anything resembling licence to fuck with the bios clock would be on a
system known to be a single OS system which isn't even close to actual
situation otherwise very easily observable if one takes a look around on
the disk.

>>> I find the whole sudo thing rediculous, and I think that there is a way
>>> to switch it off (ie to log into root) but do not know what it is.

On that, or more pointedly about the rootless approach espoused by
several distros, you'll hear no argument from me.

[unruh]

That is how linux works. The rtc is used ONLY to set the system clock on
bootup.

> NEED for the bios clock at all during operation. It resets it after
> operation without knowing so much as whether the computer will next be
> run by windows, by another linux system, or will just serve as a planter
> to grow 'spinach'. The ONLY event that could even remotely give it
> anything resembling licence to fuck with the bios clock would be on a
> system known to be a single OS system which isn't even close to actual
> situation otherwise very easily observable if one takes a look around on
> the disk.

If you read what I said later, on shutdown most linux systems reset the
rtc from the system clock. That is done in /etc/init.d/halt usually

So, I ask you again, What is in /etc/adjtime? What is in debian's clock
config file (/etc/sysconfig/clock?)

You really really seem to want to complain rather than fix.

[Shmuel Metz]

In <69mdne9GyuXe0Q3N...@giganews.com>, on 10/30/2012

at 04:53 PM, bad sector <forgetski@postit_INVALID_.gov> said:

>I don't need polls. I'm confident that there are many more
>computers in the world that are not systems for several people to
>use but rather household animals in the service of a single
>humanoid sometimes using several user accounts.

Yawn! What does that have to do with booting half a dozen times a day?

[Shmuel Metz]

In <arSdnYmmIpk5aRLN...@giganews.com>, on 10/30/2012

at 11:39 AM, bad sector <forgetski@postit_INVALID_.gov> said:

>As far as I know most people reboot half a dozen or more times
>every single day so there's ample opportunity for BIOS edits.

I've never met a user who routinely booted half a dozen times per day.

[Shmuel Metz]

In <te6dnSJ0sKrM-BLN...@giganews.com>, on 10/30/2012

at 01:27 AM, bad sector <forgetski@postit_INVALID_.gov> said:

>How about this: anything on my computer should be what I want it
>to be?

I have no problem with the behavior of an OS being configurable, but
that's quite different from saying that the OS shouldn't support a
function that many find useful.

[Shmuel Metz]

In <qZSdnRxQWqLOGg3N...@giganews.com>, on 10/30/2012

at 06:05 PM, bad sector <forgetski@postit_INVALID_.gov> said:

>I really don't care because the problem isn't the software
>bug/mistake or any possible misconfifguration,

Of course it is. Blaming the OS for an application error just makes
you look foolish.

Now, had you simply asked for an OS option to disable resetting the
clock, that might have been rational.

[bad sector]

On 10/31/2012 04:06 PM, unruh wrote:
> On 2012-10-31, bad sector <forgetski@postit_INVALID_.gov> wrote:

>> I knew that the system time was being reset upon contact with the
>> internet and that after a normal shutdown the HW clock had been reset
>> also. With a hard shutdown I could get to look into the BIOS and saw
>> that the hw clock had NOT been reset while running. What that means is
>> that the sytem, or any other system for that matter, obviously has NO
>
> That is how linux works. The rtc is used ONLY to set the system clock on
> bootup.

I never said I had a problem with that, it's why people set the BIOS
clock in the first place, they want the OS to use that time (or one
derived from it on the basis of chosen time zone. Optionally users may
'authorize' the OS to update time-and-date from online sources.
Personally I never authorize any automatic on-line anything.

>> NEED for the bios clock at all during operation. It resets it after
>> operation without knowing so much as whether the computer will next be
>> run by windows, by another linux system, or will just serve as a planter
>> to grow 'spinach'. The ONLY event that could even remotely give it
>> anything resembling licence to fuck with the bios clock would be on a
>> system known to be a single OS system which isn't even close to actual
>> situation otherwise very easily observable if one takes a look around on
>> the disk.
>
> If you read what I said later, on shutdown most linux systems reset the
> rtc from the system clock. That is done in /etc/init.d/halt usually
>
> So, I ask you again, What is in /etc/adjtime?

/etc/adjtime
0.0 0 0.0

> What is in debian's clock config file (/etc/sysconfig/clock?)

no sign of /etc/sysconfig

> You really really seem to want to complain rather than fix.

Wrong. First I wanted to know what was causing the unacceptable time
upset, then I wanted to elliminate the source of the problem if
possible. I identified the source of the problem as an Ubuntu
installation, and so I elliminated it. As mentioned earlier

dd if=/dev/zero of=/dev/sda13

the partition was wiped clean


HOWEVER, since a theoretical possibility arose according to which I may
have inadvertantly opted to treat my BIOS clock (always set on zulu
time) as if it were set on local time (something I have never done) I
did a quick reinstall just to see what options I had to pick from during
installation. The installer default time zone turned out to be Eastern
and I left it that way. AT NO TIME was there any question about what my
BIOS clock was set to so I definitely gave no input of that nature.


The subject 'freshie' installation behaved exactly as described earlier.

Summing up

- The installer sets a default or other time zone

- The installed NEVER asks about what BIOS clock is set to

- Upon booting without an internet connection it presumes that
the BIOS clock is set to local time and uses it

- If the BIOS clock is set to Zulu time it uses it as if it were
local time (for lack of any other reference)

- As soon as able to connect the system makes an unauthorized
connection &
- updates system time to its idea of local time &
- resets the BIOS clock to that same time.

In short, bahavior is similar to windows and so care should be taken
with OS'es other than windows as well or one might end up with a dozen
other installations all showing the wrong time.


The OS can fine tune the BIOS clock with user permission but

- there is neither need nor authority for it to reset the BIOS
clock from whatever time zone it was set to by the user

- there is no need to reset it at all unless the user wants it
reset

- In the event of multi OS computers such resetting risks making
a mess off other system times

[bad sector]

On 10/31/2012 10:01 AM, Shmuel (Seymour J.) Metz wrote:
> In <te6dnSJ0sKrM-BLN...@giganews.com>, on 10/30/2012
> at 01:27 AM, bad sector <forgetski@postit_INVALID_.gov> said:
>
>> How about this: anything on my computer should be what I want it
>> to be?
>
> I have no problem with the behavior of an OS being configurable, but
> that's quite different from saying that the OS shouldn't support a
> function that many find useful.

Agreed, but with the necesary disctinction between supporting and
imposing when imposition is not inevitable

[bad sector]

On 10/31/2012 05:51 PM, Shmuel (Seymour J.) Metz wrote:
> In <69mdne9GyuXe0Q3N...@giganews.com>, on 10/30/2012
> at 04:53 PM, bad sector <forgetski@postit_INVALID_.gov> said:
>
>> I don't need polls. I'm confident that there are many more
>> computers in the world that are not systems for several people to
>> use but rather household animals in the service of a single
>> humanoid sometimes using several user accounts.
>
> Yawn! What does that have to do with booting half a dozen times a day?

How about the likelyhood that real multi user systems seldom get
rebooted several times a day i.e. my leading up proposition that most
computers do get (re)booted several times a day.

[bad sector]

On 10/31/2012 06:14 PM, Shmuel (Seymour J.) Metz wrote:
> In <qZSdnRxQWqLOGg3N...@giganews.com>, on 10/30/2012
> at 06:05 PM, bad sector <forgetski@postit_INVALID_.gov> said:
>
>> I really don't care because the problem isn't the software
>> bug/mistake or any possible misconfifguration,
>
> Of course it is. Blaming the OS for an application error just makes
> you look foolish.

What application error are you talking about? It is, as far as I've
able to determine, solely an OS design problem.

> Now, had you simply asked for an OS option to disable resetting the
> clock, that might have been rational.

When I initially posted I had no idea what the problem or its origin
was, only that 80% of the time I use OpenSuse and that most of my
installations are OpenSuse, and that for some reason I'd been having
problems with the wrong time even when not booting windows known to
cause such problems.

[bad sector]

On 10/31/2012 05:50 PM, Shmuel (Seymour J.) Metz wrote:
> In <arSdnYmmIpk5aRLN...@giganews.com>, on 10/30/2012
> at 11:39 AM, bad sector <forgetski@postit_INVALID_.gov> said:
>
>> As far as I know most people reboot half a dozen or more times
>> every single day so there's ample opportunity for BIOS edits.
>
> I've never met a user who routinely booted half a dozen times per day.

I have in the last hours alone because when any memeber of the
Jack-Rosegarden-Qsynth-ZynAddSubFX quartet hang or crash it will easily
take several reboots to get everything back on track. You can prevent
that by first disconnecting everything from jack but you don't always
get a chance to do so. One example was a few minutes ago when I just
tried to change the Synth plugin of one track to another in Rosegarden
and so it crashed. It took about four reboots to get everything together
again and resume where I had left off. Just before that I did about 6
rebots trying to further document the topic problem, plus a complete
installation. There's about a dozen rigt there in half a day.

[David]

I only reboot computers if there is a problem requiring such, eg
Windoze, or there is a power failure, rare, or updating needs such to
be done. Most of the time they are left on unless it gets too damn hot
what with the oxygen machine as well and that I shouldn't turn off.
The air conditioner is only capable of cooling so much. I should have
gone for the bigger one instead of being a cheapskate.
--
Regards
David Simpson
Thursday, 1 November 2012

A few hours grace before the madness begins again.

Please, help defeat spammers!
Do not share your friends' email addresses.
Delete all old addresses.
Send bulk emails as BCC:
Many thanks.

[Shmuel Metz]

In <LK-dnVJmj6htMAzN...@giganews.com>, on 10/31/2012

at 07:02 PM, bad sector <forgetski@postit_INVALID_.gov> said:

>What application error are you talking about?

Asking the OS to update the RTC. I'm including the configuration data
as part of the application.

[Shmuel Metz]

In <mf-dna95U9rMMQzN...@giganews.com>, on 10/31/2012

at 06:55 PM, bad sector <forgetski@postit_INVALID_.gov> said:

>How about the likelyhood that real multi user systems seldom get
>rebooted several times a day i.e. my leading up proposition that
>most computers do get (re)booted several times a day.

I am the only one using my car, therefor I have to change the tires
several times a day.

[bad sector]

On 11/02/2012 08:10 AM, Shmuel (Seymour J.) Metz wrote:
> In <mf-dna95U9rMMQzN...@giganews.com>, on 10/31/2012
> at 06:55 PM, bad sector <forgetski@postit_INVALID_.gov> said:
>
>> How about the likelyhood that real multi user systems seldom get
>> rebooted several times a day i.e. my leading up proposition that
>> most computers do get (re)booted several times a day.
>
> I am the only one using my car, therefor I have to change the tires
> several times a day.

I don't have a problem with that if it suits your fancy just be careful
in the traffic, but for me booting is more like starting the engine.

[Shmuel Metz]

In <6LednU6gIpbKqQnN...@giganews.com>, on 11/02/2012

I generally only start the car engine only after it was shut down. Why
would you reboot your PC if it was already running the OS you wanted?
Rebooting a PC is *not* analogous to restarting a car.

Now, in a development environment some people might be switching
between OS's, but that's unusual.

[bad sector]

On 11/03/2012 06:23 PM, Shmuel (Seymour J.) Metz wrote:
> In <6LednU6gIpbKqQnN...@giganews.com>, on 11/02/2012
> at 05:00 PM, bad sector <forgetski@postit_INVALID_.gov> said:
>
>> On 11/02/2012 08:10 AM, Shmuel (Seymour J.) Metz wrote:
>>> In <mf-dna95U9rMMQzN...@giganews.com>, on 10/31/2012
>>> at 06:55 PM, bad sector <forgetski@postit_INVALID_.gov> said:
>>>
>>>> How about the likelyhood that real multi user systems seldom get
>>>> rebooted several times a day i.e. my leading up proposition that
>>>> most computers do get (re)booted several times a day.
>>>
>>> I am the only one using my car, therefor I have to change the tires
>>> several times a day.
>
>> I don't have a problem with that if it suits your fancy just be
>> careful in the traffic, but for me booting is more like starting the
>> engine.
>
> I generally only start the car engine only after it was shut down. Why
> would you reboot your PC if it was already running the OS you wanted?
> Rebooting a PC is *not* analogous to restarting a car.
>
> Now, in a development environment some people might be switching
> between OS's, but that's unusual.

I'm not going to argue with you, the other day I outlined how I needed
to reboot I don't know how many times in a matter of a few hours, read
it if you want to or don't if you don't. "MY" way of using all of "my"
computers involves LOTS of reboots all of the time and so, as per the
original relevant point, that gives me plenty of opportunity to get into
the BIOS to reset the clock to any other timezone that may be either
needed OR that may tickle my fancy. My contention is that no OS has any
business resetting to another times zone without specific user authority
and there isn't a thing under the sun or above it that'll change my opinion.

[unruh]

Except that is not, from your description, what happened. You have a
confilict in your system as to whether or not your bios clock is on
local time or utc. It is a configuration problem. But you seem to be
totally uninterested in tracking it down, instead enjoy telling all and
sundry how horrible it is that the system changes your bios clock.

You have for example never told us whether you run ntpd on your system,
a program whose whole purpose is to control the time on your system. You
have not told us what is in your control files regarding the rtc. You
have not tried setting the /etc/adjtime file. But you do have an
infinite amount of time to complain.

>
>

[bad sector]

My descriprion has been dynamic, needs be, as at first I had no idea
what the problem was. The last several timeS I pointed to one 'buntu
installation as the source of the problem i.e. it resets the BIOS clock
to local time a la windows (or only some windows according to Rajko)

> You have a confilict in your system as to whether or not your bios
> clock is on local time or utc. It is a configuration problem. But you
> seem to be totally uninterested in tracking it down, instead enjoy
> telling all and sundry how horrible it is that the system changes
> your bios clock.

Which system? In ubuntu there is NO CONFLICT, it decides to use local
time only and sets the bios clock to it. Remove Ubuntu and there is NO
PROBLEM.

I have however demonstrated that since the system at fault resets the
BIOS clock only after running this much is proof that it does not need
it to be reset while it is runing. It follows then that if it does not
need it reset (to anything) while running than on a multi-OS computer (a
condition easily detactable by it) it has no business resetting it at all.

> You have for example never told us whether you run ntpd on your
> system,

<m6GdnapM0bQU4BPN...@giganews.com>:

"I don't use ntpd except exeptionaly"

N.B. Ubuntu-Studio evidently does, on its own initiative. I don't use
nntp because any form of networking is taboo on some of my systems and I
see no wisdom in standardizing on what is not a general condition. Plus
as far as I know nntp is for fine-adjustment as opposed to dealing gross
TZ upset as in this case.

> a program whose whole purpose is to control the time on your system.

"Control" or "adjust"? Control is administrative and that's all mine,
adjusting does not (I think) cover resetting to another time zone.

> You have not told us what is in your control files regarding the
> rtc.

I dug up what I could find

> You have not tried setting the /etc/adjtime file.

On which installation? The one causing the problem, the one where the
problem is first seen?

<mf-dna15U9p9NAzN...@giganews.com>:

/etc/adjtime
0.0 0 0.0

That was on the 'buntu system. The one I'm using right now (12.2 on one
of my portables) says:

0.000000 1351514416 0.000000
1351514416
LOCAL

I'd have no idea how to "set" anyway and with many on the net advising
to rather have a cron that deletes it I'm not sure if I'd want to get
involved. As I understand it the purpose of this file is fine-tuning the
clock. I don't see its relevance in fixing a 4 hour reset by another OS
between boots ESPECIALLY when that 4 hour difference is an artificially
introduced error by another OS and any attempt to "fix" it could well
compound the situation.

> But you do have an infinite amount of time to complain.

I'm satisfied that the problem, namely the unauthorized resetting of the
BIOS clock, has been isolated to Ubuntu-Studio on the subject computer
using half a dozen other OS'es as well. Although I originally did not
know it, this is NOT an OpenSuse issue and so I will not continue this
discussion on this group. I'll take blame for having let the discussion
deviate grossly from the topic which was

a) identifying the cause of an ovbserved problem and
b) ellimininating the source

It has been identified & it has been elliminated.

[unruh]

Yes, there is something wrong with the configuration in that one
installation.

>
>> You have a confilict in your system as to whether or not your bios
>> clock is on local time or utc. It is a configuration problem. But you
>> seem to be totally uninterested in tracking it down, instead enjoy
>> telling all and sundry how horrible it is that the system changes
>> your bios clock.
>
> Which system? In ubuntu there is NO CONFLICT, it decides to use local
> time only and sets the bios clock to it. Remove Ubuntu and there is NO
> PROBLEM.

Do you, in that Ubuntu operating system, run ntpd?

>
> I have however demonstrated that since the system at fault resets the
> BIOS clock only after running this much is proof that it does not need
> it to be reset while it is runing. It follows then that if it does not
> need it reset (to anything) while running than on a multi-OS computer (a

Linux uses the bios clock ONLY to set the system time at bootup.
The bios clock itself is set both by ntpd which switches on the kernel
11 min mode, which sets the RTC from the system time once every 11 min.
I have no idea whether that always sets it to UTC or if it knows about
the possibility that it is in local time.

The hwclock run at shutdown uses /etc/adjtime to determine if it should
use local or UTC for the bios clock. If there is nothing in /etc/admtime
then it assumes local time. If there is then it uses that. Or it uses
the flags given to hwclock to determine which.
I have suggested that you look for the hwclock command in /etc/init.d
(grep hwclock /etc/init.d/*)
and look to see what the flags are.

> condition easily detactable by it) it has no business resetting it at all.

Of course it does. You, via your configuration files, told it to. That
you happen not to know about all the config files is really irrelevant.

Anyway, I have suggested ways you can try to find the config files.
Try them.

>
>> You have for example never told us whether you run ntpd on your
>> system,
>
><m6GdnapM0bQU4BPN...@giganews.com>:
>
> "I don't use ntpd except exeptionaly"

No idea if it does.

>
> N.B. Ubuntu-Studio evidently does, on its own initiative. I don't use
> nntp because any form of networking is taboo on some of my systems and I

I am sorry, but "on its own initiative" is wrong. It does so because the
configuration tell s it to. configurations you can change.

> see no wisdom in standardizing on what is not a general condition. Plus
> as far as I know nntp is for fine-adjustment as opposed to dealing gross

nntp is totally different from ntpd. nntp is for newsnet. ntpd is for
setting clocks. So lets try again
ps auxww|grep ntpd|grep -v grep

> TZ upset as in this case.
>
>> a program whose whole purpose is to control the time on your system.
>
> "Control" or "adjust"? Control is administrative and that's all mine,
> adjusting does not (I think) cover resetting to another time zone.

It depends on the config files. Set them properly.

>
>> You have not told us what is in your control files regarding the
>> rtc.
>
> I dug up what I could find

No you did not. I have suggested a number of things, and you have not
done them.

>
>
>> You have not tried setting the /etc/adjtime file.
>
> On which installation? The one causing the problem, the one where the
> problem is first seen?

Of course the one that causes the problems. I do not want you altering
anything on my computer:-)

>
><mf-dna15U9p9NAzN...@giganews.com>:
>
> /etc/adjtime
> 0.0 0 0.0
>
> That was on the 'buntu system. The one I'm using right now (12.2 on one
> of my portables) says:
>
> 0.000000 1351514416 0.000000
> 1351514416
> LOCAL
>

That says that it is assuming that the rtc is on local time.
It is not entirely clear which hwclock you are running on Ubuntu
however.
Anyway, try copying this file to the Ubuntu system.

> I'd have no idea how to "set" anyway and with many on the net advising
> to rather have a cron that deletes it I'm not sure if I'd want to get
> involved. As I understand it the purpose of this file is fine-tuning the
> clock. I don't see its relevance in fixing a 4 hour reset by another OS
> between boots ESPECIALLY when that 4 hour difference is an artificially
> introduced error by another OS and any attempt to "fix" it could well
> compound the situation.

Never mind the interaction between the various distributions. First fix
the one that it problematic. Then see if it causes problems elsewhere.
The problem with running many distros is EXACTLY what you see--
incompatible configuration of the various systems. And it IS simply
configuration.

>
>> But you do have an infinite amount of time to complain.
>
> I'm satisfied that the problem, namely the unauthorized resetting of the
> BIOS clock, has been isolated to Ubuntu-Studio on the subject computer

It is NOT unauthorized. "You" authorized it, in the configuration files
you accepted in the various distros. So, instead of yelling at the
distros, figure out what is wrong and fix it.

> using half a dozen other OS'es as well. Although I originally did not
> know it, this is NOT an OpenSuse issue and so I will not continue this
> discussion on this group. I'll take blame for having let the discussion
> deviate grossly from the topic which was

Up to you.

[bad sector]

On 11/04/2012 08:45 PM, unruh wrote:

> Up to you.

I moved it to alt.os.linux as I should have done when it became obvious
that it has nothing to do with OpenSuse.

[Shmuel Metz]

In <ysednRUtD_3S4AvN...@giganews.com>, on 11/04/2012

at 09:35 AM, bad sector <forgetski@postit_INVALID_.gov> said:

>I'm not going to argue with you, the other day I outlined how I
>needed to reboot I don't know how many times in a matter of a
>few hours,

What you didn't do was to provide any evidence that it was typical.

>and there isn't a thing under the sun or above it that'll change my
>opinion.

If facts and logic won't change your opinion then I doubt that the
developers will value it any more than I do.

[bad sector]

On 11/04/2012 10:09 PM, Shmuel (Seymour J.) Metz wrote:

> If facts and logic won't change your opinion then I doubt that the
> developers will value it any more than I do.

They can do real polls of real people to discover if there's a demand
for what they want to implement instead of listening to voices coming
from 'the cloud'.

[unruh]

As you have finally discovered, it was a configuration error. Whether it
was yours or theirs is irrelevant. If it was theirs they obviously felt
that for their clientel, that UTC=no was a more reasonable configuration
than was UTC=yes (eg lots of dual booting with Windows). They may have
been wrong in thier feelings, but that does not alter the fact that it
was a simply configuration error. And you were mistaken in your
impression of how the hardware clock worked. The system uses it to set
the system time at bootup, and sets the rtc from the system time on
shutdown. Whether that is how you would like it is really irrelevant.


>
>
>

[bad sector]

On 11/05/2012 12:22 PM, unruh wrote:
> On 2012-11-05, bad sector <forgetski@postit_INVALID_.gov> wrote:
>> On 11/04/2012 10:09 PM, Shmuel (Seymour J.) Metz wrote:
>>
>>> If facts and logic won't change your opinion then I doubt that the
>>> developers will value it any more than I do.
>>
>> They can do real polls of real people to discover if there's a demand
>> for what they want to implement instead of listening to voices coming
>> from 'the cloud'.
>
> As you have finally discovered, it was a configuration error. Whether it
> was yours or theirs is irrelevant. If it was theirs they obviously felt
> that for their clientel, that UTC=no was a more reasonable configuration
> than was UTC=yes (eg lots of dual booting with Windows).

The fact that their own recommendation for UTC=yes sits in brightly lit
neon letters right above the subject line is irrelevant too I guess.
'nuff said.

[Shmuel Metz]

In <fc6dnahHR9udRwrN...@giganews.com>, on 11/05/2012

You mean spam them with questionnaires? Won't happen. The developers
have feedback channels, but they pay more attention to informed
opinions than they do to uninformed opinions.

[bad sector]

On 11/05/2012 08:34 PM, Shmuel (Seymour J.) Metz wrote:
> In <fc6dnahHR9udRwrN...@giganews.com>, on 11/05/2012
> at 10:23 AM, bad sector <forgetski@postit_INVALID_.gov> said:
>
>> On 11/04/2012 10:09 PM, Shmuel (Seymour J.) Metz wrote:
>
>>> If facts and logic won't change your opinion then I doubt that the
>>> developers will value it any more than I do.
>
>> They can do real polls of real people to discover if there's a
>> demand for what they want to implement instead of listening to
>> voices coming from 'the cloud'.
>
> You mean spam them with questionnaires? Won't happen. The developers
> have feedback channels, but they pay more attention to informed
> opinions than they do to uninformed opinions.

No spam, I'm aware of what's around me and don't even have to ask
anyone. I see what they use and how they use it and it's pretty
representative. The thing is to know who the the customers really are
and what they WANT as oposed what may or may not be considered by
whoever else as being ideal. Ferraris ride on Goodyears "because Mr.
Ferrari likes it that way" if you've ever heard that one. Nothing
qualitative there it's 100% administrative. Show me that what you're
delivering is what the majority wants and I'll accpet that because it's
the only thing that's acceptable unless you're working for someone else
or just yourself.

[Shmuel Metz]

In <RsOdnUaHd97ZvgTN...@giganews.com>, on 11/06/2012

at 09:48 AM, bad sector <forgetski@postit_INVALID_.gov> said:

>No spam, I'm aware of what's around me and don't even have to ask
>anyone.

Then how are polls relevant?

>The thing is to know who the the customers really are
>and what they WANT

What is your evidence that they don't know? Anecdotal data don't
count.

>Show me that what you're delivering is what the majority wants
>and I'll accpet that

Why would the developers care whether you accept their judgement?