armysetr.blogg.se - Linux setdate

#Linux setdate install
#Linux setdate update

This means you can have a somewhat correct clock in case there are network issues when you boot up. When your machine boots up it will set its clock to the timestamp fake-hwclock wrote during the last reboot/shutdown. With fake-hwclock installed your machine will not start up thinking it is 1970 all over again. On top of this, use of NTP is still recommended to deal with the fakeĬlock "drifting" while the hardware is halted or rebooting. This will stop some of the problems that mayīe caused by a system believing it has travelled in time back toġ970, such as needing to perform filesystem checks at every boot. Of scripts to save the kernel's current clock periodically (includingĪt shutdown) and restore it at boot so that the system clock keeps at Some machines don't have a working realtime clock (RTC) unit, or noĭriver for the hardware that does exist.

#Linux setdate install

Install the fake-hwclock program: # apt-get install fake-hwclockįake-hwclock: Save/restore system clock on machines without working RTC hardware So far this is essentially what others have recommended however there is one more step I think you should take. edit /etc/ntp.conf and place tinker panic 0 at the top.

edit /etc/default/ntp and ensure that the -g option is present.

You can configure the panic threshold in one of two ways: You need sudo privileges, for example: sudo sntp -Ss -M 128 0.de.Īs others have pointed out the best solution is to instruct ntpd to ignore the panic threshold, which is 1000 seconds by default. A convenient list of servers can be found on. Recated) ntpdate(8), or rdate(8) commands. With suitable privilege, run as a command or from a cron(8) job, sntp -S ntpserver.somewhere will set (step) the local clock from a synchronized specified server, like the (dep‐

Synchronized then if the offset adjustment is less than 128 milliseconds the correction will be slewed, and if the correction is more than 128 milliseconds the correction will With suitable privilege, run as a command or from a cron(8) job, sntp -Ss -M 128 ntpserver.somewhere will request the time from the server, and if that server reports that it is Is the simplest use of this program and can be run as an unprivileged command to check the current time and error in the local clock. So, is there a reason why placing the ntpdate command in rc.local does not perform the required task, while doing so in. I can, of course, reinstall the ntp service so at least the clock is updated within a few minutes from startup, but then we're back at square 1. However, this means that if the machine is turned on and no user is logged in, then the time never gets updates.

#Linux setdate update

This does update the clock as expected, and I get the true current time once the command prompt is available. Last thing I did was to remove that from rc.local and place a call to ntpdate in my. However, when doing this from command line once logged in (via ssh), the clock gets updated as soon as I invoke ntpdate. Using the above, the machine still starts at 1970.

Remove the sudo from the above command in rc.local.

Remove the ntp service altogether and leave just sudo ntpdate.

UPDATE 2: I tried following the few suggestions that came in response to the 1st update, but nothing seems to actually do the job as required.

UPDATE 1: The following (thanks to Eric and Stephan) works fine from command line, but fails to update the clock when put in /etc/rc.local: $ date sudo service ntp stop sudo ntpdate -s sudo service ntp start date How can I force a clock update at any given time? However, after startup, it still takes a couple of minutes until the time is updated, during which period I cannot work effectively with tar and make. I added the following line to /etc/rc.local file: sudo ntpdate -s Thus, I use the NTP service to update the time to the current time. The wake-up time is somewhere during 1970. I am running Ubuntu on an ARM based embedded system that lacks a battery backed RTC.