search for: systohc

Does any know of a way to sync the hardware clock without a reboot? Graham Johnston Senior Network Analyst Westman Communications Group 204.725.4300 ext 382 johnstong at westmancom.com -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.centos.org/pipermail/centos/attachments/20060719/70ef23ce/attachment-0002.html>

...localtime -> /usr/share/zoneinfo/Europe/Paris [root at xxx ~]# cat /etc/sysconfig/clock ZONE="Europe/Paris" UTC=true ARC=false [root at xxx ~]# echo $TZ [root at xxx ~]# [root at xxx ~]# date Sun Feb 20 18:01:28 EST 2011 [root at xxx ~]# rdate -s time.mit.edu [root at xxx ~]# hwclock ?systohc [root at xxx ~]# date Sun Feb 20 18:03:34 EST 2011 Note that I have even completely rebooted the server, with no effect. Am I missing something important ? Thank you in advance for your suggestions ! -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lis...

Is there a package to do this? Normally the hardware clock is set during shutdown if one is running ntpd. But if a long-running server shuts down unexpectedly, this isn't done, and the hardware clock might be off by a lot when it comes back up. So setting it periodically from a cron job could be useful. What do others do? Adding a one liner to /etc/cron.daily that invokes

Hi. I run peridocally (from cron) on all of my machines 30 * * * * root /sbin/hwclock --systohc All of those machines in question take their time via NTP from the same local server, and that server gets its time from a ntp pool. Now I had to reboot a couple of them two days ago and to my surprise all had problems with the time upon booting. Here are the important files: [root at XXXXXX ~]...

...while getting initial credentials". Then I sync both CDs manually, I mean, I established the same date in both DCs. however: the kerberos message continue: "kinit: Clock skew too great while getting initial credentials". I also, run this command: kinit: "root at s1:~#hwclock --systohc". Any idea? Regards, Phillip.

Apologies for being late to the party with this... I finally found my old notes on this re: helping out a blind friend fix his centos box... log in as root cd /usr/share/timezone cd /usr/share/zoneinfo/America/ cp Los_Angeles /etc/localtime /usr/bin/rdate -s time.nist.gov /sbin/hwclock --systohc For more details, go to http://wiki.ehow.com/Change-the-Timezone-in-Linux - rh -- Robert Hanson - Abba Communications Computer & Internet Services (509) 624-7159 - www.abbacomm.net

How can i have my centOS-3 system synch to a time server on the internet? -- My "Foundation" verse: Isa 54:17 No weapon that is formed against thee shall prosper; and every tongue that shall rise against thee in judgment thou shalt condemn. This is the heritage of the servants of the LORD, and their righteousness is of me, saith the LORD. -- carpe ductum -- "Grab the

Hi, I have a set of servers whose system time is drifting. I am running ntp client on CentOS 5.8. My config is here -> http://fpaste.org/s55U/ Anything i am missing? Regards, Kaushal

...daylight savings time (DST) -- this is a userspace concern. As such, there is really no way of making the time match follow DST short of adding the timezone infrastructure to the kernel -- which will never happen. So, my only suggestion is to do the following when DST changes occur: hwclock --systohc ; hwclock --hctosys which will update the kernel's tz_minuteswest to the appropriate value based upon the current GMT offset. This could even be done in a cron at 3am on the date of changes. I'll submit a patch shortly to add a warning about the limitations of the time match, but other t...

...M. Both dom0 and domU show ''Switching to clocksource xen'' in dmesg. I don''t know where the domU gets its time at startup, I''m guessing it''s from the hypervisor and the hypervisor clock drifted away from the dom0 one? Anyway, doing an ''hwclock --systohc'' in dom0 and restarting the domU doesn''t change anything. Ideally I''d want all clocks synchronized to the dom0 one, with NTPd taking care of keeping dom0 synchronized. If that matters, we''re planning an upgrade to Xen-4.1.2 but I don''t know exactly when...

I can't reboot a server to set the hardware clock to UTC time, but CentOS was installed with the assumption that the PC was running UTC. Is it possible to update the hardware clock to the right time and therefore allow CentOS to maintain the right time without rebooting? I am hoping to use this route for consistency versus changing how CentOS interprets the time so all servers are the same.

Hi, I would like to sync my CentOS 6.3 hardware clock time to my NTP server's time. Can I do that without reboot the hosts? If yes, it would be great if anyone of you can provide me steps to do that. I am newbie in CentOS. Thanks, Anand Singh

Hi, We have a little over 100 servers, almost all running CentOS 5.7. Virtually all are Dell servers, generally a mix of 1950s, R610s, and R410s. We use NTP and/or PTP to sync their clocks. One phenomenon we've noticed is that (1) on reboot, the clocks are all greatly out of sync, and (2) if the PTP or NTP process is stopped, the clocks start drifting very quickly. If it was isolated to

I installed CentOS 5 on a server today (wiping clean the drive which had 4.4 on it). During installation I picked the correct timezone, location and all. Yet, upon booting the machine, it seems to think that it's 6 hours earlier than it really is. The BIOS has the correct time and date on it. /etc/locatime was originally what /usr/share/zoneinfo/America/Denver would've

Hi all, I am having an issue with some older CentOS 5.3 servers. Every time the server boots, it gives the error "Cannot access the hardware clock by any known method", and then promptly sets the time 5 hours behind the hardware clock, down to the second. After the system is up. "hwclock" works fine. hwclock --debug does not show any error at all. The hardware clock is

...ogger "Starting anaconda galaxy110.sc.uni-leipzig.de postinstall" exec < /dev/tty3 > /dev/tty3 #changing to VT 3 so that we can see whats going on.... /usr/bin/chvt 3 ( #update local time echo "updating system time" /usr/sbin/ntpdate -sub 139.18.1.2 /usr/sbin/hwclock --systohc # Yum proxy echo 'proxy = http://proxy.uni-leipzig.de:3128' >> /etc/yum.conf rpm -Uvh --httpproxy proxy.uni-leipzig.de --httpport 3128 https://dl.fedoraproject.org/pub/epel/epel-release-latest-7.noarch.rpm # update all the base packages from the updates repository if [ -f /usr/bi...

...ly the first time. # reboot the server if you did set the time manual. # on my server the bios time is set to UTC. # on the os the time is set to UTC +1 hours ( for me, depends on you time zone ) # ( set time:? date -s "2 OCT 2006 18:00:00" ) # ( set clock to hardware bios:? hwclock --systohc --utc ) # # reboot and check again if you changed your time. ! # # # ---- SETUP bind9: service DNS # http://wiki.samba.org/index.php/Dns-backend_bind # change in /etc/bind/named.options.conf mcedit /etc/bind/named.options.conf # change?auth-nxdomain yes # add???? allow-transfer { none; }; #...

On a selection of boxes, ntpd running in Xen Dom0 reproducibly exhibits extermely high noise/jitter. Switching back to -default, non-xen kernel ntpd runs with very low jitter/noise. Question -- how can I ''tame'' ntpd noise & jitter when running in Dom0? Is the problem a config issue, or a bug? Already reported this downstream; everybody''s "stumped".

On a selection of boxes, ntpd running in Xen Dom0 reproducibly exhibits extermely high noise/jitter. Switching back to -default, non-xen kernel ntpd runs with very low jitter/noise. Question -- how can I ''tame'' ntpd noise & jitter when running in Dom0? Is the problem a config issue, or a bug? Already reported this downstream; everybody''s "stumped".

Hey all, I was watching some logs on a domU today and i suddenly noticed that the timestamps were off by something on the order of 47 seconds. I was surprised because *I don''t* run independent wall clocks. I checked some other domUs and the "drift" was also very close to that of the first domU. I also checked another dom0, Here the domUs were "only" out of sync by