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
