Red Hat Bugzilla – Bug 457436
InterfaceError: (0, '') in cursors.py db.character_set_name() after 4.7 upgrade
Last modified: 2013-07-02 23:19:08 EDT
Description of problem: Since we upgraded our server to RHEL 4.7 (from RHEL 4.6) our Zope server (Zope-2.7.6-final.tgz) started throwing InterfaceError: (0, '') after about 40 minutes of use accessing the mysql database. Restarting the Zope fixes the problem for another about 40 minutes. The bug was reported on both ZMySQLDA (ZMySQLDA-2.0.8.tar.gz) and direct use of MySQLdb (through zope though), which led us to MySQL-python. After investigating (and the bug report here was usefull although it speaks of an upgrade 5.0.22 => 5.0.24): http://bugs.mysql.com/bug.php?id=21543 we decided to recompile the MySQL-python from MySQL-python-1.2.1_p2-1.el4.1.src.rpm on our RHEL 4.7 server and install the RHEL 4.7 compiled version. This fixed the problem for us (at least so far). Version-Release number of selected component (if applicable): MySQL-python-1.2.1_p2-1.el4.1 How reproducible: We do not have a 100% reliable way of reproducing the bug. On our server, it appears more or less after 40 to 60 minutes of regular use (a few "ab" every now and then) on the zForum component (zForum-1.08.tar.gz). Steps to Reproduce: [Untested by us] 1. Install Zope-2.7.6-final.tgz, ZMySQLDA-2.0.8.tar.gz, Plone-2.1.3.tar.gz and zForum-1.08.tar.gz 2. Setup zForum in Plone to use a mysql DB 3. run queries on the forum (like http://www.gymglish.com/www/forum ) for about 1 hour 4. Get python trace with the error in event.log Here is one python trace for this error: 2008-07-29T13:20:28 ERROR(200) SiteError http://www.gymglish.com/english-courses-english-test/contact_view Traceback (most recent call last): File "/home/gymglish/myzope/binary/lib/python/ZPublisher/Publish.py", line 101, in publish request, bind=1) File "/home/gymglish/myzope/binary/lib/python/ZPublisher/mapply.py", line 88, in mapply if debug is not None: return debug(object,args,context) File "/home/gymglish/myzope/binary/lib/python/ZPublisher/Publish.py", line 39, in call_object result=apply(object,args) # Type s<cr> to step into published object. [...] File "/home/gymglish/myzope/binary/lib/python/Products/PageTemplates/TALES.py", line 221, in evaluate return expression(self) File "/home/gymglish/myzope/binary/lib/python/Products/PageTemplates/Expressions.py", line 172, in __call__ return self._eval(econtext) File "/home/gymglish/myzope/binary/lib/python/Products/PageTemplates/Expressions.py", line 167, in _eval return render(ob, econtext.vars) File "/home/gymglish/myzope/binary/lib/python/Products/PageTemplates/Expressions.py", line 74, in render ob = ob() File "/home/gymglish/myzope/var/instance1000-145905-www1/Products/GymglishArticle/GymglishContactFolder.py", line 222, in showForm1 myDict = self.REQUEST.SESSION.get(self.id, {}) File "/home/gymglish/myzope/var/instance1000-145906-www2/Products/ggSQLSessionDataManager/ggSQLSessionDataManager.py", line 390, in get if self.has_key(key): File "/home/gymglish/myzope/var/instance1000-145906-www2/Products/ggSQLSessionDataManager/ggSQLSessionDataManager.py", line 399, in has_key resu = a9db.DBQuery(sql, connectionpool=self._connectionpool) File "/home/gymglish/a9engine-ro/expert/a9db.py", line 571, in DBQuery rows = TryBasicDBQuery(sql, ggconnection=ggconnection, approximate_query_ok = approximate_query_ok) File "/home/gymglish/a9engine-ro/expert/a9db.py", line 545, in TryBasicDBQuery rows = BasicDBQuery(sql, ggconnection=ggconnection, approximate_query_ok = approximate_query_ok) File "/home/gymglish/a9engine-ro/expert/a9db.py", line 502, in BasicDBQuery cursor.execute(sql) File "/usr/lib/python2.3/site-packages/MySQLdb/cursors.py", line 145, in execute charset = db.character_set_name() InterfaceError: (0, '') Additional info: Could there be an ABI issue with RHEL 4.6 -> 4.7 upgrade in the MySQL-python package ? Or are we most likely not looking at the right location ?
MySQL-python hasn't changed since 4.5. But mysql did change in 4.7, so maybe there's an ABI issue on that side. Please confirm what mysql release you are using, and if possible what you had before the upgrade.
Hello Tom, Current versions of mysql packages on the RHEL 4.7 computers showing the issue: mysql-4.1.22-2.el4 mysql-devel-4.1.22-2.el4 mysql-server-4.1.22-2.el4 mysqlclient10-3.23.58-4.RHEL4.1 MySQL-python-1.2.1_p2-1.el4.1 Versions of mysql packages before the upgrade: mysql-4.1.20-3.RHEL4.1.el4_6.1 mysql-devel-4.1.20-3.RHEL4.1.el4_6.1 mysql-server-4.1.20-3.RHEL4.1.el4_6.1 mysqlclient10-3.23.58-4.RHEL4.1 MySQL-python-1.2.1_p2-1.el4.1 The computers showing the issue do NOT run the mysql server. Our mysql server is running RHEL 4.7 also (mysql-server-4.1.22-2.el4), but we ruled out a mysqld server issue since our (Centos) 4.6 computers were not affected when connecting to the RHEL 4.7 database server whereas our (production) RHEL 4.7 computers all were affected. Our (currently unaffected) Centos 4.6 computers have the following mysql packages: mysql-4.1.20-3.RHEL4.1.el4_6.1 mysql-devel-4.1.20-3.RHEL4.1.el4_6.1 mysql-server-4.1.20-3.RHEL4.1.el4_6.1 mysqlclient10-3.23.58-4.RHEL4.1 MySQL-python-1.2.1_p2-1.el4.1 Best regards,
Yeah, if it is an ABI-type problem it wouldn't be on the server side. What I suspect is either /usr/lib/mysql/libmysqlclient.so.14.0.0 /usr/lib/mysql/libmysqlclient_r.so.14.0.0 whichever of those MySQL-python's _mysql.so links to (please apply ldd to _mysql.so to check --- I suspect the latter but haven't got the RHEL4 bits at hand to confirm it). Are you in a position to roll back just that one file to the 4.1.20 version and see if the problem goes away?
Hello Tom, /usr/lib/python2.3/site-packages/_mysql.so links to /usr/lib/mysql/libmysqlclient_r.so.14 as shown here: [admin@145906-www2 ~]$ ldd /usr/lib/python2.3/site-packages/_mysql.so libmysqlclient_r.so.14 => /usr/lib/mysql/libmysqlclient_r.so.14 (0x005c9000) libz.so.1 => /usr/lib/libz.so.1 (0x00a7b000) libpthread.so.0 => /lib/tls/libpthread.so.0 (0x00bbf000) libcrypt.so.1 => /lib/libcrypt.so.1 (0x001e1000) libnsl.so.1 => /lib/libnsl.so.1 (0x00ee9000) libm.so.6 => /lib/tls/libm.so.6 (0x00111000) libssl.so.4 => /lib/libssl.so.4 (0x00346000) libcrypto.so.4 => /lib/libcrypto.so.4 (0x0037a000) libc.so.6 => /lib/tls/libc.so.6 (0x00464000) /lib/ld-linux.so.2 (0x002f5000) libgssapi_krb5.so.2 => /usr/lib/libgssapi_krb5.so.2 (0x002bc000) libkrb5.so.3 => /usr/lib/libkrb5.so.3 (0x00134000) libcom_err.so.2 => /lib/libcom_err.so.2 (0x001b8000) libk5crypto.so.3 => /usr/lib/libk5crypto.so.3 (0x001bb000) libresolv.so.2 => /lib/libresolv.so.2 (0x00199000) libdl.so.2 => /lib/libdl.so.2 (0x002a7000) This is the case for both unchanged RHEL 4.7 and for RHEL 4.7 servers with our newly compiled MySQL-python rpm. I am in a position to roll back only the /usr/lib/mysql/libmysqlclient_r.so.14 file to use the mysql-4.1.20-3.RHEL4.1.el4_6.1 rpm on one affected server. I will do so and tell you if I can reproduce the bug in this setup. Best regards, Antoine
Hello Tom, We have rolled back just the /usr/lib/mysql/libmysqlclient_r.so.14.0.0 file to the 4.1.20 version on an otherwise unchanged 4.7 RHEL server that produced the error: [root@145908-www3 mysql]# rpm -qi mysql|grep -E "Name|Version|Release" Name : mysql Relocations: (not relocatable) Version : 4.1.22 Vendor: Red Hat, Inc. Release : 2.el4 Build Date: Tue 06 May 2008 06:22:25 PM CEST [root@145908-www3 mysql]# rpm -qi MySQL-python|grep -E "Name|Version|Release" Name : MySQL-python Relocations: (not relocatable) Version : 1.2.1_p2 Vendor: Red Hat, Inc. Release : 1.el4.1 Build Date: Thu 11 Jan 2007 02:27:40 AM CET [root@145908-www3 mysql]# ll /usr/lib/mysql/libmysqlclient_r.so.14* lrwxrwxrwx 1 root root 26 Jul 26 03:15 /usr/lib/mysql/libmysqlclient_r.so.14 -> libmysqlclient_r.so.14.0.0 lrwxrwxrwx 1 root root 57 Aug 1 12:17 /usr/lib/mysql/libmysqlclient_r.so.14.0.0 -> libmysqlclient_r.so.14.0.0-mysql-4.1.20-3.RHEL4.1.el4_6.1 -rwxr-xr-x 1 root root 1261164 Aug 1 12:17 /usr/lib/mysql/libmysqlclient_r.so.14.0.0-mysql-4.1.20-3.RHEL4.1.el4_6.1 -rwxr-xr-x 1 root root 1264716 May 6 18:22 /usr/lib/mysql/libmysqlclient_r.so.14.0.0-mysql-4.1.22-2.el4 After this change, we did not notice any InterfaceError any more. Best regards, Antoine
Hello, I can also confirm that reverting the change with: libmysqlclient_r.so.14.0.0 -> libmysqlclient_r.so.14.0.0-mysql-4.1.22-2.el4 makes the problem appear again. So, it is libmysqlclient_r.so.14.0.0 of mysql-4.1.22-2.el4 that creates the regression for our application. Best regards, Antoine
Thank you for submitting this issue for consideration in Red Hat Enterprise Linux. The release for which you requested us to review is now End of Life. Please See https://access.redhat.com/support/policy/updates/errata/ If you would like Red Hat to re-consider your feature request for an active release, please re-open the request via appropriate support channels and provide additional supporting details about the importance of this issue.