Date: Tue, 30 Sep 2014 11:43:57 -0400 From: David Shane Holden <dpejesh@yahoo.com> To: "Eggert, Lars" <lars@netapp.com> Cc: "freebsd-current@freebsd.org" <freebsd-current@freebsd.org> Subject: Re: [PATCH] nscd Message-ID: <542ACFBD.3000407@yahoo.com> In-Reply-To: <007A0492-5F92-44E8-8904-699F4A42C667@netapp.com> References: <m0d8o4$qa3$1@ger.gmane.org> <007A0492-5F92-44E8-8904-699F4A42C667@netapp.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On 09/30/14 04:17, Eggert, Lars wrote: > When I start "nscd -n -s -t" and then run top in another shell, top > takes ~10 seconds to start up every time; if nscd did its thing, > repeat invocations should be much faster. nscd doesn't seem to see > any activity either, based on its log: The -t switch will only work after you change the #ifdef in debug.h to define the trace routines, and even then it doesn't give you too much information other than what methods are called. nscd could really use some debug logging but that's a whole other issue. As for why it's not working in your setup I can't say. Have you tried testing with getent to see which database is taking so long, and is that 10 seconds before or after the patch? By default nscd is suppose to timeout after 8 seconds so there might be something else going on in nscd which you're being affected by which is now being exposed. What I do know is when the timeout value is unusually large (in this case due to the bad memcpy) the kevent timer registered at the end of nscd.c:process_socket_event() doesn't seem to be honored. My guess is inside the kernel it's setting it to 0 if it exceeds some threshold so it immediately gets triggered. It's basically shooting itself in the head right when a connection to the socket is made. You can test this by running 'socat UNIX-CONNECT:/var/run/nscd -'. You'll notice that it instantly disconnects without the patch, then 8 seconds with it.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?542ACFBD.3000407>