httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Mikhail T." <>
Subject mod_reopen (Re: reopening of logs without restarting)
Date Mon, 08 Feb 2010 19:30:43 GMT
22.01.2010 15:28, Akins, Brian ???????(??):
> Each process (not thread) has an open filehandle with mod_log_config,
> correct?
Having almost finished the necessary changes to mod_log_config, I 
realized, that there are/may be modules, that keep their own logging. 
Being able to include those in my reopening is not required for my 
purposes, but it would be nice...

Going through the process' table of opened files, probably, can not be 
implemented in a cross-platform fashion, but as long as the arp-API was 
used to open the log-files, I thought, I could achieve it...

Here is the (Unix-only) plan -- please, shoot me down, before I waste 
too much time going down the wrong path:

   1. On start-up, my mod_reopen will:
          * install its own signal-handler for the user-configurable
            "reopen" signal;
          * memorize the values of the first server_rec (server_zero)
            and arp_pool_t (pool_zero), that are passed to the hook
            registered via ap_hook_child_init();
   2. Upon receiving a signal, I will:
          * go through all servers:
               for (server = server_zero; server; server = server->next)
            re-opening their respective error_logs (each one has its own
            mutex already).
          * I will then go through all cleanup_t entries of the
            pool_zero, looking for those, that have
            apr_unix_file_cleanup listed in their plain_cleanup_fn field
            and treating their "data" records as the apr_file_t they are.

The file_reopen function would compare the st_dev and st_ino numbers of 
the stat structures filled by fstat-ing the current apr_file_t's filedes 
and stat-ing its fname. If a change is detected, it will open a new 
file-descriptor and, upon success, assign its value to filedes, then 
closing the old value. This will all happen while holding the existing 
thlock of the apr_file_t, if necessary.

I'm going to ignore the pipes for now, on the assumption, that people 
using them are happy with their own log-rotations. I will also, of 
course, ignore files opened for anything, but writing (in append-mode).

The questions:

   1. Am I right thinking, that the pool_zero pool will contain all
      "interesting" files?
   2. What is the right "hook" for the reoping? Safely the
      signal-handler can only set a flag, which must be examined later
      -- where? Perhaps, I can -- from the signal-handler -- inject
      myself with ap_hook_log_transaction to be called upon the next
      transaction, perform the reopening and remove myself then?

Or should I just stick to changing the mod_log_config as I initially 


View raw message