This service will be undergoing maintenance at 00:00 UTC, 2016-08-01. It is expected to last about 1 hours
Bug 806472 - php not closing database connections to db2 express C when finished.
php not closing database connections to db2 express C when finished.
Status: CLOSED CURRENTRELEASE
Product: Red Hat Enterprise Linux 5
Classification: Red Hat
Component: php (Show other bugs)
5.8
x86_64 Linux
unspecified Severity medium
: rc
: ---
Assigned To: Web Stack Team
BaseOS QE - Apps
: Regression
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2012-03-23 17:20 EDT by Harold Pritchett
Modified: 2013-12-03 04:42 EST (History)
6 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2013-12-03 04:42:45 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)
Instructions for temporary fix to get the database back online (437 bytes, text/plain)
2012-03-23 17:20 EDT, Harold Pritchett
no flags Details


External Trackers
Tracker ID Priority Status Summary Last Updated
PHP Bug Tracker 63171 None None None 2012-09-27 08:00:54 EDT

  None (edit)
Description Harold Pritchett 2012-03-23 17:20:11 EDT
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
Comment 1 Remi Collet 2012-09-27 03:43:40 EDT
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.
Comment 2 Remi Collet 2012-09-27 08:00:52 EDT
Upstream bug open, with a better patch proposal for #594813 which fixes this regression.
See https://github.com/php/php-src/pull/207
Comment 3 Joe Orton 2012-10-10 10:14:44 EDT
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
Comment 5 Harold Pritchett 2012-10-16 17:15:16 EDT
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.
Comment 8 Remi Collet 2013-07-22 09:32:19 EDT
Postponed for 5.11
Comment 9 Joe Orton 2013-12-03 04:42:45 EST
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.

Note You need to log in before you can comment on or make changes to this bug.