PHP4 Core Dumps

[VeZoZ]

I'm having problems with PHP4 causing core dumps with a suPHP configuration and previously with apache 1.3 with php4 as a module the pages simply would not load.

What appears to be causing it is

include("http://someurl.com");


Anyone know of any modules that would cause this? Never had this issue before until switching to the new apache build system in cPanel.

 

[VeZoZ]

Well I figured out what the issue was it's zend causing the core dumps.

So now I just need to install an older version of Zend for PHP4. Appears the cPanel's chosen version does not play nicely with some PHP4 functions.

 

[cPanelKenneth]

Zend Opt is a hit-or-miss extension. A combination (PHP + zend opt) that works fine on one server will not work fine on another. Especially is this the case with PHP 4.

 

[Kent Brockman]

I'm also finding core dump files since Zend Opt was installed.
The core.* files appear in diferent user account folders, and are about 35 MB in size. They appear intermittently. I wish to know how to determine why are these files there in order to debug the source of this, or if core dumping may be disabled somewhere since it's not bringing relevant info to me.

 

[VeZoZ]

I found they were mostly coming from url includes.

Easiest fix is to run an older version of zend optimizer I believe 3.2.1 and 3.2.0 are fine. 3.3.0 seemed to cause the dumps for me.

 

[Kent Brockman]

Maybe. But for some reason the core dumps aren't dumped everytime I run a PHP file including remote resources. I found core dump files in folders where those php components include relative path from within the same domain. These components are part of high traffic websites and should be dumping core files in a major quantity, but I'm finding ocurrences only twice a week in different domains.
May this occur only when special circumstances are present? maybe concurrent include request form the same components at the same time?
Next time I'll double check the time and date of creation of these core files in differents domains. May be due to any correlation with overload of the server.

 

[cPanelKenneth]

We changed teh PHP Extension Manager to install an older 3.2.x version of Zend Opt when PHP 4 is being used. Are you both using PHP 4?

 

[Kent Brockman]

We changed teh PHP Extension Manager to install an older 3.2.x version of Zend Opt when PHP 4 is being used. Are you both using PHP 4?

Here we are using PHP 4.4.8+5.2.5 with Zend Extension Manager v1.2.0 + Zend Optimizer v3.3.0

These dual configs of PHP were compiled last February when cPanel was 11.18.0-S20595. Since that moment, the core dumps began appearing in the user accounts.

 

[rdsupport]

the same with me
i'm using PHP 4.4.8+5.2.5 with Zend Extension Manager v1.2.0 + Zend Optimizer v3.3.3

but for now i had disable the php4 with this
Whm -> Configure Php And Suexec -> select PHP 4 Handler " none" -> save

but i'm still find the core.xxx files generated again

 

[Kent Brockman]

The core dump files are found generally in folders containing public dynamic php forms, so I suppose it is due to some kind of abuse. Although the logs aren't showing anything strange at the moment in which the core files were created.
How can this be narrowed down to take a more detailed conclusion about the origin of these files and how to mitigate the factors that facilitate its generation?

 

[Kent Brockman]

No clues? Is there any way to determine what script is causing the core dump?

 

[mctDarren]

Use gdb to examine the core file.

 

[Kent Brockman]

Use gdb to examine the core file.

Can you explain any more? what is the syntax to use?

 

[mctDarren]

Type man gdb. This will explain the gdb program. In fact, man should become your best friend, as it will explain a lot as you learn more about linux. man cmd can be invaluable.

To answer this question, gdb -c core_filename will examine the core file. Core files are snapshots of a programs state at the point of failure. That big number in the filename is the process id (PID). That can help you track down the program/script that caused it as well.

To the OP: You can stop core files from being produced as a result of suPHP and Rlimit stoppages. In /etc/init.d/httpd at the top of the file you'll see the ulimit command line. Add a "-c 0" (slash-c-zero) to the line:

ulimit -c 0 -n [i]x[/i]

where the x above is the number previously assigned by your Rlimit script. That should stop core dump files if you want them stopped. Just keep in mind that you won't have a way to know when Apache has throttled a rogue script that probably should be addressed on shared servers. Hope that helps.

 

[Kent Brockman]

To answer this question, gdb -c core_filename will examine the core file. Core files are snapshots of a programs state at the point of failure. That big number in the filename is the process id (PID). That can help you track down the program/script that caused it as well.

okay, given the process PID, how can you know what process has that PID assigned?

To the OP: You can stop core files from being produced as a result of suPHP and Rlimit stoppages. In /etc/init.d/httpd at the top of the file you'll see the ulimit command line. Add a "-c 0" (slash-c-zero) to the line:

ulimit -c 0 -n [i]x[/i]

where the x above is the number previously assigned by your Rlimit script. That should stop core dump files if you want them stopped. Just keep in mind that you won't have a way to know when Apache has throttled a rogue script that probably should be addressed on shared servers. Hope that helps.

I have these values in my /etc/init.d/httpd file:

ulimit -n 1024
ulimit -n 4096
ulimit -n 8192
ulimit -n 16384

Should I modify these four lines?