httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jeff Trawick <>
Subject Re: [mod_fcgid] can't find apr headers
Date Thu, 10 Dec 2009 14:07:13 GMT
On Thu, Dec 10, 2009 at 7:03 AM, Carsten Wiedmann <> wrote:
> Jeff Trawick schrieb:
>>>> /usr/local/build/ includes /usr/local/include/apr-1 in
>>>>   (if not, what is EXTRA_INCLUDES set to?)
>>> No, the apr include dir is not part of EXTRA_INCLUDES. The apr inlude dir is
>>> defined in APR_INCLUDEDIR.
>> The APR include dir should appear within both APR_INCLUDEDIR and
>> EXTRA_INCLUDES.  Report that to your httpd provider, or open a bug at
>> if you built it yourself.
> This only happens, if you build httpd with a preinstalled APR, but not with
> the bundled APR (With a preinstalled APR httpd is also using apr-1-config to
> get the values, like apxs -c). With the bundled APR the APR_INCLUDEDIR dir
> is not added to EXTRA_INCLUDES.
> With the bundled APR, that's only working for (most) people, because
> apr/apr-util doesn't (normally) respect it's own config.layout (if
> --enable-layout is used), and so the httpd and APR headers are going to the
> same directory, which is the directory defined in "includedir" in

I'm confused...  What is the condition where EXTRA_INCLUDES doesn't
find APR include files?  When the bundled APR is used with certain
non-default layouts, or something else?

>>> And and least I have to set e.g.:
>>> | FcgidIPCDir /var/run/
>>> | FcgidProcessTableFile /var/run/fcgid_shm
>>> Or Apache can't start: No access/exists to the default values of these two
>>> directives.
>> the enclosing directories exist but you can't write to it?
> Correct, and my example above is also wrong (sorry, a problem with my copy
> 'n paste). It must be e.g.:
> | FcgidIPCDir /var/run/fcgidsock

Is it true that ServerRoot wasn't writable in general?  What else had
to be changed?  ErrorLog, Pidfile, etc.?

> It's just that people must know, that
> a) FcgidProcessTableFile is created by the startup process (uid: root)
> b) the files in FcgidIPCDir are created by a worker process (e.g. uid: www)
> and for b) and if the configured FcgidIPCDir already exists, this user must
> have privs to create something in this directory.
> If only the last part of FcgidIPCDir does not exists, the startup process is
> creating this directory with the correct owner.
>>> Maybe e.g. TMPDIR should be used as default?
>> The defaults are "logs/fcgidsock" and "logs/fcgid_shm" under
>> ServerRoot.  I think DEFAULT_REL_RUNTIMEDIR is a better choice than
>> hard-coded "logs", but that wouldn't help you since your ServerRoot
>> has no "logs" directory or you have no write access anyway.  I don't
>> think a system-wide directory is an appropriate default.  (mod_fcgid
>> currently creates lock files there :( ).
> TMPDIR is just an example, because:
> - there is always a way to get a valid TMPDIR path
> - on my system it has the sticky bit, so others can't e.g. delete my
> FcgidProcessTableFile
> - if we assume there is no fcgidsock subdir at this time, the startup
> process is creating this dir with exclusive privs for e.g. the www user.
> (- well, and a log dir is for logfiles and not for e.g. sockets ;-) )

Note that DEFAULT_REL_RUNTIMEDIR isn't necessarily "logs".  Some of
the entries in config.layout have a separate "run" directory under
ServerRoot; others use /var/run.  A packager should pick something

But yes with a default httpd build you may find various run-time files
or sockets in ServerRoot/logs, depending on exactly which modules are
in use.

Individual modules shouldn't be decide the appropriate place for
run-time files, even if they could determine that TMPDIR or some other
common system directory has no security implications.  I'll fix
mod_fcgid to respect DEFAULT_REL_RUNTIMEDIR.

View raw message