nscd and glibc news

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

I usually don't do this but there are some changes coming which people
should be aware of and which deserve special testing.


First, I spent a great deal of time on nscd.  The version in the current
FC3 test is quite different from old code and starting with the 2.3.3-50
glibc (not published yet) there will be another big change.

The nscd in FC3 now supports persistent database.  The information
gathered cached is not lost when the nscd process is terminated.  This
means right after startup a lot of information is already available, no
need to go to the services.  Along with the change nscd was changed to
reload data when the timeout time is reached.  This means in general no
delay here either.  Entries which are in constant use probably won't
leave the cache at all.

To implement this lots of internals changed, especially the memory
handling.  And this is where testing is needed.  The amount of memory
available for caching is now directly dependent on the size of the hash
table (look at the nscd.conf file).  If the table is sized too small
data cannot be stored.  This is very different from the old behavior
where a too-small hash table only meant that the performance degraded
due to hash collisions.  So my plea is, especially those of you who can
run the code on machines with high usage of passwd, group, host
information (multiuser machines, ftp/http servers), please give it a
try.  Use nscd --stat to review the statistics (ask if in doubt).  It'll
show you when the hash table is too small.  I would like to find a
reasonable default size.

The already mentioned 2.3.3-50 version will bring another change.  The
communication between processes and nscd is radically different (read:
it's *much* faster; one test suite is 100x faster).  Here I am mostly
concerned about robustness.  The cache handling is very tricky.  So
again, people who could expose the code to high usage are invited to let
me know whether the code works or not (please also report success).


Also new in the last versions of glibc is stricter error checking in the
memory handling code.  The FC3 code today already aborts when it finds a
problem.  Before only a warning was issued and people tended to ignore
this.  Now the process is terminated in addition to the error message.
The default can be changed with the MALLOC_CHECK_ environment variable
(setting it to zero disables the checks).  It is *highly* advised to not
change the default and instead report/fix the problems.  These are
potentially fatal bugs which might also imply security risks.  I think
Warren at some point reported OO.org does start.  It is the
application's fault, so don't complain about glibc.  Fix the code.

In 2.3.3-50 I've added more tests and there might be yet more to come in
future.  Programs which seemed to have worked fine in the past might now
crash because of the much stricter tests.  Again, report/fix the
problem.  I _think_ I got the tests right.  If something looks
suspicious feel free to file a bug against glibc.  But do this only if
you have carefully investigated the situation and ideally if valgrind,
mudflap, and perhaps efence all have not found a bug.


Thanks for testing.

- --
â Ulrich Drepper â Red Hat, Inc. â 444 Castro St â Mountain View, CA â
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.6 (GNU/Linux)

iD8DBQFBQQ9k2ijCOnn/RHQRAjK9AJsF6EF5D7CJhro+IPf4Ufh+k/nNBACgqabe
lQq/ZGf2d1uR/yYsXQuFjco=
=xpBY
-----END PGP SIGNATURE-----



[Index of Archives]     [Current Fedora Users]     [Fedora Desktop]     [Fedora SELinux]     [Yosemite News]     [Yosemite Photos]     [KDE Users]     [Fedora Tools]     [Fedora Docs]

  Powered by Linux