I just did a complete "emerge -C mod_php apache php && rm -rf /etc/apache2 && rm -rf /etc/php && emerge php apache mod_php" Then i wrote this: <? echo "works"; ?> and saved it as /var/www/localhost/htdocs/test.php calling it via browser resulted in an empty return, no error messages, no log output (even access_log was empty) and no way to figure out what's the problem. Then i changed error_reporting to E_ALL only, activated any error-reporting and logging i could find for apache2 and mod_php, and tested again. Still nothing. [tinyrant cause="has to be"]What a crap![/tinyrant] So I can only call mod_php buggy. Could someone who knows the ebuild try to fix this? I could get into serious trouble if i haven't finised coding my php-webapp until friday, wich could end up in a lawsuit against me. :(( B.t.w.: Running test.php trough the normal php (aka cli-php4) does work! Even when the two config-files are the same... Reproducible: Always Steps to Reproduce: umm... i have no sandbox?? strange thing that... should i have one? Gentoo Base System version 1.6.12 Portage 2.0.51.19 (default-linux/x86/2005.0, gcc-3.3.5-20050130, glibc-2.3.4.20041102-r1, 2.6.12-gentoo-r1 i686) ================================================================= System uname: 2.6.12-gentoo-r1 i686 AMD Athlon(tm) Processor Python: dev-lang/python-2.3.5 [2.3.5 (#1, Jun 30 2005, 11:03:26)] dev-lang/python: 2.3.5 sys-apps/sandbox: [Not Present] sys-devel/autoconf: 2.13, 2.59-r6 sys-devel/automake: 1.4_p6, 1.5, 1.6.3, 1.7.9-r1, 1.8.5-r3, 1.9.5 sys-devel/binutils: 2.15.92.0.2-r10 sys-devel/libtool: 1.5.16 virtual/os-headers: 2.6.8.1-r2 ACCEPT_KEYWORDS="x86" AUTOCLEAN="yes" CFLAGS="-O2 -march=athlon-tbird -fomit-frame-pointer -pipe -falign-functions=4" CHOST="i686-pc-linux-gnu" CONFIG_PROTECT="/etc /usr/kde/2/share/config /usr/kde/3/share/config /usr/share/config /var/bind /var/qmail/control" CONFIG_PROTECT_MASK="/etc/gconf /etc/splash /etc/terminfo /etc/env.d" CXXFLAGS="-O2 -march=athlon-tbird -fomit-frame-pointer -pipe -falign-functions=4" DISTDIR="/usr/portage/distfiles" FEATURES="autoaddcvs autoconfig candy ccache distlocks sandbox sfperms strict userpriv usersandbox" GENTOO_MIRRORS="ftp://ftp-stud.fht-esslingen.de/pub/Mirrors/gentoo/ http://ftp-stud.fht-esslingen.de/pub/Mirrors/gentoo/ http://mir.zyrianes.net/gentoo/ http://www.gigaload.org/gentoo.org/" LANG="de_DE.utf8" LC_ALL="de_DE.utf8" LINGUAS="de" MAKEOPTS="-j3" PKGDIR="/usr/portage/packages" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" SYNC="rsync://rsync.de.gentoo.org/gentoo-portage" USE="x86 3dnow aalib acl acpi alsa apache2 audiofile avi bash-completion berkdb bitmap-fonts bluetooth bzlib crypt cups curl curlwrappers dedicated dio directfb doc emboss encode exif fbcon fftw flac flash flatfile foomaticdb fortran ftp gd gdbm gif gpm gstreamer gtk2 hardened hardenedphp imagemagick imap imlib innodb ipv6 jack java jikes jpeg junit ladcca lcms libcaca libg++ libwww mad mikmod mime ming mmap mmx mng motif mp3 mpeg mysql mysqli ncurses nls nocd offensive ogg oggvorbis openal pam pcre pdflib perl php png portaudio posix ppds prelude python quicktime readline ruby samba sdl session shared sharedmem slang sndfile snmp soap sockets sox spell spl ssl svg svga tcpd threads tidy tiff tokenizer truetype truetype-fonts type1-fonts unicode usb vhosts vorbis xml2 xmms xsl xv zlib fritzcapi_cards_fcpci linguas_de userland_GNU kernel_linux elibc_glibc" Unset: ASFLAGS, CBUILD, CTARGET, LDFLAGS, PORTDIR_OVERLAY
Do you have APACHE2_OPTS="-D PHP4" set in /etc/conf.d/apache2?
Per IRC conversation, the reporter has x11-libs/xview-3.2-r3 emerged. Marking as dupe of Bug 88001. *** This bug has been marked as a duplicate of 88001 ***
Oh no, /me hates bugzilla again for jumping onto next open bug. Please disregard the previous comment. *shrug* REOPENED.
one thing, doesn't test.php just contain <? phpinfo; ?> and not <? echo phpinfo(); ?>
(In reply to comment #1) > Do you have APACHE2_OPTS="-D PHP4" set in /etc/conf.d/apache2? Sure i have. ;P And everything worked well before the last updates... I even diffed the files with an 3 days old backup to see if something went wrong...
(In reply to comment #4) > one thing, doesn't test.php just contain > <? phpinfo; ?> > and not > <? echo phpinfo(); ?> it does contain <? echo "works" ?> ;-) no idea where you got that phpinfo() from. ;)) i used the most simple thing possible. and i guess for php itself this one is even simpler than <?= "works" ?> (wich of course does not work too... ;)
(In reply to comment #6) > ;-) no idea where you got that phpinfo() from. ;)) I didn't have access to my gentoo machine and fixed php4 for a buddy some days ago, and at his machine the test file looked like it. He might have changed the test file himself. The problem there was that he hadn't added -D PHP4 in apache2 conf.d file (and restarted apache)
Do you have short_open_tag set to On in /etc/php4/apache2-php4/php.ini? Given the amount of information provided, closing as NEEDINFO/WORKSFORME. Check and fix your apache/PHP configuration.
(In reply to comment #8) > Do you have short_open_tag set to On in /etc/php4/apache2-php4/php.ini? Sometimes i think all other bug-reporters must be idiots, that you're asking me such questions. ;P I REPEAT: - "And everything worked well before the last updates..." - "I even diffed the files with an 3 days old backup to see if something went wrong..." Diffing means here: "compared the config-files of php and apache with old ones that worked before the updates, to see what had changed, and then copying the old files over the new ones replacing them." So as you clearly see it had to work. > Check and fix your apache/PHP configuration. The second thing i stated is that i UNMERGED the whole apache/php stuff, deleted all(!!!) related config-files, re-emerged the stuff, and tested it with the most simple useful test case possible. So what's remaining then to fix??? Should I possibly replace the <? echo "works"; ?> by <? echo 'works'; ?> *lol* > Given the amount of information provided, closing as NEEDINFO/WORKSFORME. Then tell me what you need to know instead of acting like a prima donna. ;P I think this information is enough because it's really easy to reproduce the problem isn't it?? I will be happy to provide you with every information you could additionally need. B.t.w.: To track the problem down i'm just emerging/testing/unmerging every mod_php-version in portage. 4.3.8 (most oldest) and 4.3.9 failed to emerge (more info on request). Now i'm trying 5.0.4 (most newest non-beta) to get a contrast. if all of them don't work we can say it's not php. but what is it then? The only thing i changed in the last weeks was that i changed the domain and installed bind9 to accommodate to this. If this can be the source of the probem please tell me so, because (don't forget: raw html-files work fine) i can't imagine this...
Okay, i'll not emerge 5.x or 4.4.x... i don't want those even more unstable dependencies borking my system...
(In reply to comment #9) > I REPEAT: > - "And everything worked well before the last updates..." Sorry, I don't know what "last updates" do you mean... You have x86 in your keywords, so I assume you have dev-php/mod_php-4.3.11 installed. Looking at 'genlop -s mod_php', that it the version that I instaled on Mon Apr 11 09:22:47 2005, so what "last updates" are you talking about? If you have unstable mod_php/apache version, indicate that in your bug report. Post exact apache and php version you have installed. Stable apache and php version work fine for me, I have no idea why did you do all the unmerging and wiping configs and emerging again. > Then tell me what you need to know instead of acting like a prima donna. ;P > I think this information is enough because it's really easy to reproduce the > problem isn't it?? Calm down. I can't reproduce this, because it *just works fine out of the box for me* for almost 3 months on quite a few machines. > B.t.w.: To track the problem down i'm just emerging/testing/unmerging every > mod_php-version in portage. 4.3.8 (most oldest) and 4.3.9 failed to emerge (more > info on request). Now i'm trying 5.0.4 (most newest non-beta) to get a contrast. Stop making mess on your system. Clean this up and emerge such apache/php versions that this bug report is about, i.e. latest stable x86 ones. Alternatively, close this bug as invalid a open a new bug report about another version that does not work for you for whatever reason.
Just to remove some simple causes here: view page source (or simular) in the browser, does that show an unparsed php file or not (since <? and ?> qualify as comments in mozilla without the -- in the tags) Could you post your /etc/conf.d/apache here? What apache and mod_php version are you using?
(In reply to comment #11) > Sorry, I don't know what "last updates" do you mean... You have x86 in your > keywords, so I assume you have dev-php/mod_php-4.3.11 installed. It's not that hard lo look at the title of this bug report isn't it? ;P Okay, i assumed that the title would make this clear, and my assumption was wrong in you case. So for you: Yes. I always mean 4.3.11 when i say "last updates", because this is the last version that's marked as stable. But let's not do overkill. I hope there aren't any more misunderstandings, so this will be solved quickly. :) > If you have unstable mod_php/apache version, indicate that in your bug report. I have not, so I indicate not. ;) I guess it's wiser to define everyting unindicated to be "normal" (as defined by all documentation avaliable), and then defining the differences. So for me you can expect that if i don't say it, don't expect the exception. ;) > Post exact apache and php version you have installed. mod_php-4.3.11 apache-2.0.54-r7 Stable apache and php version work fine for me, I have no idea why did you do all the unmerging and wiping configs and emerging again. Well. I do a weekly "emerge -uD world" after looking to "emerge -puD world" if there are any unwanted packages that i have to mask out first. And this time mod_php was one of the updated ones. The etc-update for /etc/php/apache2-php4/php.ini was like normal. I only took some of the changed parameters from the old to the new file as usual and then restarted apache. But after this no php-page did return even one char... not even the http-header (like it's now). So i thought maybe the new mod_php has problems with my options and it's wise to remove all settings and start with a fresh one. So i unmerged the stuff, removed my configs, installed everything freshly, left the configs in the default settings, enabled php ("-D PHP4") and started apache again. Then i created that simple test.php in /var/www/localhost/htdocs/, gave it chmod 644, and called it via browser. Still nothing. The strangest thing is that i really did not change anything. (with the exception of the "emerge -uD world" and the installation of bind and the changing resolv.conf to point to 127.0.0.1) And i know many poeple say they did not chane *anything*, but in fact they left something out in their explanation. And i dislike this behaviour. So i tryed to include everything i could imaging in my bug report. The baddest thing is that i still can feel thay you're sitting there thinking "damn. but this works here! there's no difference on his system an mine? there MUST be one! how else can this be??" And i agree fully to this. But i really don't know how to find that damn difference that stops it from working here. I have no idea how to start, because there *is* nothing left to set to old stade. I disabled bind, took the old resolv.conf from a backup to restore it bit-by-bit, re-installed apache and mod_php to initial state, leaving the only real difference in the packages that were installed with "emerge -uD world". So of course my first attempt was to blame the source of mod_php for this, because it's the only thing not working... But as you stated it works on your systems. So i can only imagine it's one of the other updates. I'll install genlop tomorrow and will try to put a list of those packages together to post them here. But i'm not experienced enough to manually umerge them and merging all the old packages without guidance or the risk of borking my system. So i'll leave them as-is until you tell me to do something. >Calm down. I can't reproduce this, because it *just works fine out of the box for me* for almost 3 months on quite a few machines. Sorry, I've just that huge stress hump from my deadline on friday ("deadline" is a good name. this will get damn ugly if i'm not finished :( ) As i posted this bug-report i did not know that i was the only one because i found some other threads about exactly my problem in the gentoo forums. So I thought it would be a good idea to file a bug to prevent all the others who did not emerge 4.3.11 from running into the same trouble. Now that I know that 4.3.11 (and maybe 4.3.x too with some other packages updated) is only problematic on *some* systems, I guess the best idea is to track down the real culprit. Good idea? Anyone interested in it? ;) > Stop making mess on your system. Clean this up and emerge such apache/php versions that this bug report is about, i.e. latest stable x86 ones. *g* i did not even really start. after unmerging 4.3.11 and emerging 4.3.10, testing it, unmerging it again i removed all the configs again to remove the mess, and then i looked at the other versions avaliable and saw that i would make even more mess. so i decided to reinstall 4.3.11 again and look back here. ;) So in a way i read your thoughts or you read mine. State: unmessed && reset_to_init ;)
Please, *attach* your apache and php configuration files here (i.e. don't inline). /etc/conf.d/apache2 /etc/php/apache2-php4/php.ini /etc/apache2/conf/modules.d/70_mod_php.conf /etc/apache2/conf/commonapache2.conf
(In reply to comment #12) > view page source (or simular) in the browser, does that show an unparsed php > file or not (since <? and ?> qualify as comments in mozilla without the -- in > the tags) Nope. I even did a netcat to port 80 submitting ------------- GET / HTTP/1.1 Host: intranet.somehost.org ------------- (where "intranet.somehost.org"must be replaced by a correct name that worked before the "emerge -uD world") The stuff apache returned can only be stated as "". An empty string. Not even http-headers. Nothing! links gave a "socket error" while trying the same. When i disable php in the php.ini, then i get what i expect: the plain unparsed source. plain .html work too... so apache clearly works... with one possible exception: I don't get any logfile-entries in access_log or error_log for the requests that return an empty string. > Could you post your /etc/conf.d/apache here? Okay. wait...: "No such file or directory." ;) It's /etc/conf.d/apache2. (creating attachments after message submission... ) > What apache and mod_php version are you using? See comment #13.
Created attachment 62708 [details] /etc/conf.d/apache2
Created attachment 62709 [details] /etc/apache2/conf/commonapache2.conf From my system. You will notice that it's exactly the same as the freshly installed one.
Created attachment 62710 [details] /etc/apache2/conf/modules.d/70_mod_php.conf From my system. You will notice that it's exactly the same as the freshly installed one.
Created attachment 62711 [details] /etc/php/apache2-php4/php.ini From my system. You will notice that it's exactly the same as the freshly installed one.
Comment on attachment 62708 [details] /etc/conf.d/apache2 From my system. You will notice that it's exactly the same as the freshly installed one, with one difference: APACHE2_OPTS="-D PHP4"
I'm sorry if I appeared rude or stupid :-p What does apache put in it's log files. Does it for instance give a "200" message in the access log? No http headers, that doesn't look good at all. One thing you could test is to emerge apache, php and then mod_php with CFLAGS and CXXFLAGS just set to -O2. Could be a gcc problem or optimize problem since you appear to be the only user with this problem.
(In reply to comment #21) > What does apache put in it's log files. Does it for instance give a "200" > message in the access log? For pages that got interpreted by mod_php i got no entries in any log. not in access_log, not in error_log and not in syslog. I even enabled all logging in php.ini once and still got nothing. I tested this by doing echo "" > access_log echo "" > error_log and then requesting the page with all i got. firefox, lynx, links and netcat. in the end those logs were still empty, and there was nothing about the problems in the syslog (in metalog: "/var/log/eveything/current") > No http headers, that doesn't look good at all. One thing you could test is to > emerge apache, php and then mod_php with CFLAGS and CXXFLAGS just set to -O2. > Could be a gcc problem or optimize problem since you appear to be the only user > with this problem. Well, I also read about it in the gentoo forums where at least two other poeple had exactly the same problem. But now there is another new thing: Yesterday the fan on my server's cpu stopped to work. This crashed the system. Luckily I already expected this and bought a new fan that i planned to mount on the same day in the evening. But unluckily this was too late. So after the exchange of the fan i booted up my system but there was a problem and i could not boot. I even had to do multiple fscks. And here is the real problem i guess: My filesystem for / is JFS, because i read a comparision of ext2, ext3, reiserfs, xfs and jfs, and the result showed that jfs would be the optimal thing for me. Now I guess jfs isn't that great thing, because: Why do I have to do fsck on a journaling fs? And why do I have to do it even multiple times before being bootable again? Even worse: As a result of the fscks my whole /etc dir was "lost&found", but of course in a unusable state. Now normally I would expect to blame a buggy hdd for stuff like this, but i use 2 of exactly the same disks as a raid 0 on my worksation for more than a year now, and in some long-time-tests they showed to be rather reliable. So I guess ther must be a problem with my filesystem before. And of course this would explain such strange thing as a not working mod_php. So I would recommend to close down this bug and wait, until i did some extended hardware-reliability-tests and reinstalled my system on a reiserfs root-fs. If I then still get the same error, I can come back again. But I hardly believe that I never will see the problem again. ;) I'm sorry for all the trouble this caused, but I guess we'll never find out if there still is a bug in some deep substatement of some heavily use-flag-dependend part of the php-code in combination with something other... ;) Please close the bug and choose the resolution most appropriate, because i don't know exactly what to choose... (WONTFIX? CANTFIX? WORKSFORME??)
RESOLVED INVALID I think would be the right one. Really bad luck, that stuff about the fan and jfs. I hope you get the machine up and running again with reiserfs :-p
