[gentoo-amd64] hardware clock often doesn't sync to system on shutdown

[gentoo-amd64] hardware clock often doesn't sync to system on shutdown

[Thanasis]

I have a laptop (Gateway T-1625), set up with ntpd to sync the system 
time (with the "-s" option in /etc/conf.d/ntpd) to a local system of the 
LAN.
What happens is tha although it syncs the system time successfully, it 
often fails to sync the hardware clock during shutdown although I have 
set CLOCK_SYSTOHC="yes" in /etc/conf.d/clock, and so I see those "One of 
the files in /etc/{conf.d,init.d} or /etc/rc.conf has a modification 
time in the future!" boot messages. Then I can confirm the difference in 
time using the commands "date" and "hwclock --show" which shows the 
difference, eg:

# hwclock --show && date
Thu 11 Sep 2008 09:55:22 PM EEST  -0.228853 seconds
Fri Sep 12 08:58:30 EEST 2008

Here is some more info in case you need it:
# rc-update show |grep clock
               clock | boot 
# uname -a
Linux dwarfy 2.6.24-29Aug-r8 #1 SMP Fri Aug 29 06:56:28 EEST 2008 x86_64 
AMD Turion(tm) 64 X2 Mobile Technology TL-60 AuthenticAMD GNU/Linux

I suspect buggy hardware and bios. Maybe related to another problem, the 
system's clock freezing for random intervals if I don't boot the system 
passing "noapic" or "noirqbalance" to the kernel .
See my report still open at http://bugzilla.kernel.org/show_bug.cgi?id=10847

[gentoo-amd64] Re: hardware clock often doesn't sync to system on shutdown

[Duncan]

Thanasis <thanasis@asyr.hopto.org> posted 48CA0929.60003@asyr.hopto.org,
excerpted below, on  Fri, 12 Sep 2008 09:16:09 +0300:

> I have a laptop (Gateway T-1625), set up with ntpd to sync the system
> time (with the "-s" option in /etc/conf.d/ntpd) to a local system of the
> LAN.
> What happens is tha although it syncs the system time successfully, it
> often fails to sync the hardware clock during shutdown although I have
> set CLOCK_SYSTOHC="yes" in /etc/conf.d/clock, and so I see those "One of
> the files in /etc/{conf.d,init.d} or /etc/rc.conf has a modification
> time in the future!" boot messages. Then I can confirm the difference in
> time using the commands "date" and "hwclock --show" which shows the
> difference, eg:
> 
> # hwclock --show && date
> Thu 11 Sep 2008 09:55:22 PM EEST  -0.228853 seconds
> Fri Sep 12 08:58:30 EEST 2008

EEST = Eastern European Summer Time, UTC+300, correct?  (Just wikipediad 
it)

Given the 11 hour time difference reported above, this may not be your 
problem, but here, I'm MST, (US Mountain Standard Time, UTC-700), and at 
one point I was having problems with a 14 hour difference because the 
system (clock init script? something anyway) was adjusting the wrong 
direction, UTC+700 instead of UTC-700.  Obviously, that created 
problems...

So... check your time zone settings.

You may also want to step thru the init script logically and figure out 
what command it's actually using (or add a set -x right before the 
hwclock call, and a set +x right after, so you get the line from bash, 
running the initscript manually to see what it spits out), then issue the 
same exact command on the command line, where you can see the error 
output if any.  I remember doing this while troubleshooting my problem 
(which eventually got fixed) here.

FWIW I run ntp also, and have clock set to sync at shutdown.  I've not 
had any problems since whatever it was that time got fixed.  I'm still 
not sure exactly what was screwed up, but being 14 hours off until I got 
networking and started ntp wasn't fun, I'll tell you that!

I also have the local clock set to local (UTC-700) time.  That's not 
recommended for those who have time changes twice a year (except for 
those dual booting MS whatever, since it only does local time, IIRC), but 
AZ is one of the states here in the US that doesn't, so I don't have to 
worry about it.

So that's something else to consider.  You may have better luck toggling 
the system and hwclock to the other of UTC or local.  I was about to give 
up and switch to UTC here, just to see if it would work, when either 
something I did or a package update fixed it and it just started 
working... <shrug>

Finally, since you run ntp, it's not really vital that you have the 
hwclock synced /exactly/ anyway.  Try setting your hardware clock from 
the BIOS... if it's off a few seconds, no biggee, the ntp sync with fix 
it.  You can then turn the shutdown sync off, if desired, and just let 
the hardware clock run on its own, updating it manually if it gets too 
far off.  By combining that with toggling UTC/local, and/or purposefully 
setting the hardware clock a few minutes ahead, you should be able to 
avoid the future filetime warnings, since the difference would be putting 
the filetimes in the past instead of the future.  Just don't get too 
carried away, because rc uses those filetimes to track whether it needs 
to recache its service dependencies, etc, and if you have the hwclock set 
too far ahead, it won't detect config changes you've made and end up 
using stale data.

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman

Re: [gentoo-amd64] Re: hardware clock often doesn't sync to system on shutdown

[Thanasis]

on 09/14/2008 11:44 AM Duncan wrote the following:
> Thanasis <thanasis@asyr.hopto.org> posted 48CA0929.60003@asyr.hopto.org,
> excerpted below, on  Fri, 12 Sep 2008 09:16:09 +0300:
>
>   
>> I have a laptop (Gateway T-1625), set up with ntpd to sync the system
>> time (with the "-s" option in /etc/conf.d/ntpd) to a local system of the
>> LAN.
>> What happens is tha although it syncs the system time successfully, it
>> often fails to sync the hardware clock during shutdown although I have
>> set CLOCK_SYSTOHC="yes" in /etc/conf.d/clock, and so I see those "One of
>> the files in /etc/{conf.d,init.d} or /etc/rc.conf has a modification
>> time in the future!" boot messages. Then I can confirm the difference in
>> time using the commands "date" and "hwclock --show" which shows the
>> difference, eg:
>>
>> # hwclock --show && date
>> Thu 11 Sep 2008 09:55:22 PM EEST  -0.228853 seconds
>> Fri Sep 12 08:58:30 EEST 2008
>>     
>
> EEST = Eastern European Summer Time, UTC+300, correct?  (Just wikipediad 
> it)
>
> Given the 11 hour time difference reported above, this may not be your 
> problem, but here, I'm MST, (US Mountain Standard Time, UTC-700), and at 
> one point I was having problems with a 14 hour difference because the 
> system (clock init script? something anyway) was adjusting the wrong 
> direction, UTC+700 instead of UTC-700.  Obviously, that created 
> problems...
>
> So... check your time zone settings.
>
> You may also want to step thru the init script logically and figure out 
> what command it's actually using (or add a set -x right before the 
> hwclock call, and a set +x right after, so you get the line from bash, 
> running the initscript manually to see what it spits out), then issue the 
> same exact command on the command line, where you can see the error 
> output if any.  I remember doing this while troubleshooting my problem 
> (which eventually got fixed) here.
>
> FWIW I run ntp also, and have clock set to sync at shutdown.  I've not 
> had any problems since whatever it was that time got fixed.  I'm still 
> not sure exactly what was screwed up, but being 14 hours off until I got 
> networking and started ntp wasn't fun, I'll tell you that!
>
> I also have the local clock set to local (UTC-700) time.  That's not 
> recommended for those who have time changes twice a year (except for 
> those dual booting MS whatever, since it only does local time, IIRC), but 
> AZ is one of the states here in the US that doesn't, so I don't have to 
> worry about it.
>
> So that's something else to consider.  You may have better luck toggling 
> the system and hwclock to the other of UTC or local.  I was about to give 
> up and switch to UTC here, just to see if it would work, when either 
> something I did or a package update fixed it and it just started 
> working... <shrug>
>
> Finally, since you run ntp, it's not really vital that you have the 
> hwclock synced /exactly/ anyway.  Try setting your hardware clock from 
> the BIOS... if it's off a few seconds, no biggee, the ntp sync with fix 
> it.  You can then turn the shutdown sync off, if desired, and just let 
> the hardware clock run on its own, updating it manually if it gets too 
> far off.  By combining that with toggling UTC/local, and/or purposefully 
> setting the hardware clock a few minutes ahead, you should be able to 
> avoid the future filetime warnings, since the difference would be putting 
> the filetimes in the past instead of the future.  Just don't get too 
> carried away, because rc uses those filetimes to track whether it needs 
> to recache its service dependencies, etc, and if you have the hwclock set 
> too far ahead, it won't detect config changes you've made and end up 
> using stale data.
>
>   
Duncan,
Thanks to your guidance, I found out that I had a large "systematic 
drift rate" in /etc/adjtime file. This must have been the reason why the 
hwclock was set behind. So I've set the drift to zero (actually just 
deleted the file and let the system create a new one) and I hope things 
will be ok now. :-)

[gentoo-amd64] Re: hardware clock often doesn't sync to system on shutdown

[Duncan]

Thanasis <thanasis@asyr.hopto.org> posted 48CD973B.6080308@asyr.hopto.org,
excerpted below, on  Mon, 15 Sep 2008 01:59:07 +0300:

> Thanks to your guidance, I found out that I had a large "systematic
> drift rate" in /etc/adjtime file. This must have been the reason why the
> hwclock was set behind. So I've set the drift to zero (actually just
> deleted the file and let the system create a new one) and I hope things
> will be ok now. :-)

Are you on baselayout-1 still or -2 (which is still ~arch)?  IDR the 
details on baselayout-1, but at least with -2, you can set it not to use 
the adjtime file at all.  If you're on -2 and can't find the details 
yourself, post to that effect and I'll try to find them for you from this 
end.

Particularly if you're having trouble with the clock interrupt failing 
(as you mentioned you are), if you sync via NTP, that file can cause more 
problems than it solves, because the system keeps deciding the clock 
isn't working right and setting a larger adjustment, which fights what 
ntpd is already doing.  Thus if you're running ntpd anyway, it's best to 
disable use of that file entirely, /especially/ if as I said your acpi or 
whatever is screwing it.  If you're still on baselayout-1 and can't 
figure out how to disable adjtime, it may be worth putting a rm in /etc/
conf.d/local (make it conditional on there actually being a file to rm, 
so the rm doesn't error out if it's not there, and ensure the local 
service is in your initlevels as appropriate) for both local_start and 
stop, so it's regularly removed before it starts getting to be too big of 
a problem.

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman

Re: [gentoo-amd64] Re: hardware clock often doesn't sync to system on shutdown

[Thanasis]

[-- Attachment #1: Type: text/plain, Size: 2112 bytes --]

on 09/15/2008 11:49 AM Duncan wrote the following:
> Thanasis <thanasis@asyr.hopto.org> posted 48CD973B.6080308@asyr.hopto.org,
> excerpted below, on  Mon, 15 Sep 2008 01:59:07 +0300:
>
>> Thanks to your guidance, I found out that I had a large "systematic
>> drift rate" in /etc/adjtime file. This must have been the reason why the
>> hwclock was set behind. So I've set the drift to zero (actually just
>> deleted the file and let the system create a new one) and I hope things
>> will be ok now. :-)
>
> Are you on baselayout-1 still or -2 (which is still ~arch)?  IDR the 
> details on baselayout-1, but at least with -2, you can set it not to use 
> the adjtime file at all.  If you're on -2 and can't find the details 
> yourself, post to that effect and I'll try to find them for you from this 
> end.
>
> Particularly if you're having trouble with the clock interrupt failing 
> (as you mentioned you are), if you sync via NTP, that file can cause more 
> problems than it solves, because the system keeps deciding the clock 
> isn't working right and setting a larger adjustment, which fights what 
> ntpd is already doing.  Thus if you're running ntpd anyway, it's best to 
> disable use of that file entirely, /especially/ if as I said your acpi or 
> whatever is screwing it.  If you're still on baselayout-1 and can't 
> figure out how to disable adjtime, it may be worth putting a rm in /etc/
> conf.d/local (make it conditional on there actually being a file to rm, 
> so the rm doesn't error out if it's not there, and ensure the local 
> service is in your initlevels as appropriate) for both local_start and 
> stop, so it's regularly removed before it starts getting to be too big of 
> a problem.
>
#  equery l |grep baselayout
sys-apps/baselayout-1.12.11.1

So I'm on baselayout-1.
I attach the /etc/init.d/clock which shows a local "readonly" variable 
that controls a "--noadjfile" option.
What does the following test do?

if ! touch /etc/adjtime 2>/dev/null ; then
                readonly="yes"
elif [[ ! -s /etc/adjtime ]] ; then
                echo "0.0 0 0.0" > /etc/adjtime
fi





[-- Attachment #2: clock --]
[-- Type: text/plain, Size: 3054 bytes --]

#!/sbin/runscript
# Copyright 1999-2007 Gentoo Foundation
# Distributed under the terms of the GNU General Public License v2

opts="save"

depend() {
	need localmount
}

setupopts() {
	if is_uml_sys ; then
		TBLURB="UML"
		fakeit=1
	elif is_vserver_sys ; then
		TBLURB="VServer"
		fakeit=1
	elif is_xenU_sys ; then
		TBLURB="xen"
		fakeit=1
	elif is_vz_sys ; then
		TBLURB="VZ"
		fakeit=1
	elif grep -q ' cobd$' /proc/devices ; then
		TBLURB="coLinux"
		fakeit=1
	elif [[ $(uname -m) == s390* ]] ; then
		TBLURB="s390"
		fakeit=1
	elif [[ ${CLOCK} == "UTC" ]] ; then
		myopts="--utc"
		TBLURB="UTC"
	else
		myopts="--localtime"
		TBLURB="Local Time"
	fi
	[[ ${fakeit} -eq 1 ]] && return 0

	if [[ ${readonly} == "yes" ]] ; then
		myadj="--noadjfile"
	else
		myadj="--adjust"
	fi

	if [[ ${SRM} == "yes" ]] ; then
		myopts="${myopts} --srm"
	fi
	if [[ ${ARC} == "arc" ]] ; then
		myopts="${myopts} --arc"
	fi
	myopts="${myopts} ${CLOCK_OPTS}"

	# Make sure user isn't using rc.conf anymore.
	if grep -qs ^CLOCK= /etc/rc.conf ; then
		ewarn "CLOCK should not be set in /etc/rc.conf but in /etc/conf.d/clock"
	fi
	# Make sure people set their timezone ... we do it here
	# even though we don't actually use the variable so that
	# people see the warning on boot.
	if [[ -z ${CDBOOT} && ${TIMEZONE-Factory} == "Factory" ]] ; then
		ewarn "Your TIMEZONE in /etc/conf.d/clock is still set to Factory!"
	fi
}

start() {
	local myopts=""
	local myadj=""
	local TBLURB="" fakeit=0
	local errstr=""
	local readonly="no"
	local ret=0

	if ! touch /etc/adjtime 2>/dev/null ; then
		readonly="yes"
	elif [[ ! -s /etc/adjtime ]] ; then
		echo "0.0 0 0.0" > /etc/adjtime
	fi

	setupopts

	if [[ ${fakeit} -ne 1 && -e /proc/modules && ! -e /dev/rtc ]] ; then
		modprobe rtc &> /dev/null || modprobe genrtc &> /dev/null
	fi

	ebegin "Setting system clock using the hardware clock [${TBLURB}]"
	if [[ ${fakeit} -eq 1 ]] ; then
		ret=0

	elif [[ -x /sbin/hwclock ]] ; then
		# Since hwclock always exit's with a 0, need to check its output.
		errstr=$(/sbin/hwclock ${myadj} ${myopts} 2>&1 >/dev/null)
		errstr="${errstr}$(/sbin/hwclock --hctosys ${myopts} 2>&1 >/dev/null)"

		if [[ -n ${errstr} ]] ; then
			ewarn "${errstr}"
			ret=1
		else
			ret=0
		fi
		errstr="Failed to set clock"
	else
		ret=1
		errstr="/sbin/hwclock not found"
	fi
	eend ${ret} "${errstr}" "You will need to set the clock yourself"

	return 0
}

stop() {
	# Don't tweak the hardware clock on LiveCD halt.
	[[ -n ${CDBOOT} ]] && return 0

	[[ ${CLOCK_SYSTOHC} != "yes" ]] && return 0

	local myopts=""
	local TBLURB=""
	local errstr=""
	local ret=0

	setupopts

	ebegin "Setting hardware clock using the system clock [${TBLURB}]"
	if [[ ${fakeit} -eq 1 ]] ; then
		ret=0

	elif [[ -x /sbin/hwclock ]] ; then
		errstr=$(/sbin/hwclock --systohc ${myopts} 2>&1 >/dev/null)

		if [[ -n ${errstr} ]] ; then
			ret=1
		else
			ret=0
		fi
		errstr="Failed to sync clocks"
	else
		ret=1
		errstr="/sbin/hwclock not found"
	fi
	eend ${ret} "${errstr}"
}

save() {
	CLOCK_SYSTOHC="yes"
	stop
}


# vim:ts=4

Re: [gentoo-amd64] Re: hardware clock often doesn't sync to system on shutdown

[Sebastian Redl]

Thanasis wrote:
> I attach the /etc/init.d/clock which shows a local "readonly" variable 
> that controls a "--noadjfile" option.
> What does the following test do?
>
> if ! touch /etc/adjtime 2>/dev/null ; then
>                readonly="yes"
> elif [[ ! -s /etc/adjtime ]] ; then
>                echo "0.0 0 0.0" > /etc/adjtime
> fi
First it tests if a touch of /etc/adjtime succeeds. If not, the file is 
not writeable, and it sets the readonly variable.

Then it tests if /etc/adjtime exists (it does, since the touch 
succeeded) and has non-zero size. If not, it writes a zero adjust into 
the file.

Sebastian

Re: [gentoo-amd64] Re: hardware clock often doesn't sync to system on shutdown

[Thanasis]

on 09/15/2008 05:57 PM Sebastian Redl wrote the following:
> Thanasis wrote:
>> I attach the /etc/init.d/clock which shows a local "readonly" 
>> variable that controls a "--noadjfile" option.
>> What does the following test do?
>>
>> if ! touch /etc/adjtime 2>/dev/null ; then
>>                readonly="yes"
>> elif [[ ! -s /etc/adjtime ]] ; then
>>                echo "0.0 0 0.0" > /etc/adjtime
>> fi
> First it tests if a touch of /etc/adjtime succeeds. If not, the file 
> is not writeable, and it sets the readonly variable.
>
> Then it tests if /etc/adjtime exists (it does, since the touch 
> succeeded) and has non-zero size. If not, it writes a zero adjust into 
> the file.
>
> Sebastian
How can I make /etc/adjtime readonly? I tried "chmod a-w /etc/adjtime", 
but root can always write to it :-) , unless the init script doesn't run 
as root.

[gentoo-amd64] Re: hardware clock often doesn't sync to system on shutdown

[Duncan]

Thanasis <thanasis@asyr.hopto.org> posted 48CE7EAE.9080404@asyr.hopto.org,
excerpted below, on  Mon, 15 Sep 2008 18:26:38 +0300:

> on 09/15/2008 05:57 PM Sebastian Redl wrote the following:
>> Thanasis wrote:
>>> I attach the /etc/init.d/clock which shows a local "readonly" variable
>>> that controls a "--noadjfile" option. What does the following test do?
>>>
>>> if ! touch /etc/adjtime 2>/dev/null ; then
>>>                readonly="yes"
>>> elif [[ ! -s /etc/adjtime ]] ; then
>>>                echo "0.0 0 0.0" > /etc/adjtime
>>> fi
>> First it tests if a touch of /etc/adjtime succeeds. If not, the file is
>> not writeable, and it sets the readonly variable.
>>
>> Then it tests if /etc/adjtime exists (it does, since the touch
>> succeeded) and has non-zero size. If not, it writes a zero adjust into
>> the file.
>>
>> Sebastian
> How can I make /etc/adjtime readonly? I tried "chmod a-w /etc/adjtime",
> but root can always write to it :-) , unless the init script doesn't run
> as root.

A caveat in that the below are all untested ideas.  I'm just throwing 
them out as possible solutions I'd explore further if it were me.  They 
may work, or not, but it's probably worth investigating them further and/
or testing them.

There's a spot in /etc/conf.d/clock to set your own options, right?  From 
the script, perhaps it's ${CLOCK_OPTS}.  If you can set your own 
arbitrary options, you can try adding --noadjfile to them.  Except 
hwclock is called several times (twice for start, once for stop if you 
have it set to do so) with different options, and I've not checked to see 
what effect setting --noadjfile will have in all those calls.  You could 
reason it out or just try it and see.

Alternatively, the manpage says there's an --adjfile=filename option.  
You could try adding that option and pointing it elsewhere, so the 
scripts don't look in the right place.

A third thing to try would be making the adjfile a directory (make it an 
empty one just in case) instead of a file.  Obviously it won't be 
possible to write a valid adjust into it then, but I'm not sure what the 
failure mode would be, tho it shouldn't blow up the system so it should 
be safe to try.

Finally, a combination of options two and three above, pointing 
--adjfile= at a different location, an empty directory, might work.

As I said, those are ideas I'd try.

Something else I HAVE done on occasion, is hack whatever initscript a bit 
to fit my needs.  If you do so, make sure portage's (assuming that's the 
PM you're using, others... I expect you'd know what to configure in them) 
CONFIG_PROTECT variables are set to include that dir (IIRC it does as 
it's under /etc, but the mask variable may unprotect it, so check that), 
so an update lets you manage the changes instead of overwriting it 
without asking.

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman

Re: [gentoo-amd64] Re: hardware clock often doesn't sync to system on shutdown

[Thanasis]

on 09/16/2008 01:31 AM Duncan wrote the following:
> Thanasis <thanasis@asyr.hopto.org> posted 48CE7EAE.9080404@asyr.hopto.org,
> excerpted below, on  Mon, 15 Sep 2008 18:26:38 +0300:
>
>> on 09/15/2008 05:57 PM Sebastian Redl wrote the following:
>>> Thanasis wrote:
>>>> I attach the /etc/init.d/clock which shows a local "readonly" variable
>>>> that controls a "--noadjfile" option. What does the following test do?
>>>>
>>>> if ! touch /etc/adjtime 2>/dev/null ; then
>>>>                readonly="yes"
>>>> elif [[ ! -s /etc/adjtime ]] ; then
>>>>                echo "0.0 0 0.0" > /etc/adjtime
>>>> fi
>>> First it tests if a touch of /etc/adjtime succeeds. If not, the file is
>>> not writeable, and it sets the readonly variable.
>>>
>>> Then it tests if /etc/adjtime exists (it does, since the touch
>>> succeeded) and has non-zero size. If not, it writes a zero adjust into
>>> the file.
>>>
>>> Sebastian
>> How can I make /etc/adjtime readonly? I tried "chmod a-w /etc/adjtime",
>> but root can always write to it :-) , unless the init script doesn't run
>> as root.
>
> A caveat in that the below are all untested ideas.  I'm just throwing 
> them out as possible solutions I'd explore further if it were me.  They 
> may work, or not, but it's probably worth investigating them further and/
> or testing them.
>
> There's a spot in /etc/conf.d/clock to set your own options, right?  From 
> the script, perhaps it's ${CLOCK_OPTS}.  If you can set your own 
> arbitrary options, you can try adding --noadjfile to them.  Except 
> hwclock is called several times (twice for start, once for stop if you 
> have it set to do so) with different options, and I've not checked to see 
> what effect setting --noadjfile will have in all those calls.  You could 
> reason it out or just try it and see.
>
> Alternatively, the manpage says there's an --adjfile=filename option.  
> You could try adding that option and pointing it elsewhere, so the 
> scripts don't look in the right place.
>
> A third thing to try would be making the adjfile a directory (make it an 
> empty one just in case) instead of a file.  Obviously it won't be 
> possible to write a valid adjust into it then, but I'm not sure what the 
> failure mode would be, tho it shouldn't blow up the system so it should 
> be safe to try.
>
> Finally, a combination of options two and three above, pointing 
> --adjfile= at a different location, an empty directory, might work.
>
> As I said, those are ideas I'd try.
>
> Something else I HAVE done on occasion, is hack whatever initscript a bit 
> to fit my needs.  If you do so, make sure portage's (assuming that's the 
> PM you're using, others... I expect you'd know what to configure in them) 
> CONFIG_PROTECT variables are set to include that dir (IIRC it does as 
> it's under /etc, but the mask variable may unprotect it, so check that), 
> so an update lets you manage the changes instead of overwriting it 
> without asking.
>
Thanks Duncan. You gave me an idea:
# ls -l /etc/adjtime
lrwxrwxrwx 1 root root 9 2008-09-16 16:19 /etc/adjtime -> /dev/null

It seems to work well so far. :-)
Do you think it might cause any problems, to /dev/null maybe?

[gentoo-amd64] Re: hardware clock often doesn't sync to system on shutdown

[Duncan]

Thanasis <thanasis@asyr.hopto.org> posted 48CFB464.8030008@asyr.hopto.org,
excerpted below, on  Tue, 16 Sep 2008 16:28:04 +0300:

> Do you think it might cause any problems, to /dev/null maybe?

I'm not sure how it's handled in this case, but the ones that cause 
problems redirecting to /dev/null are I believe the ones that rewrite by 
writing a temp version, then mv-ing it over the old one.  In fact, some 
of those won't work with symlinks for much the same reason.

Of course, if it's trying to do that as a normal user, it won't work, but 
if it's doing that as root (as likely here) it can cause problems.  I've 
had it happen a couple times to me...

So I'd try starting and stopping clock a time or two and then check /dev/
null to see if it's still fine.  But make sure you either have a copy of 
the device node or know how to create one, before you do.  If you're 
using udev, you should have a copy of both the null and console device 
nodes either in the /dev on / before udev mounts over it (so you can 
access it by doing a mount --bind... I have an fstab entry for just that, 
to make doing backups of the / filesystem easier), or in your initramfs/
initrd, or both.

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman

[gentoo-amd64] Re: hardware clock often doesn't sync to system on shutdown

[ABCD]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Duncan wrote:
> But make sure you either have a copy of the device node or know how to 
> create one, before you do.

To recreate /dev/null, do (as root):

# mknod -m 666 /dev/null c 1 3

- --
ABCD
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkjQkN8ACgkQOypDUo0oQOo9egCfVpL0hhWyCSnEa3FTg184gsSp
KfwAoLqAa7Y0WyLD/1tAuTkttHDq9NjV
=k6EE
-----END PGP SIGNATURE-----

Re: [gentoo-amd64] Re: hardware clock often doesn't sync to system on shutdown

[Thanasis]

on 09/17/2008 08:08 AM ABCD wrote the following:
> Duncan wrote:
> > But make sure you either have a copy of the device node or know how to
> > create one, before you do.
>
> To recreate /dev/null, do (as root):
>
> # mknod -m 666 /dev/null c 1 3
>
Thank you ABCD and Duncan.
I managed to have a backup of /dev/null and /dev/console as /null and 
/console. :-)

Re: [gentoo-amd64] Re: hardware clock often doesn't sync to system on shutdown

[Conway S. Smith]

On Wed, 17 Sep 2008 08:19:42 +0300
Thanasis <thanasis@asyr.hopto.org> wrote:
> on 09/17/2008 08:08 AM ABCD wrote the following:
> > Duncan wrote:
> > > But make sure you either have a copy of the device node or know
> > > how to create one, before you do.
> >
> > To recreate /dev/null, do (as root):
> >
> > # mknod -m 666 /dev/null c 1 3
> >
> Thank you ABCD and Duncan.
> I managed to have a backup of /dev/null and /dev/console as /null
> and /console. :-)
> 
> 
Did you need the backups (did your /etc/adjtime -> /dev/null symlink
break /dev/null)?


Conway S. Smith

-- 
The only "intuitive" interface is the nipple. After that, it's all
learned. (Bruce Ediger, bediger@teal.csn.org, in comp.os.linux.misc,
on X interfaces.)

Re: [gentoo-amd64] Re: hardware clock often doesn't sync to system on shutdown

[Thanasis]

on 09/17/2008 04:34 PM Conway S. Smith wrote the following:
> On Wed, 17 Sep 2008 08:19:42 +0300
> Thanasis <thanasis@asyr.hopto.org> wrote:
>   
>> on 09/17/2008 08:08 AM ABCD wrote the following:
>>     
>>> Duncan wrote:
>>>       
>>>> But make sure you either have a copy of the device node or know
>>>> how to create one, before you do.
>>>>         
>>> To recreate /dev/null, do (as root):
>>>
>>> # mknod -m 666 /dev/null c 1 3
>>>
>>>       
>> Thank you ABCD and Duncan.
>> I managed to have a backup of /dev/null and /dev/console as /null
>> and /console. :-)
>>
>>
>>     
> Did you need the backups (did your /etc/adjtime -> /dev/null symlink
> break /dev/null)?
>
>
> Conway S. Smith
>
>   
No, at least so far everything seems good:

# ls -l /dev/null /null
crw-rw-rw- 1 root root 1, 3 2008-09-17 21:41 /dev/null
crw-rw-rw- 1 root root 1, 3 2008-09-17 10:59 /null
# ls -l /dev/console /console
crw------- 1 root root 5, 1 2008-09-17 08:00 /console
crw------- 1 root root 5, 1 2008-09-17 18:42 /dev/console
#