httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Carsten Wiedmann <carsten_st...@gmx.de>
Subject Re: [mod_fcgid] can't find apr headers
Date Thu, 10 Dec 2009 12:03:03 GMT
Jeff Trawick schrieb:
>>> /usr/local/build/config_vars.mk includes /usr/local/include/apr-1 in
>>> EXTRA_INCLUDES
>>>   (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
> https://issues.apache.org/bugzilla/ 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
condig_vars.mk.


>> 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

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 ;-) )


>> So for me there is only one problem left. php_apc does not work together
>> with mod_fcgid. And the question, who the guilty party is (mod_fcgid or
>> apc...). Only the first request for a file is working, a core dump at the
>> second, and so on.
> 
> As for the core dump, open a bug with the component that is
> segfaulting. (I'm guessing PHP or APC, which are developed at
> php.net.)
> 
> Somewhat separately, can APC work as desired with mod_fcgid barring
> any implementation bugs?  I don't know.  See the discussion in
> https://issues.apache.org/bugzilla/show_bug.cgi?id=48110

Hm, I guess it's a problem with APC. There are also bug reports in the APC
bug tracker regarding fast-cgi. Of course, eAccelerator is working with
fast-cgi. Well, I don't need this progressbar "feature" from APC, so
eAccelerator is also ok.


Regards,
Carsten


Mime
View raw message