Re: FreeRADIUS instability

Can you try this: https://www.netbsd.org/~christos/res_kqueue.diff ? christos > On Sep 29, 2021, at 6:12 PM, Pawel S. Veselov wrote: > > #include > #include > #include > #include > #include > > int main(int argc, char ** argv) { > >

Re: FreeRADIUS instability

Date:Wed, 29 Sep 2021 13:48:51 -0700 From:"Pawel S. Veselov" Message-ID: <72a4f226-78dc-22f9-4d4b-90e434b76...@gmail.com> | I think the only way to fix this is to have the resolver state | cleaned up thoroughly after fork(). I can't see how this can be | worked

Re: FreeRADIUS instability

On 9/29/21 14:21, Pawel S. Veselov wrote: As you saw the libc address lookup routines leave the fd open, and if something as part of a "make sure all fd's > 2 are closed at startup" type functionality went and closed it, that would cause a problem. The kqueue fd is used to monitor /etc/resolv.con

Re: FreeRADIUS instability

Robert, On 9/29/21 11:30, Robert Elz wrote: | So we caught where the queue is closed, and traced it back to | getaddrinfo(). That call both closes fd#3, creates a new kqueue | and leaves it open. This is the back trace from close: | | #0 0x732d69c07892 in close () from /usr/l

Re: FreeRADIUS instability

On 9/29/21 09:09, Pawel S. Veselov wrote: Yes, the question is what happened to fd#3 (presumably the kqueue). If you can get into the debugger (gdb ) and look at queue call and see what fd is passed to it? It's still fd#3 What we have determined from tracing the process that fd#3 is just bei

Re: FreeRADIUS instability

On 29.09.2021 21:59, Rhialto wrote: That should not be needed: if you install the "debug" sets, you should get files in /usr/libdata/debug, in particular /usr/libdata/debug/usr/lib/libc.so.*.debug Do I understand correctly that in case of using 9-STABLE I have to add MKDEGUG and MKDEBUGLIB to /

Re: FreeRADIUS instability

On Wed 29 Sep 2021 at 20:49:20 +0300, Dima Veselov wrote: > Greetings! > > On 29.09.2021 20:18, Rhialto wrote: > > On Wed 29 Sep 2021 at 09:09:06 -0700, Pawel S. Veselov wrote: > > > Our next step is to recompile libc with debugging symbols and start > > > That should not be needed: if you instal

Re: FreeRADIUS instability

Date:Wed, 29 Sep 2021 09:09:06 -0700 From:"Pawel S. Veselov" Message-ID: <467fc0d3-37d1-a88a-2584-420f2a06b...@gmail.com> | So we caught where the queue is closed, and traced it back to | getaddrinfo(). That call both closes fd#3, creates a new kqueue | and leav

Re: FreeRADIUS instability

Greetings! On 29.09.2021 20:18, Rhialto wrote: On Wed 29 Sep 2021 at 09:09:06 -0700, Pawel S. Veselov wrote: Our next step is to recompile libc with debugging symbols and start That should not be needed: if you install the "debug" sets, you should get files in /usr/libdata/debug, in particul

Re: FreeRADIUS instability

On Wed 29 Sep 2021 at 09:09:06 -0700, Pawel S. Veselov wrote: > Our next step is to recompile libc with debugging symbols and start That should not be needed: if you install the "debug" sets, you should get files in /usr/libdata/debug, in particular /usr/libdata/debug/usr/lib/libc.so.*.debug -Ola

Re: FreeRADIUS instability

Hi Christos, On 9/17/21 15:19, Christos Zoulas wrote: I think your problem is mprotect. (man 7 sysctl). Try setting security.pax.mprotect.ptrace=2 thank you, that got us a working GDB. On Sep 17, 2021, at 3:40 PM, Pawel S. Veselov wrote: On 9/16/21 11:31 AM, Dima Veselov wrote: I'm trying

Re: Pkgsrc problem

Probably it was something at that moment. Can now access it again. But having both 9.2 and 9.1 inaccessible is strange. On Wed, Sep 29, 2021, 12:12 Chavdar Ivanov wrote: > On Wed, 29 Sept 2021 at 05:16, Riza Dindir wrote: > > > > Hello, > > > > I am having trouble getting packages as of now (29

Re: Pkgsrc problem

On Wed, 29 Sept 2021 at 05:16, Riza Dindir wrote: > > Hello, > > I am having trouble getting packages as of now (29 sept 2021, 07:13 > GMT+3). I am using this as PKG_PATH > > https://cdn.netbsd.org/pub/pkgsrc/packages/NetBSD/amd64/9.2/All > > But when I go to > https://cdn.netbsd.org/pub/pkgsrc/pa