Hi All, Many years ago, I needed to install YACS (yet another clock synchronizer) into my Red Hat (?) system, to keep my hardware clock from "drifting" over time. No mention of it, or anything on clock synchronizers, that I can find for my Linux Mint 17 Qiana. Not needed? Handled elsewhere as a standard feature? Thanks, Carl Turney Bayswater, Vic
Hi Carl. I'm basing this answer on you using ntp or similar to sync your time from a suitable source. Is there any reason why a cron job running hwclock on a periodic basis wouldn't do the job? man 8 hwclock One of the following, depending upon if you have your hardware clock on local time or utc. hwclock --systohc --localtime hwclock --systohc --utc Regards, Morrie. -----Original Message----- From: luv-main [mailto:luv-main-bounces@luv.asn.au] On Behalf Of Carl Turney Sent: Wednesday, 21 October 2015 11:47 AM To: luv-main@luv.asn.au Subject: No need for YACS in Mint? Hi All, Many years ago, I needed to install YACS (yet another clock synchronizer) into my Red Hat (?) system, to keep my hardware clock from "drifting" over time. No mention of it, or anything on clock synchronizers, that I can find for my Linux Mint 17 Qiana. Not needed? Handled elsewhere as a standard feature? Thanks, Carl Turney Bayswater, Vic _______________________________________________ luv-main mailing list luv-main@luv.asn.au http://lists.luv.asn.au/listinfo/luv-main
On 21.10.15 12:20, Morrie Wyatt wrote:
I'm basing this answer on you using ntp or similar to sync your time from a suitable source. ... One of the following, depending upon if you have your hardware clock on local time or utc.
hwclock --systohc --localtime
hwclock --systohc --utc
An ntpd is what kept my host within a fraction of a second for five years with ubuntu 10.04, IIRC, while the absence of it has the same machine several minutes off in a year under debian 7.8.0. On debian, the first thing I've found (prompted by this thread) is the "ntpdate" package. Its manpage describes invocation in a startup script, i.e. it's an alternative to ntpd. (And won't act if an ntpd is running.) It doesn't seem to take any notice of /etc/ntp.conf, but works with a server specified on the command line. Aaah, I see the need for the manual/scripted setting of hwclock; ntpdate doesn't touch that. (ntpd maybe didn't either, but that didn't show.) Must try openntpd - on another evening. Erik
On Wed, 21 Oct 2015 08:36:31 PM Erik Christiansen wrote:
An ntpd is what kept my host within a fraction of a second for five years with ubuntu 10.04, IIRC, while the absence of it has the same machine several minutes off in a year under debian 7.8.0.
On debian, the first thing I've found (prompted by this thread) is the "ntpdate" package. Its manpage describes invocation in a startup script, i.e. it's an alternative to ntpd. (And won't act if an ntpd is running.)
The Debian package ntp has the ntpd. It is built from the same source package as ntpdate. If you want to set the date from a cron job (or manually) then use ntpdate. Otherwise use ntp. -- My Main Blog http://etbe.coker.com.au/ My Documents Blog http://doc.coker.com.au/
On 21.10.15 23:15, Russell Coker wrote:
On Wed, 21 Oct 2015 08:36:31 PM Erik Christiansen wrote:
On debian, the first thing I've found (prompted by this thread) is the "ntpdate" package. Its manpage describes invocation in a startup script, i.e. it's an alternative to ntpd. (And won't act if an ntpd is running.)
The Debian package ntp has the ntpd. It is built from the same source package as ntpdate. If you want to set the date from a cron job (or manually) then use ntpdate. Otherwise use ntp.
Darnit, the ntp package _is_ there. Many thanks. Have purged openntpd, and substituted ntp. The only remaining oddity is that ntpdate (when I give it a whirl) still doesn't seem able to obey its own conf file, to use /etc/ntp.conf: # ntpdate -d 21 Oct 23:44:12 ntpdate[8610]: ntpdate 4.2.6p5@1.2349-o Fri Apr 10 19:08:07 UTC 2015 (1) 21 Oct 23:44:12 ntpdate[8610]: no servers can be used, exiting despite: # grep NTP_CONF /etc/default/ntpdate NTPDATE_USE_NTP_CONF=yes and four (default) uncommented "server" lines in /etc/ntp.conf. Substituting four local servers makes no difference. It only seems to work when a server is specified on the command line. It's no showstopper, I just don't understand the failure. Erik
Erik Christiansen writes:
On 21.10.15 23:15, Russell Coker wrote:
The Debian package ntp has the ntpd. It is built from the same source package as ntpdate. If you want to set the date from a cron job (or manually) then use ntpdate. Otherwise use ntp.
Darnit, the ntp package _is_ there. Many thanks. Have purged openntpd, and substituted ntp.
The only remaining oddity is that ntpdate (when I give it a whirl) still doesn't seem able to obey its own conf file, to use /etc/ntp.conf:
# ntpdate -d [...]
If you already install ISC ntpd, just use "ntpd -q". ntpdate is for people who *don't* install an ntpd. ntpd -q has been available since at least Debian 6 (Feb 2011). If you have systemd, and you don't need to be an NTP *server*, consider "systemctl enable systemd-timesyncd" instead. This is installed but off by default in Debian 8; AIUI it will be the default in Debian 9. Running hwclock(8) manually is mostly unnecessary. The *kernel* writes to the hardware clock every 11 minutes, iff it believes there's an NTP client keeping the system clock accurate. (I researched this last month, but I don't have the cites handy. If anyone cares, I can go dig it up.) PS: re "doesn't obey it's config file", in Debian there are hooks in ISC dhclient to restart ntpd every time it gets a lease, with a custom temporary ntpd.conf. Maybe ntpdate is using that instead of /etc/ntp.conf?
Quoting Trent W. Buck (trentbuck@gmail.com):
If you have systemd, and you don't need to be an NTP *server*, consider "systemctl enable systemd-timesyncd" instead. This is installed but off by default in Debian 8; AIUI it will be the default in Debian 9.
*cough* Yes, stretch does indeed have this enabled by default. On new systems, I'm inclining towards openntpd, http://www.openntpd.org/ . Of course, this is for the use-case of wanting to have a functional ongoing ntp daemon, not just a Microsoft-style SNTP client with no error checking, authentication, no tracking of jitter or delay, no ability to consult more than one NTP server, and no precaution against adjusting the time jumps backwards, which is what systemd-timesyncd is. One nice thing, if you have a real ntpd running (ISC's or OpenBSD Foundation's or Chrony), then systemd-timesyncd quits gracefully (on systems where I've tested this, at least). And I personally feel much better running a real NTP implementation even on laptops.
On 21.10.15 18:14, Rick Moen wrote:
Quoting Trent W. Buck (trentbuck@gmail.com):
If you have systemd, and you don't need to be an NTP *server*, consider "systemctl enable systemd-timesyncd" instead. This is installed but off by default in Debian 8; AIUI it will be the default in Debian 9.
*cough* Yes, stretch does indeed have this enabled by default. On new systems, I'm inclining towards openntpd, http://www.openntpd.org/ .
Any specific reason for preferring it over the Debian ntp package? (I guess familiarity is often a biggie.)
Of course, this is for the use-case of wanting to have a functional ongoing ntp daemon, not just a Microsoft-style SNTP client with no error checking, authentication, no tracking of jitter or delay, no ability to consult more than one NTP server, and no precaution against adjusting the time jumps backwards, which is what systemd-timesyncd is.
But ... but ... it wouldn't be Fully-Lennarted Systemdix without being M$-monolithic and M$-degenerate, would it?
One nice thing, if you have a real ntpd running (ISC's or OpenBSD Foundation's or Chrony), then systemd-timesyncd quits gracefully (on systems where I've tested this, at least).
One nice thing, IIUC, is that we can still chuck systemd out, in favour of real discrete daemons, on install?
And I personally feel much better running a real NTP implementation even on laptops.
After removing networking start from the startup scripts, in favour of manual networking start, for the few occasions when one is tethered? Erik
Quoting Erik Christiansen (dvalin@internode.on.net):
Any specific reason for preferring it over the Debian ntp package? (I guess familiarity is often a biggie.)
I'm actually considerably _more_ familiar with NTP Project's ntpd, as it's the reference implmentation. The openntpd.org (OpenBSD Foundation) 'Portable OpenNTPD' alternative is intriguing as it aims to reduce the attack surface as a network daemon, which other things being equal is A Good Thing. Hence, I'm considering its relative merits at the moment and am undecided. I was about to say that it's still early days for the OpenBSD Foundation's codebase, but am surprised to note, upon checking, that this is wrong: The project was launched well over a decade ago, and I'm merely behind the news. ;-> (I believe I finally noticed it courtesy of an LWN.net article about recurring NTP Project ntpd security problems, and remedies via alternative implementations.)
And I personally feel much better running a real NTP implementation even on laptops.
After removing networking start from the startup scripts, in favour of manual networking start, for the few occasions when one is tethered?
In my use case, I pretty much always have either wireless ethernet or wired ethernet at startup.
Rick Moen <rick@linuxmafia.com> writes:
Quoting Trent W. Buck (trentbuck@gmail.com):
If you have systemd, and you don't need to be an NTP *server*, consider "systemctl enable systemd-timesyncd" instead. This is installed but off by default in Debian 8; AIUI it will be the default in Debian 9.
*cough* Yes, stretch does indeed have this enabled by default. On new systems, I'm inclining towards openntpd, http://www.openntpd.org/ .
Of course, this is for the use-case of wanting to have a functional ongoing ntp daemon,
Fair enough. It sounds like your use case is different from the OP's.
not just a Microsoft-style SNTP client with no error checking, authentication, no tracking of jitter or delay, no ability to consult more than one NTP server, and no precaution against adjusting the time jumps backwards, which is what systemd-timesyncd is.
Erm, as at v215 at least some of that appears to be false. /etc/systemd/timesyncd.conf's variable is "Servers" not "Server", though I can't find timesyncd.conf.5 to tell me why. I see logs like this: 2015-10-24T01:34:13+1100 het systemd-timesyncd[265]: Timed out waiting for reply from 10.128.0.1:123 (ntp). 2015-10-24T02:08:21+1100 het systemd-timesyncd[265]: Using NTP server 10.128.0.1:123 (ntp). 2015-10-24T02:08:21+1100 het systemd-timesyncd[265]: interval/delta/delay/jitter/drift 2048s/-0.005s/0.000s/0.008s/-63ppm 2015-10-24T02:42:29+1100 het systemd-timesyncd[265]: interval/delta/delay/jitter/drift 2048s/+0.000s/0.000s/0.007s/-63ppm 2015-10-24T03:16:37+1100 het systemd-timesyncd[265]: interval/delta/delay/jitter/drift 2048s/-0.005s/0.000s/0.003s/-64ppm 2015-10-24T03:50:46+1100 het systemd-timesyncd[265]: interval/delta/delay/jitter/drift 2048s/-0.006s/0.000s/0.004s/-66ppm I can't be arsed RTFSing for more details.
Quoting Trent W. Buck (trentbuck@gmail.com):
Erm, as at v215 at least some of that appears to be false.
/etc/systemd/timesyncd.conf's variable is "Servers" not "Server", though I can't find timesyncd.conf.5 to tell me why.
Good to know. Personally, I'd rather have a real NTP implementation, though.
On 22.10.15 11:06, Trent W. Buck wrote:
If you already install ISC ntpd, just use "ntpd -q". ntpdate is for people who *don't* install an ntpd. ntpd -q has been available since at least Debian 6 (Feb 2011).
Between your words of wisdom, and the ntpd manpage:
-q Exit the ntpd just after the first time the clock is set. This behavior mimics that of the ntpdate program, which is to be retired. <<
I'm convinced. (Crikey, I've moved from sendmail to postfix, vi to vim, and SunOS to Solaris to Linux. This modernisation lark never stops.) ...
PS: re "doesn't obey it's config file", in Debian there are hooks in ISC dhclient to restart ntpd every time it gets a lease, with a custom temporary ntpd.conf. Maybe ntpdate is using that instead of /etc/ntp.conf?
I could only locate an ntpd.conf while I had openntpd installed. It doesn't exist with ntpdate and ntp installed. It is true that ntpdate uses /etc/default/ntpdate, but it has the default I mentioned upthread: On 21.10.15 23:59, Erik Christiansen wrote:
# grep NTP_CONF /etc/default/ntpdate NTPDATE_USE_NTP_CONF=yes
I should have quoted the full stanza: # Set to "yes" to take the server list from /etc/ntp.conf, from package ntp, # so you only have to keep it in one place. NTPDATE_USE_NTP_CONF=yes Ditching ntpdate obviates any need to fuss with that. Erik
Erik Christiansen writes:
PS: re "doesn't obey it's config file", in Debian there are hooks in ISC dhclient to restart ntpd every time it gets a lease, with a custom temporary ntpd.conf. Maybe ntpdate is using that instead of /etc/ntp.conf?
I could only locate an ntpd.conf while I had openntpd installed. It doesn't exist with ntpdate and ntp installed. It is true that ntpdate uses /etc/default/ntpdate, but it has the default I mentioned upthread:
Note: I wrote ntp.conf, you wrote ntpd.conf. Braino? On all Debian systems I've created with debian-installer[0], /etc/ntp.conf gets created automatically based on your answers during the install. (...I think. Now I'm worried :P) [0] as opposed to debootstrap or similar.
participants (6)
-
Carl Turney -
Erik Christiansen -
Morrie Wyatt -
Rick Moen -
Russell Coker -
trentbuck＠gmail.com