Re: ntpd segfaults on start

From: Cy Schubert <Cy.Schubert_at_cschubert.com>
Date: Thu, 05 Sep 2019 20:55:27 -0700
In message <20190905142817.GB2559_at_kib.kiev.ua>, Konstantin Belousov writes:
> On Thu, Sep 05, 2019 at 06:07:22AM -0700, Cy Schubert wrote:
> > In message <20190905063354.qxecqjkafikdtdyq_at_vzakharov>, Vladimir Zakharov 
> > write
> > s:
> > > 
> > > --ply3axd74k44nuk3
> > > Content-Type: text/plain; charset=utf-8
> > > Content-Disposition: inline
> > > Content-Transfer-Encoding: quoted-printable
> > >
> > > On Thu, Sep 05, 2019, Vladimir Zakharov wrote:
> > > > Hello!
> > > >=20
> > > > Accidentally it turned out that the ntpd does not start on boot.
> > > > Logs show that it core dumps:
> > > > 2019-09-05T08:38:43.588563+03:00 vzakharov ntpd 34934 - - ntpd 4.2.8p12
> -a=
> > >  (1): Starting
> > > > 2019-09-05T08:38:43.588717+03:00 vzakharov kernel - - - Security policy
>  l=
> > > oaded: MAC/ntpd (mac_ntpd)
> > > > 2019-09-05T08:38:43.718356+03:00 vzakharov kernel - - - pid 35074 (ntpd
> ),=
> > >  jid 0, uid 123: exited on signal 11
> > > >=20
> > > > Not sure how long does it happen. ktrace and gdb points to `setrlimit`
> > > > call. Clean rebuild has no effect. Does anyone have any idea what the
> > > > problem could be?
> > >
> > > Accidental insight after sending initial mail: I've disabled
> > > ASLR related sysctls, and now ntpd starts and runs again.
> > > # grep aslr /boot/loader.conf
> > > kern.elf32.aslr.enable=3D0
> > > kern.elf64.aslr.enable=3D0
> > > # service ntpd status
> > > ntpd is running as pid 30528.
> > 
> > I'll take a look at this. When you get a chance can you open a PR for this 
> > and assign the ticket to me, please.
>
> See the thread 'ntpd doesn't like ASLR on stable/12 post-r350672' on stable.
> Read it to the end.

Same setrlimit, different error NetBSD is experiencing.

I'll investigate.


-- 
Cheers,
Cy Schubert <Cy.Schubert_at_cschubert.com>
FreeBSD UNIX:  <cy_at_FreeBSD.org>   Web:  http://www.FreeBSD.org

	The need of the many outweighs the greed of the few.
Received on Fri Sep 06 2019 - 01:55:35 UTC

This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:41:21 UTC