Internal server error while installing mod

[butch2k]

i encountered the same kind of errors a while back using plesk on a server and fixed it using relative path in SMF rather than the proposed (and wrong) absolute one.

[LiroyvH]

This seems related.
http://www.simplemachines.org/community/index.php?topic=372905.0

AB was on a server running php in CGI mode. Illori most likely in mod_php (DSO).
I wonder what your full chown and chmod settings are.

[Herman's Mixen]

check for SElinux

kernel:[1016560.129073] nf_ct_ftp: dropping packetIN= OUT=lo SRC=0000:0000:0000:0000:0000:0000:0000:0001 DST=0000:0000:0000:0000:0000:0000:0000:0001 LEN=436 TC=0 HOPLIMIT=64 FLOWLBL=0 PROTO=TCP SPT=21 DPT=40186 SEQ=1845996668 ACK=1022066861 WINDOW=265 RES=0x00 ACK PSH FIN URGP=0 OPT (0101080A3C92E6213C92816C)

as tis looks like it...

[LiroyvH]

Actually that would be related to iptables. He probably has CSF running.
SELinux is something different.

[Ricky.]

Alright..  this is insane.. I was avoiding to work on SMF install on this server  as I had plan to look into this issue again , so finally I decided to work on it and actually took backup of things, even took server snapshot as had decided to go liberal to fix it.
But..
It just installed easily and without any problem..

That is making crazy.. its my server, had not done anything apart of reboot 2 days back when stupid datacenter guy thought I need it in single user mod for some diagnose..

I think something is changed, gonna check it now.. first logs

[LiroyvH]

[LiroyvH]

Did your /tmp get cleared upon reboot? *curious*

[Ricky.]

Nothing in logs, and at once I thought SuPHP is not working but it is  !

Is that on reboot , /tmp get cleared.. but hows that effect things ?

[LiroyvH]

Of course suPHP works.

Hmm... I never asked; what caching do you have compiled to Apache?
And before the errors started occuring, had you just recompiled Apache/PHP?

[Ricky.]

That was a new DA server, initially hardened and running DirectAdmin. Everything was find unless I made first SMF installation and rest  you know. And NOPE I am not able to recall that I did anything on this server apart of tweaking firewall as per complaints of few clients this server (CSF firewall).


And interestingly this time it had not even asked for ftp login and and username.

Btw, what do you mean by caching.. Apache handler ?
Its fastCGI ..

[LiroyvH]

Alrighty.

Nope I mean something like eAccellerator or XCache or APC.

[Ricky.]

You mean PHP accelerator..

Nope , none so far, and I forgot that  
Will do APC though ..

[Arantor]

No, caching.

SMF doesn't know or care about opcode caches but eAccelerator, XCache and APC all have data storage APIs.

That said, the out of the box configuration will cache opcode caches to be largely pointless.

[LiroyvH]

Indeed ^  Caching.

Either way, reason I ask is because I've seen this type of behavior (spitting out strange errors while no misconfiguration exists, no matter which PHP mode (DSO/mod_php, suPHP, (F)CGID and no matter which MPM either.)) with 2 types of caching that make use of /tmp where after a httpd restart or PHP recompile (which also invokes a reload, lol.) the errors started occurring.
Doing mysql shutdown, destroy everything in /tmp, restart httpd and bring mySQL back up fixed those problems. (The mySQL shutdown because of it's socket ex.)
Problems varied from ridicilous permission errors to attachments being unable to save because it had problems with /tmp.
Till today, i'm still not entirely sure why it showed that behavior. I haven't seen it ever since PHP 5.3.22. I have theories but because the issues don't occur anymore it's hard to check, lol.

To note: I'm not sure if the caching had anything to do with it, the servers so happened to have it. And one server that didn't have it didn't show issues; but that isn't conclusive.


On a sidenote by the way... You said "suPHP works" but later on mention "Handler is FCGI". That means it's not suPHP, but FCGI. suPHP is a handler, just like FCGI is a handler. The two don't run simultaneously, or at least: not that I have ever seen, heard or read about nor been prompted the option
You could be running SuHosin with FCGI perhaps?
It doesn't really matter, FCGI acts quite similar in quite some cases, but suPHP is just so slightly more secure (and resource intensive..) where as FCGI requires moar extra security.

[Chen Zhen]

Imo ensure php.ini settings are properly configured.
(ie. if using apache location is:  /etc/php5/apache2/php.ini)

• Configure temp upload directory
• Change (increase) upload max limit, memory limit and related time intervals if necessary
• Set permissions for that temp folder to 0755 and ownership to www-data:www-data

[Ricky.]

Indeed ^  Caching.

Either way, reason I ask is because I've seen this type of behavior (spitting out strange errors while no misconfiguration exists, no matter which PHP mode (DSO/mod_php, suPHP, (F)CGID and no matter which MPM either.)) with 2 types of caching that make use of /tmp where after a httpd restart or PHP recompile (which also invokes a reload, lol.) the errors started occurring.
Doing mysql shutdown, destroy everything in /tmp, restart httpd and bring mySQL back up fixed those problems. (The mySQL shutdown because of it's socket ex.)
Problems varied from ridicilous permission errors to attachments being unable to save because it had problems with /tmp.
Till today, i'm still not entirely sure why it showed that behavior. I haven't seen it ever since PHP 5.3.22. I have theories but because the issues don't occur anymore it's hard to check, lol.

One more mysterious case added, may be full system restart did the trick as I avoid server restart ,.. you see those shiny uptime things

In a sidenote by the way... You said "suPHP works" but later on mention "Handler is FCGI". That means it's not suPHP, but FCGI. suPHP is a handler, just like FCGI is a handler. The two don't run simultaneously, or at least: not that I have ever seen, heard or read about nor been prompted the option
You could be running SuHosin with FCGI perhaps?
It doesn't really matter, FCGI acts quite similar in quite some cases, but suPHP is just so slightly more secure (and resource intensive..) where as FCGI requires moar extra security.

My bad.. all the time I was typing suPHP but I was actually referring to suhosin .

[LiroyvH]

Uptime counters I abandoned for a while haha, figured kernel updates are slightly more important than a shiny counter, plus... I had a server up for 700+ days or something and then there was a power outage in the datacenter. *RAGE* It's no use!