Viewing name service cache statistics

On the Solaris and Linux systems I support, I like to run the nscd (Name Service Cahing Daemon) daemon to cache password, group and host file data. Caching can be extremely valuable on servers that handle lots of logins, and is especially beneficial if you are authenticating your users against a directory server (it decreases the amount of traffic sent between hosts). Since nscd is unable to fill each and every request from cache, it has to periodically incur a cache miss. To see how often this occurs on a Solaris server, nscd can be run with the “-g” (print statistics) option:

$ nscd -g |more

nscd configuration:

         0  server debug level
"/dev/null"  is server log file

passwd cache:

       Yes  cache is enabled
   1585148  cache hits on positive entries
         0  cache hits on negative entries
      1228  cache misses on positive entries
       270  cache misses on negative entries
      99.9% cache hit rate
         0  queries deferred
        13  total entries
         0  complete cache invalidations
       211  suggested size
       600  seconds time to live for positive entries
         5  seconds time to live for negative entries
        20  most active entries to be kept valid
       Yes  check /etc/{passwd, group, hosts, inet/ipnodes} file for changes
        No  use possibly stale data rather than waiting for refresh


This is nifty!


Earlier this week I sent a SIGHUP signal to a process to get it to reread it’s configuration file. Of all the signals that could have been chosen to perform this action, why SIGHUP? Well — the answer to this question comes on page 267 of Advanced Programming in the UNIX Environment 1st edition:

“This signal [SIGHUP] is commonly used to notify daemon processes (Chapter 13) to reread their configuration files. The reason SIGHUP is chosen for this is because a daemon should not have a controlling terminal and would normally never receive this signal.”

Richard Stevens is my favorite technical writer of all time. He uses tons of well though out examples, and tackles subjects in a logical order (this is my biggest beef with some books). I miss him.

Apache presentation

I gave a presentation titled Apache internals and debugging at last night’s Atlanta UNIX users group meeting. The meeting was a blast, and I would like to thank all of the folks who attended (and for putting up with me). When I was putting together the presentation slides, I knew I wouldn’t be able to thoroughly cover all of the topics in 45-minutes (you may have noticed that I zoooooomed through the presentation — this is why). After pondering the number of slides, I decided to leave the presentation as is so people could reference the material when debugging Apache problems. Since my DTrace overview and demos didn’t begin to touch the surface of what DTrace can do, I truly hope everyone pings their Sun sales representative to get get Bryan, Mike or Adam to wander to Atlanta to present at a future AUUG meeting. Hope folks had as much fun as I did!

Watching hook processing order

While perusing through the Apache source code, I came across this nifty little nugget of code in config.c:

if (getenv("SHOW_HOOKS")) {
            printf("Registering hooks for %s\n", m->name);
            apr_hook_debug_enabled = 1;

The getenv() call will check for an environment variable names SHOW_HOOKS. If the variable is set, Apache will display the hook processing order on stdout:

$ export SHOW_HOOKS=1

$ httpd -X |more

Registering hooks for core.c
  Hooked create_connection
  Hooked pre_connection
  Hooked post_config
  Hooked translate_name
  Hooked map_to_storage
  Hooked open_logs
  Hooked child_init
  Hooked handler
  Hooked type_checker
  Hooked fixups
  Hooked access_checker
  Hooked create_request
  Hooked create_req
  Hooked pre_mpm
  Hooked insert_filter
Registering hooks for prefork.c

This information can be useful when debugging hook placement (e.g., APR_HOOK_FIRST, APR_HOOK_LAST) issues, and is great for understanding the order in which hooks are executed.