httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rainer Jung <>
Subject Re: httpd 2.4.1 and mod_slotmem_shm / mod_proxy_balancer (AH01179)
Date Wed, 07 Mar 2012 03:13:11 GMT
On 07.03.2012 02:01, Daniel Ruggeri wrote:
> On 3/6/2012 6:32 PM, Rainer Jung wrote:
>> I like the idea even if the current problem will be fixed without. I
>> think the locations of all created or read file can be influenced by
>> configuration except for some implicit files in
>> DEFAULT_REL_RUNTIMEDIR, which is a build time setting. So being able
>> to influence helps in post build adoption of the layout.
> Yes, this is vital. I'm still trying to grok the intention of
> DEFAULT_REL_RUNTIMEDIR, but if we are talking about a file used as a
> mutex/shared file/etc, wouldn't NOT having such a directive or
> configuration parameter cause contention between multi-instance
> configurations where "httpd -c /path/to/conf1.conf" and "httpd -c
> /path/to/conf2.conf" end up pointing to the same file even though they
> share nothing else in common? Seems like some stepping-on-of-toes would
> occur unless I'm missing something else obvious.

DEFAULT_REL_RUNTIMEDIR is defined by the layout file and usually it is 
"logs", but could also be "run". It should be used relative to the 
server root. So if you run two servers with different server root, 
there's no clash of files in DEFAULT_REL_RUNTIMEDIR.

By searching the code I find the following things placed in 

- the pid file. Can be moved using PidFile

- mutexes created by the new unified mutex handling. Should be 
configurable using "Mutex"

- some gprof dump code in the prefork MPM. Not usually used and code 
comments indicate, that the directory is also configurable (not checked)

- default data file paths for dbm and shmcb implementations of socache. 
The path can be configured when choosing the socache impl type in the 

- default path of the CGI socket. Can be configured with ScriptSock

- data file for shm in slotmem_shm. Until now if a user gave a relative 
path, the file was put underneath the server root using the relative 
path. So if the path would have been a plain file name, the file would 
have been created directly in the server root. Now after Jim's change a 
relative path will be resolved relative to DEFAULT_REL_RUNTIMEDIR which 
is usually meant to be writable. The path itself is confgurable.

So to sum up: all uses of DEFAULT_REL_RUNTIMEDIR I can see at the moment 
are overwritable by configuration. A runtime configurable runtime 
directory would not be a critical feature but make it easy to move all 
these objects in a common directory not known at build time.

With respect to your question about multi-instances I'd say that 
unfortunately the directive makes conflicts more likely. Without the 
directive users are forced to use different server roots for their 
instances, e.g. to keep log files separate. If they go into the business 
of configuring the paths of all objects written individually, they can 
do so for the above list as well.

Now having the directive, it could be that they always try to use 
/var/run/apache or similar as the runtime directory for all instances 
which will immediately lead to conflict. Of course all is a matter of 
documentation first and then education (RTFM).

After reading the code IMHO the docs for socache and slotmem could be a 
bit more explicit about the data files used. Since e.g. socache modules 
are only provider implementations, their docs pages only say that they 
don't have any configuration directives. Only in the uncommented example 
of how to activate socache you can see a path name that's not explained.



View raw message