Cron errors since upgrading

Since updating to the new virtualmain/webmin (3.74 Pro) I get the following cron errors every hour. In looking at crontab, it appears that Virtualmin is the only thing that runs at 21 minutes past the hour.

Any ideas? sh: line 1: 22339 Segmentation fault /usr/bin/php-cgi -v 2>&1 < /dev/null sh: line 1: 22343 Segmentation fault /usr/bin/php-cgi -v 2>&1 < /dev/null

Status: 
Closed (fixed)

Comments

And I have rebooted the server to no avail.

Looks like PHP is occasionally crashing - which PHP version are you running there?

This is quite harmless though , and can be suppressed if you like by going to Webmin -> System -> Scheduled Cron Jobs , clicking on collectinfo.pl and changing the command to :

/etc/webmin/virtual-server/collectinfo.pl >/dev/null 2>&1
Joe's picture
Submitted by Joe on Sat, 11/07/2009 - 20:19 Pro Licensee

This almost certainly indicates memory allocation issues. Is this a VPS of some sort (like OpenVZ/Virtuozzo, which is notorious for this kind of problem)?

Jamie, php is version 5.2.11. Joe, this is RHL Enterprise 5 hosted at Rackspace.

PHP doesn't fail on anything else. It is only these cron jobs. No memory issues on the system. This fails every hour.

To me, anything running as root out of cron that fails with a segmentation violation is a problem and shouldn't be ignored.... This just started about 3 days ago and I had upgraded Virtualmin about 7 days ago.

I don't really think directing error output to /dev/null is a solution.

2 points....

1) My production server seems to be running php v5.2.11. Running php -v shows the version, then a Segmentation Fault.

2) My Test server seems to be running php v5.2.6. Running php -v shows the version with NO Segmentation Fault

But each system shows that all packages are up to date!!!

How can my test server be up to date when it's at the old version of PHP? I know that I installed php on the test server when prompted to do so (you had me clear yum to get the webmin components to install on both servers).

Why doesn't Virtualmin show php as needing to be updated on my test server?

tony

Did you perhaps configure the production server to use a different repository for PHP packages?

Also, are both systems using the same Linux distribution?

ronald's picture
Submitted by ronald on Sun, 11/08/2009 - 12:09 Pro Licensee

just wondering here for a second, for php 5.2.11 do you have this entry:
cgi.fix_pathinfo=0

Production server uses whatever Virtualmin uses plus the Rackspace repository. Test server uses whatever Virtualmin uses.

uname -r production = 2.6.18-128.7.1.el5 test system = 2.6.26.8-57.fc8

So they are close, but not the same.

I do not have 'cgi.fix_pathinfo=0'? in my php.ini files. I added it and restarted httpd and still get the Segmentation fault from a "php -v".

So the production system is perhaps running rackspace's PHP package? You could test with a command like :

rpm -q php

Jamie,

The only php that was loaded was loaded from Virtualmin.

What is the current version of PHP that comes through your repositories?

It told me there were several packages to update and I did but it appears there is a problem in 5.2.11 (64bit version anyway).

I listed the versions above.

I know this is not a Virtualmin problem (the SIGSEGV) but I'm curious why the instances of Virtualmin see php as being up to date with different versions on the systems (like a year's difference).

The definition of "up to date" in Virtualmin is having a version installed that is the latest provided by any of your configured YUM repositories. So if on the production system you have the Rackspace repository setup and in provides PHP 5.2.11, then that system would be up to date if 5.2.11 was installed.

However, if the test system only uses the CentOS and Virtualmin repositories which I think provide only version 5.2.6, if you have that version installed the system will also be considered up to date..

Okay, got that. I did a yum list php and it shows it coming from the Rackspace repository. I have opened a ticket with them.

Guess Virtualmin just sits on top of the yum repositories and reports against what they tell it.

Appreciate the explaination.

tony