I've noticed that if you emerge lighttpd 1.4.26-r1 (dunno about others) without use flag "fastcgi" enabled, lighttpd stills compile with that support. I've check the ebuild and it contains this: if ! use fastcgi ; then rm -f ${libdir}/mod_fastcgi.* fi But it doesnt work properfly because: # locate mod_fastcgi /usr/lib/lighttpd/mod_fastcgi.so /usr/lib/lighttpd/mod_fastcgi.la I've also deleted those libs manually, re-emerge lighttpd without fastcgi use flag, and those libs appear again. Reproducible: Always Steps to Reproduce: 1.emerge lighttpd without "fastcgi" use flag 2.libs are there 3.fastcgi works Actual Results: Lighttpd uses fastcgi when its supposely to crash if you include the "mod_fastcgi" (because the libs shouldnt be there) Expected Results: mod_fastcgi shouldnt work
given that the fastcgi use flag does not in any way change the build process but only the ebuild contents it should probably be dropped. back when spawn-fcgi was included in the lighttpd ebuild, the fastcgi use flag made more sense, as it would not build spawn-fcgi then. if the flag is kept it probably also should not install the fastcgi configuration file when disabled...
yea, it also shouldnt install the config file as you said. would be nice if "fastcgi" use flag install spawn-fcgi, but since is not a required dependency, maybe it doesnt make sense at all. what it makes more sense is fix the ebuild so it removes this files when "fastcgi" flag is disabled: /usr/lib/lighttpd/mod_fastcgi.so /usr/lib/lighttpd/mod_fastcgi.la /etc/lighttpd/mod_fastcgi.conf
(In reply to comment #2) > what it makes more sense is fix the ebuild so it removes this files when > "fastcgi" flag is disabled: > > /usr/lib/lighttpd/mod_fastcgi.so > /usr/lib/lighttpd/mod_fastcgi.la > /etc/lighttpd/mod_fastcgi.conf > while this may be more sensical, i would disagree that this is a usefull application of a useflag. IMHO the fastcgi flag should simply be removed.
Yeah, im agree. It was just an idea to fix it, but the use doesnt make sense because it doesnt affect the compilation. Its just like mod_rewrite, mod_alias, mod_auth, etc, those doesnt have any use flag, so mod_fastcgi shouldnt neighter.
I am currently working to lighttpd-1.4.28 so I will drop this flag to that ebuild. I do not want to touch the stable package.
Fixed in .28 Thanks for reporting
not fixed at all: uranus ~ # tail /var/log/lighttpd/error.log If this is PHP on Gentoo, add 'fastcgi' to the USE flags. 2011-01-07 12:08:06: (mod_fastcgi.c.1399) [ERROR]: spawning fcgi failed. 2011-01-07 12:08:06: (server.c.938) Configuration of plugins failed. Going down. 2011-01-07 12:32:09: (log.c.166) server started 2011-01-07 12:32:09: (mod_fastcgi.c.1104) the fastcgi-backend /usr/bin/php-cgi failed to start: 2011-01-07 12:32:09: (mod_fastcgi.c.1108) child exited with status 2 /usr/bin/php-cgi 2011-01-07 12:32:09: (mod_fastcgi.c.1111) If you're trying to run your app as a FastCGI backend, make sure you're using the FastCGI-enabled version. If this is PHP on Gentoo, add 'fastcgi' to the USE flags. 2011-01-07 12:32:09: (mod_fastcgi.c.1399) [ERROR]: spawning fcgi failed. 2011-01-07 12:32:09: (server.c.938) Configuration of plugins failed. Going down. uranus ~ # USE="fastcgi" emerge -DaNuv world These are the packages that would be merged, in order: Calculating dependencies... done! Total: 0 packages, Size of downloads: 0 kB Nothing to merge; would you like to auto-clean packages? [Yes/No] n Quitting. uranus ~ # USE="-fastcgi" emerge -DpNuv world These are the packages that would be merged, in order: Calculating dependencies... done! Total: 0 packages, Size of downloads: 0 kB uranus ~ #
remerge dev-lang/php with USE="fpm" fixed it for me.
There is no fastcgi flag in 1.4.28
I can see that; that's why .28 is a regressed version, and should be removed AT ONCE from stable. Because it breaks features compared to previous one. Service/daemon does not start with degraded service/features; service/daemon does not start at all. Worst, from init/rc point of view, the service/init script starts, what satisfies deps, but daemon dies silently (yes, whatever loud the shout is in messages, it is silent, compared to the failure that SHOULD happen in boot screen). If you do not remove .28 from stable, i will have to create a bug against "claims to be started, but is not really started".
(In reply to comment #10) > I can see that; that's why .28 is a regressed version, and should be removed AT > ONCE from stable. Because it breaks features compared to previous one. > Service/daemon does not start with degraded service/features; service/daemon > does not start at all. Worst, from init/rc point of view, the service/init > script starts, what satisfies deps, but daemon dies silently (yes, whatever > loud the shout is in messages, it is silent, compared to the failure that > SHOULD happen in boot screen). > > If you do not remove .28 from stable, i will have to create a bug against > "claims to be started, but is not really started". > I don't even understand what you are talking about. The lighttpd installs the fastcgi modules anyway. What do you mean that the daemon does not start? Please open a separate bug explaining your problem cause I must admin I don't understand what is wrong with lighttpd atm
