* [gentoo-amd64] hardware clock often doesn't sync to system on shutdown @ 2008-09-12 6:16 Thanasis 2008-09-14 8:44 ` [gentoo-amd64] " Duncan 0 siblings, 1 reply; 14+ messages in thread From: Thanasis @ 2008-09-12 6:16 UTC (permalink / raw To: gentoo-amd64 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 ^ permalink raw reply [flat|nested] 14+ messages in thread
* [gentoo-amd64] Re: hardware clock often doesn't sync to system on shutdown 2008-09-12 6:16 [gentoo-amd64] hardware clock often doesn't sync to system on shutdown Thanasis @ 2008-09-14 8:44 ` Duncan 2008-09-14 22:59 ` Thanasis 0 siblings, 1 reply; 14+ messages in thread From: Duncan @ 2008-09-14 8:44 UTC (permalink / raw To: gentoo-amd64 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 ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [gentoo-amd64] Re: hardware clock often doesn't sync to system on shutdown 2008-09-14 8:44 ` [gentoo-amd64] " Duncan @ 2008-09-14 22:59 ` Thanasis 2008-09-15 8:49 ` Duncan 0 siblings, 1 reply; 14+ messages in thread From: Thanasis @ 2008-09-14 22:59 UTC (permalink / raw To: gentoo-amd64 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. :-) ^ permalink raw reply [flat|nested] 14+ messages in thread
* [gentoo-amd64] Re: hardware clock often doesn't sync to system on shutdown 2008-09-14 22:59 ` Thanasis @ 2008-09-15 8:49 ` Duncan 2008-09-15 14:46 ` Thanasis 0 siblings, 1 reply; 14+ messages in thread From: Duncan @ 2008-09-15 8:49 UTC (permalink / raw To: gentoo-amd64 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 ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [gentoo-amd64] Re: hardware clock often doesn't sync to system on shutdown 2008-09-15 8:49 ` Duncan @ 2008-09-15 14:46 ` Thanasis 2008-09-15 14:57 ` Sebastian Redl 0 siblings, 1 reply; 14+ messages in thread From: Thanasis @ 2008-09-15 14:46 UTC (permalink / raw To: gentoo-amd64 [-- 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 ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [gentoo-amd64] Re: hardware clock often doesn't sync to system on shutdown 2008-09-15 14:46 ` Thanasis @ 2008-09-15 14:57 ` Sebastian Redl 2008-09-15 15:26 ` Thanasis 0 siblings, 1 reply; 14+ messages in thread From: Sebastian Redl @ 2008-09-15 14:57 UTC (permalink / raw To: gentoo-amd64 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 ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [gentoo-amd64] Re: hardware clock often doesn't sync to system on shutdown 2008-09-15 14:57 ` Sebastian Redl @ 2008-09-15 15:26 ` Thanasis 2008-09-15 22:31 ` Duncan 0 siblings, 1 reply; 14+ messages in thread From: Thanasis @ 2008-09-15 15:26 UTC (permalink / raw To: gentoo-amd64 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. ^ permalink raw reply [flat|nested] 14+ messages in thread
* [gentoo-amd64] Re: hardware clock often doesn't sync to system on shutdown 2008-09-15 15:26 ` Thanasis @ 2008-09-15 22:31 ` Duncan 2008-09-16 13:28 ` Thanasis 0 siblings, 1 reply; 14+ messages in thread From: Duncan @ 2008-09-15 22:31 UTC (permalink / raw To: gentoo-amd64 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 ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [gentoo-amd64] Re: hardware clock often doesn't sync to system on shutdown 2008-09-15 22:31 ` Duncan @ 2008-09-16 13:28 ` Thanasis 2008-09-16 22:55 ` Duncan 0 siblings, 1 reply; 14+ messages in thread From: Thanasis @ 2008-09-16 13:28 UTC (permalink / raw To: gentoo-amd64 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? ^ permalink raw reply [flat|nested] 14+ messages in thread
* [gentoo-amd64] Re: hardware clock often doesn't sync to system on shutdown 2008-09-16 13:28 ` Thanasis @ 2008-09-16 22:55 ` Duncan 2008-09-17 5:08 ` ABCD 0 siblings, 1 reply; 14+ messages in thread From: Duncan @ 2008-09-16 22:55 UTC (permalink / raw To: gentoo-amd64 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 ^ permalink raw reply [flat|nested] 14+ messages in thread
* [gentoo-amd64] Re: hardware clock often doesn't sync to system on shutdown 2008-09-16 22:55 ` Duncan @ 2008-09-17 5:08 ` ABCD 2008-09-17 5:19 ` Thanasis 0 siblings, 1 reply; 14+ messages in thread From: ABCD @ 2008-09-17 5:08 UTC (permalink / raw To: gentoo-amd64 -----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----- ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [gentoo-amd64] Re: hardware clock often doesn't sync to system on shutdown 2008-09-17 5:08 ` ABCD @ 2008-09-17 5:19 ` Thanasis 2008-09-17 13:34 ` Conway S. Smith 0 siblings, 1 reply; 14+ messages in thread From: Thanasis @ 2008-09-17 5:19 UTC (permalink / raw To: gentoo-amd64 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. :-) ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [gentoo-amd64] Re: hardware clock often doesn't sync to system on shutdown 2008-09-17 5:19 ` Thanasis @ 2008-09-17 13:34 ` Conway S. Smith 2008-09-17 16:11 ` Thanasis 0 siblings, 1 reply; 14+ messages in thread From: Conway S. Smith @ 2008-09-17 13:34 UTC (permalink / raw To: gentoo-amd64 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.) ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [gentoo-amd64] Re: hardware clock often doesn't sync to system on shutdown 2008-09-17 13:34 ` Conway S. Smith @ 2008-09-17 16:11 ` Thanasis 0 siblings, 0 replies; 14+ messages in thread From: Thanasis @ 2008-09-17 16:11 UTC (permalink / raw To: gentoo-amd64 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 # ^ permalink raw reply [flat|nested] 14+ messages in thread
end of thread, other threads:[~2008-09-17 16:11 UTC | newest] Thread overview: 14+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2008-09-12 6:16 [gentoo-amd64] hardware clock often doesn't sync to system on shutdown Thanasis 2008-09-14 8:44 ` [gentoo-amd64] " Duncan 2008-09-14 22:59 ` Thanasis 2008-09-15 8:49 ` Duncan 2008-09-15 14:46 ` Thanasis 2008-09-15 14:57 ` Sebastian Redl 2008-09-15 15:26 ` Thanasis 2008-09-15 22:31 ` Duncan 2008-09-16 13:28 ` Thanasis 2008-09-16 22:55 ` Duncan 2008-09-17 5:08 ` ABCD 2008-09-17 5:19 ` Thanasis 2008-09-17 13:34 ` Conway S. Smith 2008-09-17 16:11 ` Thanasis
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox