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.
email@example.com mailing list
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"