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
DEFAULT_REL_RUNTIMEDIR:
- 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
config.
- 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.
Regards,
Rainer
