Re: cvs commit: apache-1.3/src/modules/standard mod_so.c

[Paul Sutton <pa...@c2.net>]

On Tue, 10 Mar 1998, Ralf S. Engelschall wrote:
>   1. Because our server configuration is read twice the modules
>      were loaded twice which is both not needed and leads to confusion later on
>      unload because the OS-internal load counter increases. Then on unload the
>      module pointer was removed from the Apache core structure on the first
>      unloads but (because of the load counter) the modules were removed later.
>      Although this worked, it was very ugly. The only consequence is that we now
>      keep track of loaded modules ourself and don't rely on the dynamic loader
>      of the platform. This now also avoids multiply tries to unload an already
>      unloaded module and thus removes harmless but irritating error_log entries
>      ``[error] Cannot remove module mod_setenvif.c: not found in module list''.
>      as shown below.

Why do you get the error messages? It should load the module and
register it for cleanup. Then when the pool is cleared during the
start-up it is unloaded, and loaded again. So on the second load
during the start-up the modules have already been unloaded.

On Linux you should get:

(initial loads on stderr, as normal).

[debug] mod_so.c(163): unloaded module mod_userdir.c
[debug] mod_so.c(163): unloaded module mod_setenvif.c
[debug] mod_so.c(163): unloaded module mod_negotiatio
[debug] mod_so.c(163): unloaded module mod_mime.c
[debug] mod_so.c(163): unloaded module mod_log_config
[debug] mod_so.c(163): unloaded module mod_include.c
[debug] mod_so.c(163): unloaded module mod_imap.c
[debug] mod_so.c(163): unloaded module mod_env.c
[debug] mod_so.c(163): unloaded module mod_dir.c
[debug] mod_so.c(163): unloaded module mod_cgi.c
[debug] mod_so.c(163): unloaded module mod_autoindex.
[debug] mod_so.c(163): unloaded module mod_auth.c
[debug] mod_so.c(163): unloaded module mod_asis.c
[debug] mod_so.c(163): unloaded module mod_alias.c
[debug] mod_so.c(163): unloaded module mod_actions.c
[debug] mod_so.c(163): unloaded module mod_access.c
[debug] mod_so.c(211): loaded module access_module
[debug] mod_so.c(211): loaded module action_module
[debug] mod_so.c(211): loaded module alias_module
[debug] mod_so.c(211): loaded module asis_module
[debug] mod_so.c(211): loaded module auth_module
[debug] mod_so.c(211): loaded module autoindex_module
[debug] mod_so.c(211): loaded module cgi_module
[debug] mod_so.c(211): loaded module dir_module
[debug] mod_so.c(211): loaded module env_module
[debug] mod_so.c(211): loaded module imap_module
[debug] mod_so.c(211): loaded module includes_module
[debug] mod_so.c(211): loaded module config_log_modul
[debug] mod_so.c(211): loaded module mime_module
[debug] mod_so.c(211): loaded module negotiation_modu
[debug] mod_so.c(211): loaded module setenvif_module
[debug] mod_so.c(211): loaded module userdir_module
[debug] mod_so.c(266): loaded file mod_status.so

... with corresponding unloads after a TERM, or unload/load sequence
during a HUP/USR1.

Paul