Re: systemd, ntp, kernel and hwclock

On 2017-03-05 03:52:33 +, Ben Hutchings wrote: > I would also expect that users running command-line tools to set the > time, such as ntpdate, have enough technical understanding to > distinguish the system clock and RTC. And what's worse is that by default, ntpdate is run automatically from

Re: systemd, ntp, kernel and hwclock

On 2017-02-28 20:01:52 +0100, Carsten Leonhardt wrote: > Daniel Pocock writes: > > > On 27/02/17 21:26, Ben Hutchings wrote: > >> But ntpd is also known to have a large amount of code written > >> without as much regard for security as one would hope. It seems > >> like an

Re: systemd, ntp, kernel and hwclock

On Sat, 2017-03-04 at 20:33 +, Roger Lynn wrote: > On 28/02/17 01:00, Ben Hutchings wrote: > > On Mon, 2017-02-27 at 16:09 -0800, Russ Allbery wrote: > > > Right, ntpdate for some reason doesn't set the flag to do this. > > > > There is a very good reason, which is that without continuous > >

Re: systemd, ntp, kernel and hwclock

On 28/02/17 01:00, Ben Hutchings wrote: > On Mon, 2017-02-27 at 16:09 -0800, Russ Allbery wrote: >> Right, ntpdate for some reason doesn't set the flag to do this. > > There is a very good reason, which is that without continuous > adjustment the system clock cannot be assumed more stable than

Re: systemd, ntp, kernel and hwclock

Kurt Roeckx writes: > Having ntpdate clear the unsynced flag doesn't make sense since it would > start writing a time to the RTC each 11 minutes, and as Ben said you > have no idea which of the 2 clocks is the most correct one. Oh, I thought it was a one-shot thing, but it turns

Re: systemd, ntp, kernel and hwclock

On Tue, Feb 28, 2017 at 05:04:08AM +, Ben Hutchings wrote: > On Mon, 2017-02-27 at 19:30 -0800, Russ Allbery wrote: > > Ben Hutchings writes: > > > On Mon, 2017-02-27 at 16:09 -0800, Russ Allbery wrote: > > > > Daniel Pocock writes: > > > > > However,

Re: systemd, ntp, kernel and hwclock

Daniel Pocock writes: > On 27/02/17 21:26, Ben Hutchings wrote: >> But ntpd is also known to have a large amount of code written >> without as much regard for security as one would hope. It seems >> like an unnecessary risk for most systems. > Thanks for that security tip,

Re: systemd, ntp, kernel and hwclock

Adam Borowski writes: > On Tue, Feb 28, 2017 at 10:15:23AM +0100, Daniel Pocock wrote: >> > But ntpd is also known to have a large amount of code written >> > without as much regard for security as one would hope. It seems >> > like an unnecessary risk for most systems. >>

Re: systemd, ntp, kernel and hwclock

On Tue, Feb 28, 2017 at 10:15:23AM +0100, Daniel Pocock wrote: > > But ntpd is also known to have a large amount of code written > > without as much regard for security as one would hope. It seems > > like an unnecessary risk for most systems. > > > Thanks for that security tip, I'm tempted to

Re: systemd, ntp, kernel and hwclock

On 27/02/17 21:26, Ben Hutchings wrote: > On Mon, 2017-02-27 at 11:18 -0800, Russ Allbery wrote: >>> Daniel Pocock writes: >> >>> I've observed a system that had a wildly incorrect hardware >>> clock (when it was first unboxed), I ran ntpdate to sync the >>> kernel clock but

Re: systemd, ntp, kernel and hwclock

On Mon, 2017-02-27 at 19:30 -0800, Russ Allbery wrote: > Ben Hutchings writes: > > On Mon, 2017-02-27 at 16:09 -0800, Russ Allbery wrote: > > > Daniel Pocock writes: > > > > However, at the time when I ran ntpdate, ntp was not running.  I had > > > >

Re: systemd, ntp, kernel and hwclock

Ben Hutchings writes: > On Mon, 2017-02-27 at 16:09 -0800, Russ Allbery wrote: >>> Daniel Pocock writes: >>> However, at the time when I ran ntpdate, ntp was not running.  I had >>> brought up the network manually due to an interface renaming issue on

Re: systemd, ntp, kernel and hwclock

On Mon, 2017-02-27 at 16:09 -0800, Russ Allbery wrote: > > Daniel Pocock writes: > > > However, at the time when I ran ntpdate, ntp was not running.  I had > > brought up the network manually due to an interface renaming issue on > > the first boot.  Maybe when somebody runs

Re: systemd, ntp, kernel and hwclock

Ben Hutchings writes: > On Mon, 2017-02-27 at 11:18 -0800, Russ Allbery wrote: >> The much simpler systemd-timesyncd doesn't set the hardware clock for >> reasons that one may or may not agree with (I honestly haven't >> researched it in any depth), > It looks like it does

Re: systemd, ntp, kernel and hwclock

Daniel Pocock writes: > However, at the time when I ran ntpdate, ntp was not running. I had > brought up the network manually due to an interface renaming issue on > the first boot. Maybe when somebody runs ntpdate in a scenario like > that the kernel is not sending the new

Re: systemd, ntp, kernel and hwclock

On 27/02/17 20:18, Russ Allbery wrote: > Daniel Pocock writes: > >> I've observed a system that had a wildly incorrect hardware clock (when >> it was first unboxed), I ran ntpdate to sync the kernel clock but after >> a shutdown and startup again it had a wacky time again. >

Re: systemd, ntp, kernel and hwclock

On Mon, 2017-02-27 at 11:18 -0800, Russ Allbery wrote: > > Daniel Pocock writes: > > > I've observed a system that had a wildly incorrect hardware clock (when > > it was first unboxed), I ran ntpdate to sync the kernel clock but after > > a shutdown and startup again it had a

Re: systemd, ntp, kernel and hwclock

Daniel Pocock writes: > I've observed a system that had a wildly incorrect hardware clock (when > it was first unboxed), I ran ntpdate to sync the kernel clock but after > a shutdown and startup again it had a wacky time again. > I came across the discussion about how the

Re: systemd, ntp, kernel and hwclock

On Mon, Feb 27, 2017 at 05:59:53PM +0100, Daniel Pocock wrote: > Can anybody make any suggestions or add anything to the wiki? My old Mac Mini had a crazy clock and ntp was not enough to sanitize it. I fixed it by using adjtimex in addition to ntp. As an example, my clock was off by 2890 parts

systemd, ntp, kernel and hwclock

Hi all, I've observed a system that had a wildly incorrect hardware clock (when it was first unboxed), I ran ntpdate to sync the kernel clock but after a shutdown and startup again it had a wacky time again. I came across the discussion about how the hardware clock is no longer set at