Am Wed, 15 Mar 2017 13:12:37 -0700
Cy Schubert <> schrieb:

Thank you very much for responding.

> Hi O.Hartmann,
> I'll try to answer as much as I can in the noon hour I have left.
> In message <>, 
> "O. H
> artmann" writes:
> > Running a host with several jails on recent CURRENT (12.0-CURRENT #8 
> > r315187:
> > Sun Mar 12 11:22:38 CET 2017 amd64) makes me trouble on a daily basis.
> > 
> > The box is an older two-socket Fujitsu server equipted with two four-core
> > Intel(R) Xeon(R) CPU L5420  @ 2.50GHz.
> > 
> > The box has several jails, each jail does NOT run service ntpd. Each jail 
> > has
> > its dedicated loopback, lo1 throughout lo5 (for the moment) with dedicated 
> > IP
> > :
> > - (if this matter, I believe not).
> > 
> > The host itself has two main NICs, broadcom based. bcm0 is dedicated to the
> > host, bcm1 is shared amongst the jails: each jail has an IP bound to bcm1 
> > via
> > whihc the jails communicate with the network.
> > 
> > I try to capture log informations via syslog, but FreeBSD's ntpd seems to be
> > very, very sparse with such informations, coverging to null - I can't see
> > anything suiatble in the logs why NTPD dies almost every night leaving the
> > system with a wild reset of time. Sometimes it is a gain of 6 hours, 
> > sometime
> > s
> > it is only half an hour. I leave the box at 16:00 local time usually and 
> > take
> > care again at ~ 7 o'clock in the morning local time.  
> We will need to turn on debugging. Unfortunately debug code is not compiled 
> into the binary. We have two options. You can either update 
> src/usr.sbin/ntp/config.h to enable DEBUG or build the port (it's the exact 
> same ntp) with the DEBUG option -- this is probably simpler. Then enable 
> debug with -d and -D. -D increases verbosity. I just committed a debug 
> option to both ntp ports to assist here.

I realised that this wasn't the case when I turned the switch on ntpd simply on 
- the
output was the same as before. So I feared that I have to recompile with 
explicitely switched on ...

> Next question: Do you see any indication of a core dump? I'd be interested 
> in looking at it if possible.

I have, intentionally, switched off core dumping. I will switch that on. But in 
messages being logged and searched for "ntp", I never saw any error resulting 
in a crash,
but I'll look tomorrow closer.

> > 
> > When the clock is floating that wild, in all cases ntpd isn't running any 
> > mor
> > e.
> > I try to restart with options -g and -G to adjust the time quickly at the
> > beginning, which works fine.  
> This is disconcerting. If your clock is floating wildly without ntpd 
> running there are other issues that might be at play here. At most the 
> clock might drift a little, maybe a minute or two a day but not by a lot. 
> Does the drift cause your clocks to run fast or slow?

Today, I switched off ntpd on the jail-bearing host. After an hour or so the 
gain of the
clock wasn't apart from my DCF77 clock - at least not within the granularity of 
minutes. So I switched on ntpd again. After a while, I checked status via 
"service ntpd
status", and I would bet off my ass that the result was "is running with PID 
XXX". The
next minute I did the same, the clock was off by almost half an hour (always 
behind real
time, never before!) and ntpd wasn't running. A coincidence? I can not tell, I 
did a
"clear" on the terminal :-( But that was strange.

> > 
> > Apart from possible misconfigurations of the jails (I'm quite new to jails 
> > an
> > d
> > their pitfalls), I was wondering what causes ntpd to die. i can't determine
> > exactly the time of its death, so it might be related to diurnal/periodic
> > processes (I use only the most vanilla configurations on periodic, except 
> > for
> > checking ZFS's scrubbing enabled).  
> As I'm a little rushed for time, I didn't catch whether the jails 
> themselves were also running ntpd... just thought I'd ask. I don't see how 
> zfs scrubbing or any other periodic scripts could cause this.

The jails do not have ntpd running since all the docs I read tell, that the 
host provides the time. So I checked/ double-checked, that they do not have 
ntpd running.

By mentioning ZFS and scrubbing I was more thinking about time-adjusting 
periodic jobs
like adjkerntz or friends - if there are any I'm not aware of. I see, it's more 

> > 
> > I'ven't had the chance to check whether the hardware is completely all 
> > right,
> > but from a superficial point of view there is no issue with high gain of the
> > internal clock or other hardware issues.  
> It's probably a good idea to check. I don't think that would cause ntpd any 
> gas. I've seen RTC battery messages on my gear which haven't caused ntpd 
> any problem. I have two machines which complain about RTC battery being 
> dead, where in fact I have replaced the batteries and the messages still 
> are displayed at boot. I'm not sure if it's possible for a kernel to damage 
> the RTC. In my case that doesn't cause ntpd any problems. It's probably 
> good to check anyway.

The server hardware in question is quite old, from 2008/09, so it has seen its 
best days
long ago. I haven't checked so far the battery status, but that is next I do or 
the battery cell pro actively for a fresh one.

My fear is that one of the time servers I try to sync with is compromised and 
wrong times. But I have no clue on that.

I have my difficulties understanding the logic behind ntp.conf regarding 
"restrict". It
might be possible that I misconfigured in a very stupid way (due to lack of
understanding) ntpd that way, that it could be set by any outer-world 

I'll check this tomorrow while in office again.
> > 
> > If there are known issues with jails (the problem occurs since I use those),
> > advice is appreciated.  
> Not that I know of.
I'll check the jails anyway. I was asking since I use on 5 jails lo1 - lo5 with 
having a dedicated loopback IP ( - And the jail host is 
listening on all (cloned) loopback interfaces with UDP4, port 123.

I have another machine in the very same network segment, but without jails. 
I'll take
the configuration and let that box run a while (it is more recent hardware 
XEON) and the very same recent CURRENT).

Kind regards,


O. Hartmann

Ich widerspreche der Nutzung oder Übermittlung meiner Daten für
Werbezwecke oder für die Markt- oder Meinungsforschung (§ 28 Abs. 4 BDSG).

Attachment: pgpSSCcfYRfy9.pgp
Description: OpenPGP digital signature

Reply via email to