Created attachment 572381 [details] Instructions for temporary fix to get the database back online Description of problem: When connecting to db2 using PHP through UNIXODBC, it was not closing the db2 database application/agent once it completed even if the PHP script completed successfully. This behavior occurred even if there was an explicit odbc_close() function included in the script. The connections did not remain active in Apache, only on the db2 database. This behavior resulted in db2 allocating and keeping an application/agent in memory for every SQL call made from PHP, thus reaching the db2 maximum available application configuration and resulting in the database returning no connections are available. I adjusted the db2 maximum number of applications, but that simply delayed the no connections available message a little longer since none were ever being released. After hitting the maximum number of applications in db2 and manually forcing them out of the database multiple times, db2 would ultimately use the limit for configured shared memory and no semaphores would be available which requires a system restart. Even increasing the number of semaphores defined to the kernel would simply delay the error. Version-Release number of selected component (if applicable): DB2 Express: v9.7.0.1, s091114, IP23034, Fix Pack 1 kernel-2.6.18-308.1.1.el5.x86_64 php-5.1.6-32.el5.x86_64 php-odbc-5.1.6-32.el5_5.3.x86_64 php-common-5.1.6-32.el5_5.3.x86_64 php-cli-5.1.6-32.el5_5.3.x86_64 php-pdo-5.1.6-32.el5_5.3.x86_64 php-ldap-5.1.6-32.el5_5.3.x86_64 How reproducible: With php at levels below, it fails every time: php-5.1.6-32.el5.x86_64 php-odbc-5.1.6-32.el5_5.3.x86_64 php-common-5.1.6-32.el5_5.3.x86_64 php-cli-5.1.6-32.el5_5.3.x86_64 php-pdo-5.1.6-32.el5_5.3.x86_64 php-ldap-5.1.6-32.el5_5.3.x86_64 Steps to Reproduce: 1. Update php to version 5.1.6-32 Actual results: db2 fails to close database connections and finally runs out of available connections. Expected results: db2 should close connections. It worked until php was upgraded to 5.1.6-32. Additional info: Temporary fix: Downgrade php and the associated php-odbc module to following levels: php-5.1.6-27.el5_5.3.x86_64 php-odbc-5.1.6-27.el5_5.3.x86_64 php-common-5.1.6-27.el5_5.3.x86_64 php-cli-5.1.6-27.el5_5.3.x86_64 php-pdo-5.1.6-27.el5_5.3.x86_64 php-ldap-5.1.6-27.el5_5.3.x86_64
I can reproduce this issue (only in apache) with another databse (mysql-connector-odbc) It seems tobe a regression introduce in 5.1.6-29 by php-5.1.6-odbctimer.patch A call of "exit" (and perhaps other) raise a "unclean_shutdown", during which connection are not properly closed. Will investigate to improve this patch.
Upstream bug open, with a better patch proposal for #594813 which fixes this regression. See https://github.com/php/php-src/pull/207
Harold, we've identified a fix for this problem; thanks for filing the bug. If this issue is critical or in any way time sensitive, please raise a ticket through your regular Red Hat support channels to make certain it receives the proper attention and prioritization to assure a timely resolution. For information on how to contact the Red Hat production support team, please visit: https://www.redhat.com/support/process/production/#howto
At this time, this is not a critical or time sensitive problem. I have obtained a working system by downgrading php to the last working version. At some point, I feel I should upgrade PHP to current maintenance levels. At this time, this fix should be incorporated into the maintenance stream and be a part of the product. Do you have any idea when this might happen? Thanks for finding this.
Postponed for 5.11
This bug has been reviewed by Red Hat, and there are no plans to address it in Red Hat Enterprise Linux 5. If this bug is critical to production systems, please contact your Red Hat support representative and provide sufficient business justification. The issue is not present in RHEL-6.