# Apache not handling POST requests

## RandomDan

This one has me baffled.

4 boxes all running ~x86, all different physically but with very similar configurations. Each one up dated every day, be that good or bad. And each one now has a broken install of Apache.

Although Apache is happily serving GET requests without any trouble at all, a POST request is a non starter.

I have FCGID sites, the POST request never makes it as far as the cgi program... the browser just sits waiting for a reply.

I have (on 2 of the boxes) PHP, I tried to log into phpldapadmin and I get a zero sized reply to the login post request.

In the log I see messages along the lines of

[Sat Dec 04 00:01:48 2010] [notice] child pid 29887 exit signal Segmentation fault (11)

I've followed the usual practice of reinstalling apache, apr, apr-utils from scratch, I've rolled back to previous versions, I've reinstalled and rolled back upgrades that have occurred over the last few days. I think this problem started around Wednesday, but seeing as I don't post every day, that might not be too precise.

Below is my reasonably minimal apache config for a box without PHP. This is it's current state after I started disabling modules to see if I could track down the problem to one of them, but no luck there either.

```

ServerRoot /usr/lib/apache2

ServerName www.randomdan.homeip.net

ServerAdmin dan.goodliffe@randomdan.homeip.net

PidFile /var/run/apache2.pid

ErrorLog /var/log/apache2/error.log

LogFormat "%h %u %t %V \"%r\" %>s %b" common

CustomLog /var/log/apache2/access.log common

LogLevel debug

User apache

Group web

Listen 80

Timeout 300

KeepAlive On

MaxKeepAliveRequests 100

KeepAliveTimeout 15

ServerSignature On

#LoadModule authz_host_module modules/mod_authz_host.so

#LoadModule mime_magic_module modules/mod_mime_magic.so

#LoadModule mime_module modules/mod_mime.so

#LoadModule autoindex_module modules/mod_autoindex.so

#LoadModule cgid_module modules/mod_cgid.so

LoadModule vhost_alias_module modules/mod_vhost_alias.so

#LoadModule dir_module modules/mod_dir.so

#LoadModule deflate_module modules/mod_deflate.so

#LoadModule ldap_module modules/mod_ldap.so

#LoadModule authnz_ldap_module modules/mod_authnz_ldap.so

LoadModule log_config_module modules/mod_log_config.so

LoadModule env_module modules/mod_env.so

LoadModule rewrite_module modules/mod_rewrite.so

LoadModule depends_module modules/mod_depends.so

LoadModule transform_module modules/mod_transform.so

LoadModule fcgid_module modules/mod_fcgid.so

<Directory />

        Options FollowSymLinks Indexes ExecCGI

        AllowOverride All

</Directory>

#DirectoryIndex index.html index.xml index.htm index.cgi

VirtualDocumentRoot /var/www/vhosts/%0/

AccessFileName .htaccess

AddOutputFilterByType DEFLATE text/html text/plain text/xml

UseCanonicalName Off

DefaultType text/plain

HostnameLookups Off

#AddHandler cgi-script .cgi

#ScriptLog /var/www/files/script.log

#AddType application/x-httpd-php .php

#AddType application/x-httpd-php .xphp

#AddType text/xsl .xsl

#AddType text/xml .xml

```

Any help or ideas or hints or anything, much appreciated at this point, I'm at a total loss!

----------

## erik258

I don't know anything about fcgid - I'm a PHP user myself - but have you rebuilt fcgid against your new apache?

Now I'm going to rant about the following quote, not for you as much as for greater community, lest they get wacky ideas.  

 *Quote:*   

> 
> 
> Each one up dated every day, be that good or bad.

 

Definitely bad, in my opinion, if you mean they update automatically and they're in production, by which I mean their services actually matter.  I've done the auto-update thing myself on some toy boxes, but I'd never do it in production.  If the four servers are nearly identical, and you really want to auto-build packages, why not have itself take itself out of production on a daily basis and rebuild things?  You can then test the updates before you break everything else :)

But honestly, auto updates aren't a smart idea:

1) not all updates are a good idea; even if you're running stable, little bugs and such sneak in.  They'll be quickly fixed, typically, but in the mean time your servers could be broken.

2) all your updates are, I assume, done all at once, without your oversight, so how can you be sure which update - or combination - broke what?  

3) pointless.  I mean honestly, what's the point of this?  It seems very silly to me, rebuilding essential packages automatically on a daily basis.  I don't like that it removes the admin from the equation, and I really don't like that it gives people the impression that gentoo will auto-manage itself, which, as a gentooer for over 8 years now, I assure you is not the case.  

The only good thing to say about it is that it is fast in that it doesn't require you to initiate the procedure, and that it keeps your systems up to date so you don't drift too far away from the current package sets  -- which as we all know can cause pain for gentooers.    So if you really want those not-so-stunning benefits, why not do things the professional way and _test_ your new packages _before_ you roll them out to all the systems?

I personally like the idea of auto-updating the portage tree at some interval, so you don't have to do it before you install packages.  I also really like the idea of, directly after doing a sync, executing something like 'emerge -pvNDu world > /tmp/emergeworld.pretend' to see just how up to date you are or aren't.  

You can also experiment with --buildpkgonly command to emerge.  That essentially does all the work of building the package, but doesn't actually merge it into the system, but rather packages it all up and stuffs it in /usr/portage/packages, where you can merge and test it at your convenience and then push the very same package out to all your servers.  If your boxes are as homogeneous as you say, this should work really well, and I'd definitely identify it as an emerge best practice in production environments with homogeneous systems. 

-- DF

Just my two cents.

----------

## RandomDan

I'd hoped not to get into a debate about how and when I update so soon. It's fair to say I understand and accept the risks. They're "only dev" boxes, you could argue keeping them up to date helps you find out about potential pit falls before you accidently roll something in live.... but this is getting off topic.

So lets say I updated 1 box on Thursday for the first time in a week and it now has this problem.

I've rebuilt PHP on the boxes that have it and mod fcgid, and no change. What I haven't got round to yet is just posting to a regular CGI script, just for laughs, to see if that's the same, it'll effectively rule out it being something in one of the 3rd party modules.

----------

## butchie

I have the same problem, running also ~x86 on this box. After an upgrade, my php scripts can't POST any thing. 

In the Apache logs I get :

```
[Sat Dec 04 22:04:38 2010] [notice] child pid 28565 exit signal Segmentation fault (11)
```

I tried to reverse back to apache-2.2.16, without success.

Re-emerging php didn't help.

----------

## HolgerH

 *butchie wrote:*   

> I have the same problem, running also ~x86 on this box. After an upgrade, my php scripts can't POST any thing. 
> 
> In the Apache logs I get :
> 
> ```
> ...

 

I had the same problem. A not so wild guess: you guys all built the latest apache with gcc-4.5.1? If so, there's your problem. Just revert to 4.4.5, rebuild apache and all should be fine. I'm staying the hell away from gcc-4.5.1 for the foreseeable future.

-h

----------

## Hu

Following the hint from HolgerH, could one of the affected users post the output of emerge --info?

----------

## butchie

Here is mine :

```
emerge --info

Portage 2.1.9.25 (default/linux/x86/10.0/desktop, gcc-4.5.1, glibc-2.12.1-r3, 2.6.35-gentoo-r5 i686)

=================================================================

System uname: Linux-2.6.35-gentoo-r5-i686-Genuine_Intel-R-_CPU_T2400_@_1.83GHz-with-gentoo-2.0.1

Timestamp of tree: Sat, 04 Dec 2010 14:15:01 +0000

ccache version 3.1.3 [enabled]

app-shells/bash:     4.1_p9

dev-java/java-config: 2.1.11-r2

dev-lang/python:     2.4.6, 2.5.4-r4, 2.6.6-r1, 2.7.1, 3.1.3

dev-util/ccache:     3.1.3

dev-util/cmake:      2.8.1-r2

sys-apps/baselayout: 2.0.1-r1

sys-apps/openrc:     0.6.7

sys-apps/sandbox:    2.4

sys-devel/autoconf:  2.13, 2.68

sys-devel/automake:  1.4_p6-r1, 1.8.5-r3, 1.9.6-r3, 1.10.3, 1.11.1

sys-devel/binutils:  2.20.1-r1

sys-devel/gcc:       3.4.6-r2, 4.1.2, 4.4.5, 4.5.1-r1

sys-devel/gcc-config: 1.4.1

sys-devel/libtool:   2.4-r1

sys-devel/make:      3.82

virtual/os-headers:  2.6.36.1 (sys-kernel/linux-headers)

ACCEPT_KEYWORDS="x86 ~x86"

ACCEPT_LICENSE="*"

CBUILD="i686-pc-linux-gnu"

CFLAGS="-march=prescott -O2 -pipe -fomit-frame-pointer"

CHOST="i686-pc-linux-gnu"

CONFIG_PROTECT="/etc /usr/share/config"

CONFIG_PROTECT_MASK="/etc/ca-certificates.conf /etc/env.d /etc/env.d/java/ /etc/fonts/fonts.conf /etc/gconf /etc/gentoo-release /etc/php/apache2-php5.3/ext-active/ /etc/php/cgi-php5.3/ext-active/ /etc/php/cli-php5.3/ext-active/ /etc/revdep-rebuild /etc/sandbox.d /etc/terminfo"

CXXFLAGS="-march=prescott -O2 -pipe -fomit-frame-pointer"

DISTDIR="/usr/portage/distfiles"

FEATURES="assume-digests binpkg-logs ccache distlocks fixlafiles fixpackages news parallel-fetch protect-owned sandbox sfperms strict unknown-features-warn unmerge-logs unmerge-orphans userfetch"

GENTOO_MIRRORS="http://gentoo.modulix.net/gentoo/ "

LANG="fr_FR@euro"

LC_ALL="fr_FR@euro"

LDFLAGS="-Wl,-O1 -Wl,--as-needed"

LINGUAS="fr"

MAKEOPTS="-j3"

PKGDIR="/usr/portage/packages"

PORTAGE_CONFIGROOT="/"

PORTAGE_RSYNC_OPTS="--recursive --links --safe-links --perms --times --compress --force --whole-file --delete --stats --timeout=180 --exclude=/distfiles --exclude=/local --exclude=/packages"

PORTAGE_TMPDIR="/var/tmp"

PORTDIR="/usr/portage"

SYNC="rsync://rsync.europe.gentoo.org/gentoo-portage"

USE="X a52 aac acl acpi alsa apache2 apm avi berkdb branding bzip2 cairo cdr cli consolekit cracklib crypt cups cxx dbus dga divx4linux dmi dri dts dv dvd dvdr dvdread emboss encode exif fam fame firefox flac foomaticdb fortran gdbm gif gpm gtk hal iconv jpeg kde lame lcms ldap libnotify lm_sensors mad mikmod mmx mng modules mp3 mp4 mpeg mudflap mysql ncurses nls nptl nptlonly odbc ogg opengl openmp pam pango pcre pdf perl png ppds pppd python qt qt3support qt4 quicktime readline samba sdl semantic-desktop session slp spell sse sse2 ssl startup-notification subtitles svg sysfs tcpd tga tiff truetype unicode usb userlocales v4l2 vorbis webkit x264 x86 xcb xml xorg xulrunner xv xvid zlib" ALSA_CARDS="intel8x0 hda-intel" ALSA_PCM_PLUGINS="adpcm alaw asym copy dmix dshare dsnoop empty extplug file hooks iec958 ioplug ladspa lfloat linear meter mmap_emul mulaw multi null plug rate route share shm softvol" APACHE2_MODULES="actions alias auth_basic auth_digest authn_anon authn_dbd authn_dbm authn_default authn_file authz_dbm authz_default authz_groupfile authz_host authz_owner authz_user autoindex cache dav dav_fs dav_lock dbd deflate dir disk_cache env expires ext_filter file_cache filter headers ident imagemap include info log_config logio mem_cache mime mime_magic negotiation proxy proxy_ajp proxy_balancer proxy_connect proxy_http rewrite setenvif so speling status unique_id userdir usertrack vhost_alias" COLLECTD_PLUGINS="df interface irq load memory rrdtool swap syslog" ELIBC="glibc" GPSD_PROTOCOLS="ashtech aivdm earthmate evermore fv18 garmin garmintxt gpsclock itrax mtk3301 nmea ntrip navcom oceanserver oldstyle oncore rtcm104v2 rtcm104v3 sirf superstar2 timing tsip tripmate tnt ubx" INPUT_DEVICES="evdev synaptics" KERNEL="linux" LCD_DEVICES="bayrad cfontz cfontz633 glk hd44780 lb216 lcdm001 mtxorb ncurses text" LINGUAS="fr" PHP_TARGETS="php5-3" RUBY_TARGETS="ruby18" USERLAND="GNU" VIDEO_CARDS="radeon" XTABLES_ADDONS="quota2 psd pknock lscan length2 ipv4options ipset ipp2p iface geoip fuzzy condition tee tarpit sysrq steal rawnat logmark ipmark dhcpmac delude chaos account" 

Unset:  CPPFLAGS, CTARGET, EMERGE_DEFAULT_OPTS, FFLAGS, INSTALL_MASK, PORTAGE_BUNZIP2_COMMAND, PORTAGE_COMPRESS, PORTAGE_COMPRESS_FLAGS, PORTAGE_RSYNC_EXTRA_OPTS, PORTDIR_OVERLAY

```

Indeed I am on GCC-4.5.1

Going to try suggestion to revert to GCC-4.4.5

----------

## butchie

Recompiling apache with GCC-4.4.5 did it ! Works for me.

How are we supposed to handle this situation ? Continue to emerge every updates with GCC-4.4.5 or try to switch back to GCC-4.5.1 when a new apache update comes out ?

----------

## HolgerH

 *butchie wrote:*   

> Recompiling apache with GCC-4.4.5 did it ! Works for me.
> 
> How are we supposed to handle this situation ? Continue to emerge every updates with GCC-4.4.5 or try to switch back to GCC-4.5.1 when a new apache update comes out ?

 

This is almost guaranteed to be a compiler bug, so apache should not even care. There are some very, very obscure scenarios in C where previously valid code might error out with a newer compiler, but wrong code is unconditionally wrong. For now I'd just recommend staying with 4.4.5.

This cost me quite a bit of hair too since I had just updated all my machines to 4.5.1 as well, when my server started crashing and burning for no apparent reason.

If someone could add this to b.g.o I'd be grateful, I actually came here to verify if anyone else had encountered the same problem. Glad I could help  :Smile: 

-h

----------

## butchie

Thanks a LOT for your help and your explanations.

----------

## Hu

A new release, sys-devel/gcc-4.5.1-r1 has been available since 2010/11/21.  ~arch users should upgrade to it before reporting any problems.

----------

## butchie

I was indeed using this version 4.5.1-r1 to compile apache (running ~arch did pulled it in) resulting in apache segfaulting.

```
 equery list gcc

 * Searching for gcc ...

[IP-] [  ] sys-devel/gcc-3.4.6-r2:3.4

[IP-] [  ] sys-devel/gcc-4.1.2:4.1

[IP-] [  ] sys-devel/gcc-4.4.5:4.4

[IP-] [  ] sys-devel/gcc-4.5.1-r1:4.5

```

----------

## Hu

Sorry, I misread your emerge --info.  I incorrectly thought that the gcc -r# would be included in the summary line and therefore did not inspect your listing of installed gcc versions.  Instead, the summary line is about the active gcc profile.

----------

## RandomDan

Downgrading GCC to v4.4.5 (and then reinstalling boost, grr) got my site up and running again... I can now post things again. Yay!

Thanks HolgerH!

I'd looked at GCC as a possible cause, cos it'd been masked for so long, but I've had it installed now for a while with no (noticed) ill effect. Scary to think what else might be broken.

Is there a bug filed for this? And is the problem GCC breaking Apache or Apache not compiling as expected with GCC (i.e. which one is actually is at fault?)

----------

## danjoh

Downgrading to gcc-4.4.5 solved the issue for me as well (thanks to HolgerH).

I have opened a bug for this issue: https://bugs.gentoo.org/show_bug.cgi?id=347785

----------

## jlpoole

I have Apache installed on an ARM SheevaPlug which has had no problem until the last few weeks.  Apache basically segment faults at the outset.  I've tried recompiling and running it without any directives and it just segment faults.  I even back-stepped to gcc 4.4.5 and nothing has changed.

```
plug ~ # gcc-config -l

 [1] armv5tel-softfloat-linux-gnueabi-4.4.5 *

 [2] armv5tel-softfloat-linux-gnueabi-4.5.1

plug ~ #

```

I've never had this type of problem before with Apache.  I regularly (every 3-5 days) keep my system current and I suspect something has been introduced into my tool chain that is causing problems for Apache.  I had been cross compiling, but have disengaged the cross compiling to isolate the compilation on the native processor, this was done just to remove any variables.

I just wanted to chime in here that the problem of Apache not running may be larger than the scope of the above-referenced bug.   I'm emerging gdb now to see if that might shed some light on the problem; the Apache site suggests this as one way to debug.  http://httpd.apache.org/dev/debugging.html

----------

## muhsinzubeir

 *jlpoole wrote:*   

> I have Apache installed on an ARM SheevaPlug which has had no problem until the last few weeks.  Apache basically segment faults at the outset.  I've tried recompiling and running it without any directives and it just segment faults.  I even back-stepped to gcc 4.4.5 and nothing has changed.
> 
> ```
> plug ~ # gcc-config -l
> 
> ...

 

Downgrading to gcc-4.4.5, recompile apache did the trick now I can do some more php coding   :Wink: 

----------

## mziab

According to this, it only seems to happen on the x86 arch and goes away after removing -fomit-frame-pointer from C{XX}FLAGS. Can anyone confirm this helps?

----------

## HolgerH

GCC 4.5.2 is in portage. Any brave volunteers want to try whether this still happens?  :Smile: 

----------

## SoLoR

 *HolgerH wrote:*   

> GCC 4.5.2 is in portage. Any brave volunteers want to try whether this still happens? 

 

I tryed today... it still happens so stick with 4.4.5.

 *mziab wrote:*   

> According to this, it only seems to happen on the x86 arch and goes away after removing -fomit-frame-pointer from C{XX}FLAGS. Can anyone confirm this helps?

 

I did not try this and dont intend to install gcc 4.5+ again until next version... in any case, this shouldnt be fixed in gcc, not us needing to use workarounds for something that was normaly worked for years.

----------

## SoLoR

There seems to be patch for this issue https://bzattachment.mandriva.com/attachment.cgi?id=18060 i didnt try it yet... this patch is for 2.2.17 but probably works in 2.2.16 as well... also they should bump version anyway....

----------

## jlpoole

 *HolgerH wrote:*   

> GCC 4.5.2 is in portage. Any brave volunteers want to try whether this still happens? 

 

Sure... why not? 

I successfully installed 4.5.2 and re-emerged apache-2.2.16 and I have the same problem.  I contacted the mailing list for apache apr tools and it has been recommended to me to build my own version of apache and their apr with full debug and then provide the feedback.  

My version:

```
plug ~ # uname -a

Linux plug 2.6.33.5 #3 PREEMPT Thu Sep 2 07:47:34 PDT 2010 armv5tel Feroceon 88FR131 rev 1 (v5l) Marvell SheevaPlug Reference Board GNU/Linux

plug ~ #

```

----------

## sling

Ubuntu have resolved this issue with the following patch: (http://launchpadlibrarian.net/61804673/apache2_2.2.16-6ubuntu2.debdiff).  Besides that, Apache 2.2.17 has been released in October last year.  When can we expect an official 2.2.17 ebuild together with an appropraite patch to work with gcc-4.5.2?

----------

