This thread tells about strange core.* file which I could'nt assign. http://www.howtoforge.com/forums/showthread.php?t=37120 The core.* files are only shown in /root/ not in / Code: h1:/# ls -l /root/ insgesamt 18280 -rw------- 1 root root 12996608 30. Jun 20:53 core.22195 -rw------- 1 root root 12992512 30. Jun 23:18 core.22229 -rw------- 1 root root 12992512 30. Jun 21:34 core.23715 -rw------- 1 root root 12992512 30. Jun 22:52 core.24286 -rw------- 1 root root 12992512 30. Jun 21:07 core.3662 -rw------- 1 root root 13832192 30. Jun 20:39 core.7970 -rw------- 1 root root 13832192 30. Jun 22:31 core.9760 I started to search for the reason for these core.* files with gdb and it tells that all core.* files comes from ispconfig: Every day when I log in as root I see new core.* files. The coredump say that every core.file belong to ispconfig as shown above. According to gdb info I found in /var/log/ispconfig/cron.log (unfortunately there is no time) ISPConfig3 is running on Debian Lenny as a virtuozzo vm. At the moment I can't find more infos in the logs. Where can the LOGLEVEL_DEBUG in /usr/local/ispconfig/server/server.php be changed? Do you have any Idea how to solve this faulty ISPConfig sever running?
Segementation faults are mostly caused by hardware problems. You shoud check the hardware of the host server with memcheck. Also make sure that the memory limits of your vm are not too low. The segfualts have nothing to do with ispconfig itself as ispconfig is written in php and you can not cause a segfault with php code. Segfualts can only be caused by bugs in the php version itself or the surroundung os enviroment like hardwrae problems. In the ISPConfig configuration file: /usr/local/ispconfig/server/lib/config.inc.php
Does somebody has the same things installed: ISPConfig3.0.1.3 on Debian Lenny and everythink work right with the installed php version? Code: h1:~# php -v PHP 5.2.6-1+lenny3 with Suhosin-Patch 0.9.6.2 (cli) (built: Apr 26 2009 22:16:23) Copyright (c) 1997-2008 The PHP Group Zend Engine v2.2.0, Copyright (c) 1998-2008 Zend Technologies If it's not php what produces the segmentation fault it musst be faulty hardware or could there be more reasons for the core.* files?
How can I use all and more of the installed memory to produce failcounts? I want to see changing of /proc/user_beancounters and produce core.* files. My provider still claims that the vm produces core.* files because it reaches the limit. But the vm is not productiv no trafic. Only ispconfig is fresh installed again. One test account monitored with munit. I think noch it's on my to show that memory is faulty. I cant check it with memcheck or test reiserfs filesystem because it's a virtuozzo vm. Are there other things to test which points to brocken men?
I've found the reason for the segmentation faults an the core.* files. It's a bug in the following debian lenny php package. Ist not a hardware fault. hours of testing led me to that point. The same core.* files were seen in other hardware. If tried other server environments. The fauls did'nt arrise with debian etch package. This php ist faulty: Code: PHP 5.2.6-1+lenny3 with Suhosin-Patch 0.9.6.2 (cli) (built: Apr 26 2009 22:16:23) Segmentation fauls could not be recogniced with the package. Code: PHP 5.2.9-0.dotdeb.2 with Suhosin-Patch 0.9.7 (cli) (built: Apr 7 2009 20:42:41)
