Re: Mythweb (php 5.2.10) doesn't work b/c of suhosin - canaries
On Sat, Jan 9, 2010 at 7:21 PM, Greg Rundlett (freephile) wrote: > You can't uninstall suhosin because it's compiled into the > php5-common package. I guess I could either build from source [8], or > try to upgrade This is what I'd do. Download the source for the php5-common package. Recompile the package manually, but change the configure scripts to suit your needs first. There's a lot of how-to pages out there, but the general idea is covered pretty well here: http://www.debian.org/doc/FAQ/ch-pkg_basics.en.html#s-sourcebuild -N ___ gnhlug-discuss mailing list gnhlug-discuss@mail.gnhlug.org http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss/
Fwd: Mythweb (php 5.2.10) doesn't work b/c of suhosin - canaries
any help from all the mythtv users out there :-) -- Forwarded message -- From: Greg Rundlett (freephile) Date: Sat, Jan 9, 2010 at 6:14 PM Subject: Mythweb (php 5.2.10) doesn't work b/c of suhosin - canaries To: Boston PHP Talk , NYPHP Talk Anyone else have a problem with mythweb, suhosin or php5.2.10? I've recently upgraded my mythbuntu setup to 9.10 (karmic koala) and mythweb doesn't work b/c of a suhosin error. I get a big white screen. The error found in apache's log is ALERT - canary mismatch on efree() - heap overflow detected (attacker '::1', file '/usr/share/mythtv/mythweb/includes/errors.php', line 211 (generated by suhosin [1][2] ) line 211 is an innocuous $constant_list = get_defined_constants(true); Supposedly this is fixed upstream, or in newer versions of either apache or php5 [3] , but I don't see a lot of information about it. There was a somewhat related bug [4][5] with a workaround where you could turn off session encryption in the suhosin.ini but that doesn't work in my case (there's not even a suhosin.ini config file b/c suhosin is built in to php-common -- and if you create the config + setting and/or install the compiled add-on (php5-suhosin), the problem still manifests). Some other bugs involve segfaults in debian for php5.2.10 [6]. Still other problems have been reported that might be due to a conflict between suhosin and xdebug, but I've made sure that neither package is installed [7]. You can't uninstall suhosin because it's compiled into the php5-common package. I guess I could either build from source [8], or try to upgrade Lucid has PHP 5.2.11 [9] so I guess I can use pinning [10] to upgrade to that version, but I haven't done that yet. I did try installing xdebug, valgrind and kcachegrind to look for more details, but it doesn't reveal anything. == Details of my system == uname -a Linux hybrid 2.6.31-16-generic #53-Ubuntu SMP Tue Dec 8 04:01:29 UTC 2009 i686 GNU/Linux g...@hybrid:/var/www$ apache2 -v Server version: Apache/2.2.12 (Ubuntu) Server built: Nov 12 2009 22:49:46 g...@hybrid:/var/www$ sudo apt-cache policy apache2 apache2: Installed: (none) Candidate: 2.2.12-1ubuntu2.1 Version table: 2.2.12-1ubuntu2.1 0 500 http://us.archive.ubuntu.com karmic-updates/main Packages 500 http://security.ubuntu.com karmic-security/main Packages 2.2.12-1ubuntu2 0 500 http://us.archive.ubuntu.com karmic/main Packages g...@hybrid:/var/www$ apache2ctl -M apache2: Could not reliably determine the server's fully qualified domain name, using 127.0.1.1 for ServerName Loaded Modules: core_module (static) log_config_module (static) logio_module (static) mpm_prefork_module (static) http_module (static) so_module (static) alias_module (shared) auth_basic_module (shared) auth_digest_module (shared) authn_file_module (shared) authz_default_module (shared) authz_groupfile_module (shared) authz_host_module (shared) authz_user_module (shared) autoindex_module (shared) cgi_module (shared) deflate_module (shared) dir_module (shared) env_module (shared) mime_module (shared) negotiation_module (shared) php5_module (shared) rewrite_module (shared) setenvif_module (shared) status_module (shared) Syntax OK g...@hybrid:/var/www$ sudo apt-cache policy php5 php5: Installed: 5.2.10.dfsg.1-2ubuntu6.3 Candidate: 5.2.10.dfsg.1-2ubuntu6.3 Version table: *** 5.2.10.dfsg.1-2ubuntu6.3 0 500 http://us.archive.ubuntu.com karmic-updates/main Packages 500 http://security.ubuntu.com karmic-security/main Packages 100 /var/lib/dpkg/status 5.2.10.dfsg.1-2ubuntu6 0 500 http://us.archive.ubuntu.com karmic/main Packages g...@hybrid:/var/www$ php -v PHP 5.2.10-2ubuntu6.3 with Suhosin-Patch 0.9.7 (cli) (built: Nov 26 2009 14:42:49) Copyright (c) 1997-2009 The PHP Group Zend Engine v2.2.0, Copyright (c) 1998-2009 Zend Technologies php -m [PHP Modules] bcmath bz2 calendar ctype curl date dba dom exif filter ftp gd gettext hash iconv imap json libxml mbstring mcrypt mime_magic mysql mysqli ncurses openssl pcntl pcre PDO pdo_mysql pdo_pgsql pdo_sqlite pgsql posix readline Reflection session shmop SimpleXML soap sockets SPL SQLite standard sysvmsg sysvsem sysvshm tokenizer wddx xml xmlreader xmlwriter zip zlib [Zend Modules] [1] http://ubuntuforums.org/showthread.php?t=1208437 [2] Stefan Esser's blog http://www.suspekt.org/2008/10/12/suhosin-canary-mismatch-on-efree-heap-overflow-detected/ [3] http://www.mail-archive.com/debian-bugs...@lists.debian.org/msg197763.html [4] https://bugs.launchpad.net/ubuntu/+source/php5/+bug/424789 [5] http://www.uluga.ubuntuforums.org/showthread.php?p=7896618 [6] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=542514 [7] sudo apt-get remove php5-suhosin sudo apt-get remove php5-xdebug [8] http://chrisblunt.com/blog/2009/05/01/php-fixing-mismatched-canaries-how-to-remove-suhosin-from-debianubuntu-packages/ [9] http://packages.ubuntu.com/lucid/php5-common [10] http://
Re: UDEV hangs on boot
ah. I saw this bug that mentions a problem on super micro boards and ecc ram that may be of interest: https://bugzilla.redhat.com/show_bug.cgi?id=444900 comment 2 is interesting: I blacklisted edac_mc and i5000_edac by using rescue mode and was able to get the system to boot. While this is now fixed, other folks are probably going to run into the problem. good luck. Jerry Feldman wrote: > Good idea. > It is x86_64 with 2 Intel Woodcrest dual core CPUs. BTW: The BIOS sees > all 64GB memory and reports it as good. (I had it set to specifically > check the memory at one point just to make sure). > In your case, you have an i686 that does not support more than 3GB > unless PAE is set. I'm looking for any clues, possibly irrelevant. If > you do a google search for udev hangs at boot, you will get over 100,000 > hits. > > On 01/09/2010 09:29 AM, Frank DiPrete wrote: >> >> Is this an x86_64 or an i686? >> Check your kernel config in /boot >> >> My centOS 5.4 i686 machine running kernel 2.6.18-164.9.1.el5 has the >> following: >> >> CONFIG_HIGHMEM4G=y >> # CONFIG_HIGHMEM64G is not set >> >> >> >> >> Jerry Feldman wrote: >>> I'm trying to get one of our servers to boot with 64GB. The kernel >>> boots, but "starting UDEV" hangs. >>> This is an Intel whitebox with a Supermicro X7DB8+ MB currently flashed >>> at BIOS 2.1a. The memories are 16 4GB DIMMS (Kingston) that have been >>> certified by Supermicro. This occurs on both RHEL 5.2 and RHEL 5.3. I've >>> got 3 other nearly identical servers running successfully. I've changed >>> the PCI hole from 256MB to 1GB to 2GB.. This is a pulldown in the BIOS >>> and I only have these choices (actually 512 also). >>> >>> I've been doing more checking. Note that in RHEL you can turn on udev >>> debugging as a kernel argument (udevdebug). >>> I've determined that the culprit is udevsettle that resides in >>> /sbin/start_udev. This is a hard hang, and setting a timeout value does >>> nothing (eg. udevtimeout=180). With udevdebug set I have a number of >>> messages showing that some of the udev tasks have completed, but I have >>> not been able to track them to a device. The only way to access the >>> script is to boot into the rescue. I've also determined that removing >>> the additional 2 SATA drives makes no difference. I've disabled both the >>> serial, parallel and floppy ports in the BIOS. I've also set the noapic >>> and acpi=off kernel flags. Additionally, I've modified the >>> /sbin/start_udev script replacing udevsettle with /bin/sleep, which also >>> hangs. >>> Setting the udevdebug flag causes a lot of messages to scroll by on the >>> screen, but I don't see anything that would be a red flag. Additionally, >>> I've set modprobedebug. This shows that there are several modules that >>> have FATAL failures because of no file found. >>> If I comment out /sbin/start_udev in rc.sysinit, I do get a somewhat >>> working system, with no graphics (which is ok). >>> >>> Some history, is that we were fiddling around and placed 1 1GB DIMM in >>> each bank and we were able to boot. >>> Additionally, we boot into the rescue with no problems. >>> >>> One thing I am going to try on Monday is possibly trying to run a live >>> CD (possibly Fedora), but in the long run I need to run either RHEL 5.2 >>> (preferred) or RHEL 5.3. >>> >>> Just one more tidbit. I had another system that was using 16 1GB DIMMS, >>> when I upgraded that, it had the same problem, but after I rebooted it, >>> I was unable to get it back up, and when I did it would not recognize >>> the 4GB DIMMS, but since I had another dead system (power supply and >>> power switch), we moved the memories to that system. >>> >>> Additionally, I di occasionally receive a checksum error on the BIOS >>> (both machines), but not on every boot. >>> >>> > > > > > > ___ > gnhlug-discuss mailing list > gnhlug-discuss@mail.gnhlug.org > http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss/ ___ gnhlug-discuss mailing list gnhlug-discuss@mail.gnhlug.org http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss/
Re: UDEV hangs on boot
Good idea. It is x86_64 with 2 Intel Woodcrest dual core CPUs. BTW: The BIOS sees all 64GB memory and reports it as good. (I had it set to specifically check the memory at one point just to make sure). In your case, you have an i686 that does not support more than 3GB unless PAE is set. I'm looking for any clues, possibly irrelevant. If you do a google search for udev hangs at boot, you will get over 100,000 hits. On 01/09/2010 09:29 AM, Frank DiPrete wrote: > > > Is this an x86_64 or an i686? > Check your kernel config in /boot > > My centOS 5.4 i686 machine running kernel 2.6.18-164.9.1.el5 has the > following: > > CONFIG_HIGHMEM4G=y > # CONFIG_HIGHMEM64G is not set > > > > > Jerry Feldman wrote: >> I'm trying to get one of our servers to boot with 64GB. The kernel >> boots, but "starting UDEV" hangs. >> This is an Intel whitebox with a Supermicro X7DB8+ MB currently flashed >> at BIOS 2.1a. The memories are 16 4GB DIMMS (Kingston) that have been >> certified by Supermicro. This occurs on both RHEL 5.2 and RHEL 5.3. I've >> got 3 other nearly identical servers running successfully. I've changed >> the PCI hole from 256MB to 1GB to 2GB.. This is a pulldown in the BIOS >> and I only have these choices (actually 512 also). >> >> I've been doing more checking. Note that in RHEL you can turn on udev >> debugging as a kernel argument (udevdebug). >> I've determined that the culprit is udevsettle that resides in >> /sbin/start_udev. This is a hard hang, and setting a timeout value does >> nothing (eg. udevtimeout=180). With udevdebug set I have a number of >> messages showing that some of the udev tasks have completed, but I have >> not been able to track them to a device. The only way to access the >> script is to boot into the rescue. I've also determined that removing >> the additional 2 SATA drives makes no difference. I've disabled both the >> serial, parallel and floppy ports in the BIOS. I've also set the noapic >> and acpi=off kernel flags. Additionally, I've modified the >> /sbin/start_udev script replacing udevsettle with /bin/sleep, which also >> hangs. >> Setting the udevdebug flag causes a lot of messages to scroll by on the >> screen, but I don't see anything that would be a red flag. Additionally, >> I've set modprobedebug. This shows that there are several modules that >> have FATAL failures because of no file found. >> If I comment out /sbin/start_udev in rc.sysinit, I do get a somewhat >> working system, with no graphics (which is ok). >> >> Some history, is that we were fiddling around and placed 1 1GB DIMM in >> each bank and we were able to boot. >> Additionally, we boot into the rescue with no problems. >> >> One thing I am going to try on Monday is possibly trying to run a live >> CD (possibly Fedora), but in the long run I need to run either RHEL 5.2 >> (preferred) or RHEL 5.3. >> >> Just one more tidbit. I had another system that was using 16 1GB DIMMS, >> when I upgraded that, it had the same problem, but after I rebooted it, >> I was unable to get it back up, and when I did it would not recognize >> the 4GB DIMMS, but since I had another dead system (power supply and >> power switch), we moved the memories to that system. >> >> Additionally, I di occasionally receive a checksum error on the BIOS >> (both machines), but not on every boot. >> >> -- Jerry Feldman Boston Linux and Unix PGP key id: 537C5846 PGP Key fingerprint: 3D1B 8377 A3C0 A5F2 ECBB CA3B 4607 4319 537C 5846 signature.asc Description: OpenPGP digital signature ___ gnhlug-discuss mailing list gnhlug-discuss@mail.gnhlug.org http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss/
Re: UDEV hangs on boot
Is this an x86_64 or an i686? Check your kernel config in /boot My centOS 5.4 i686 machine running kernel 2.6.18-164.9.1.el5 has the following: CONFIG_HIGHMEM4G=y # CONFIG_HIGHMEM64G is not set Jerry Feldman wrote: > I'm trying to get one of our servers to boot with 64GB. The kernel > boots, but "starting UDEV" hangs. > This is an Intel whitebox with a Supermicro X7DB8+ MB currently flashed > at BIOS 2.1a. The memories are 16 4GB DIMMS (Kingston) that have been > certified by Supermicro. This occurs on both RHEL 5.2 and RHEL 5.3. I've > got 3 other nearly identical servers running successfully. I've changed > the PCI hole from 256MB to 1GB to 2GB.. This is a pulldown in the BIOS > and I only have these choices (actually 512 also). > > I've been doing more checking. Note that in RHEL you can turn on udev > debugging as a kernel argument (udevdebug). > I've determined that the culprit is udevsettle that resides in > /sbin/start_udev. This is a hard hang, and setting a timeout value does > nothing (eg. udevtimeout=180). With udevdebug set I have a number of > messages showing that some of the udev tasks have completed, but I have > not been able to track them to a device. The only way to access the > script is to boot into the rescue. I've also determined that removing > the additional 2 SATA drives makes no difference. I've disabled both the > serial, parallel and floppy ports in the BIOS. I've also set the noapic > and acpi=off kernel flags. Additionally, I've modified the > /sbin/start_udev script replacing udevsettle with /bin/sleep, which also > hangs. > Setting the udevdebug flag causes a lot of messages to scroll by on the > screen, but I don't see anything that would be a red flag. Additionally, > I've set modprobedebug. This shows that there are several modules that > have FATAL failures because of no file found. > If I comment out /sbin/start_udev in rc.sysinit, I do get a somewhat > working system, with no graphics (which is ok). > > Some history, is that we were fiddling around and placed 1 1GB DIMM in > each bank and we were able to boot. > Additionally, we boot into the rescue with no problems. > > One thing I am going to try on Monday is possibly trying to run a live > CD (possibly Fedora), but in the long run I need to run either RHEL 5.2 > (preferred) or RHEL 5.3. > > Just one more tidbit. I had another system that was using 16 1GB DIMMS, > when I upgraded that, it had the same problem, but after I rebooted it, > I was unable to get it back up, and when I did it would not recognize > the 4GB DIMMS, but since I had another dead system (power supply and > power switch), we moved the memories to that system. > > Additionally, I di occasionally receive a checksum error on the BIOS > (both machines), but not on every boot. > > > > > > ___ > gnhlug-discuss mailing list > gnhlug-discuss@mail.gnhlug.org > http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss/ ___ gnhlug-discuss mailing list gnhlug-discuss@mail.gnhlug.org http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss/
UDEV hangs on boot
I'm trying to get one of our servers to boot with 64GB. The kernel boots, but "starting UDEV" hangs. This is an Intel whitebox with a Supermicro X7DB8+ MB currently flashed at BIOS 2.1a. The memories are 16 4GB DIMMS (Kingston) that have been certified by Supermicro. This occurs on both RHEL 5.2 and RHEL 5.3. I've got 3 other nearly identical servers running successfully. I've changed the PCI hole from 256MB to 1GB to 2GB.. This is a pulldown in the BIOS and I only have these choices (actually 512 also). I've been doing more checking. Note that in RHEL you can turn on udev debugging as a kernel argument (udevdebug). I've determined that the culprit is udevsettle that resides in /sbin/start_udev. This is a hard hang, and setting a timeout value does nothing (eg. udevtimeout=180). With udevdebug set I have a number of messages showing that some of the udev tasks have completed, but I have not been able to track them to a device. The only way to access the script is to boot into the rescue. I've also determined that removing the additional 2 SATA drives makes no difference. I've disabled both the serial, parallel and floppy ports in the BIOS. I've also set the noapic and acpi=off kernel flags. Additionally, I've modified the /sbin/start_udev script replacing udevsettle with /bin/sleep, which also hangs. Setting the udevdebug flag causes a lot of messages to scroll by on the screen, but I don't see anything that would be a red flag. Additionally, I've set modprobedebug. This shows that there are several modules that have FATAL failures because of no file found. If I comment out /sbin/start_udev in rc.sysinit, I do get a somewhat working system, with no graphics (which is ok). Some history, is that we were fiddling around and placed 1 1GB DIMM in each bank and we were able to boot. Additionally, we boot into the rescue with no problems. One thing I am going to try on Monday is possibly trying to run a live CD (possibly Fedora), but in the long run I need to run either RHEL 5.2 (preferred) or RHEL 5.3. Just one more tidbit. I had another system that was using 16 1GB DIMMS, when I upgraded that, it had the same problem, but after I rebooted it, I was unable to get it back up, and when I did it would not recognize the 4GB DIMMS, but since I had another dead system (power supply and power switch), we moved the memories to that system. Additionally, I di occasionally receive a checksum error on the BIOS (both machines), but not on every boot. -- Jerry Feldman Boston Linux and Unix PGP key id: 537C5846 PGP Key fingerprint: 3D1B 8377 A3C0 A5F2 ECBB CA3B 4607 4319 537C 5846 signature.asc Description: OpenPGP digital signature ___ gnhlug-discuss mailing list gnhlug-discuss@mail.gnhlug.org http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss/
