Closed Bug 559109 Opened 12 years ago Closed 12 years ago

Fatal error: memcache is not installed or not configured correctly

Categories

(mozilla.org Graveyard :: Server Operations, task)

task
Not set
critical

Tracking

(Not tracked)

VERIFIED FIXED

People

(Reporter: stephend, Assigned: oremj)

References

()

Details

(Keywords: regression)

STR:

1. As an approver/admin, load https://support-stage-new.mozilla.com/tiki-editpage.php?locale=en-US&page=%252AUpgrading%2520to%2520Firefox%25203.6 while logged in
2. Add a tag, save it
3. Approve the changes

Fatal error: Call to undefined function mb_ereg_replace() in /data/www/support-stage-new.mozilla.com/webroot/tiki-approve_staging_page.php  on line 107
(I don't actually know if this is important; we might be only redirecting search, and not this part of SUMO, for 1.5.4/2.0 -- just filed for completeness.)
Assignee: nobody → server-ops
Component: Knowledge Base Software → Server Operations
Product: support.mozilla.com → mozilla.org
QA Contact: kb-software → mrz
Target Milestone: 1.5.4 → ---
Version: unspecified → other
IT: can we get you to install the php-mb library on that host?  Thanks!
Severity: blocker → major
Assignee: server-ops → justdave
Package php-mbstring-5.2.9-2.rhel5.i386 already installed and latest version
(In reply to comment #3)
> Package php-mbstring-5.2.9-2.rhel5.i386 already installed and latest version

James/Paul ^^^
mb_ereg_replace is from the php-mbstring library. I'm not sure what else could cause it to fail. In this case I'd usually restart Apache--maybe that's worth a shot?
Apache has been restarted.
(In reply to comment #6)
> Apache has been restarted.

I still see this error.
Seeing a related error, maybe (same package?):

https://support-stage-new.mozilla.com/search.php?where=all&locale=en-US&qs=s&q=deleting+bookmarks&sa=Search

Fatal error: Call to undefined function mb_convert_encoding() in /data/www/support-stage-new.mozilla.com/webroot/search.php on line 68
Yes, Stephen, mb_convert_encoding() also comes from the php-mbstring library.

Dave, can you paste the output of running this from the CLI:

  php -r 'var_dump(function_exists("mb_convert_encoding"));'
  php -r 'var_dump(extension_loaded("mbstring"));'

And I wonder if it's possible |which php| could somehow not be the same installation as Apache is using?
Severity: major → critical
[root@mradm02 ~]# /data/bin/issue-generic-command php -r '"var_dump(function_exists(''''mb_convert_encoding''''));"'
===pm-app-generic01===
bool(true)
===pm-app-generic02===
bool(true)
===pm-app-generic03===
bool(true)
===pm-app-generic04===
bool(true)
===pm-app-generic05===
bool(true)
===pm-app-generic06===
bool(true)
[root@mradm02 ~]# /data/bin/issue-generic-command php -r '"var_dump(extension_loaded(''''mbstring''''));"'
===pm-app-generic01===
bool(true)
===pm-app-generic02===
bool(true)
===pm-app-generic03===
bool(true)
===pm-app-generic04===
bool(true)
===pm-app-generic05===
bool(true)
===pm-app-generic06===
bool(true)
[root@mradm02 ~]# /data/bin/issue-generic-command which php
===pm-app-generic01===
/usr/bin/php
===pm-app-generic02===
/usr/bin/php
===pm-app-generic03===
/usr/bin/php
===pm-app-generic04===
/usr/bin/php
===pm-app-generic05===
/usr/bin/php
===pm-app-generic06===
/usr/bin/php
[root@mradm02 ~]# /data/bin/issue-generic-command locate bin/php
===pm-app-generic01===
/opt/hp/hpsmh/bin/php.ini
/usr/bin/php
/usr/bin/php-cgi
/usr/bin/php-config
/usr/bin/phpize
===pm-app-generic02===
/opt/hp/hpsmh/bin/php.ini
/usr/bin/php
/usr/bin/php-cgi
/usr/bin/php-config
/usr/bin/phpize
===pm-app-generic03===
/opt/hp/hpsmh/bin/php.ini
/usr/bin/php
/usr/bin/php-cgi
/usr/bin/php-config
/usr/bin/phpize
/usr/lib/debug/usr/bin/php-cgi.debug
/usr/lib/debug/usr/bin/php.debug
===pm-app-generic04===
/opt/hp/hpsmh/bin/php.ini
/usr/bin/php
/usr/bin/php-cgi
/usr/bin/php-config
/usr/bin/phpize
===pm-app-generic05===
/opt/hp/hpsmh/bin/php.ini
/usr/bin/php
/usr/bin/php-cgi
/usr/bin/php-config
/usr/bin/phpize
===pm-app-generic06===
/usr/bin/php
/usr/bin/php-cgi
/usr/bin/php-config
/usr/bin/phpize
/usr/lib/debug/usr/bin/php-cgi.debug
/usr/lib/debug/usr/bin/php.debug
[root@mradm02 ~]# /data/bin/issue-generic-command php --version
===pm-app-generic01===
PHP 5.2.9 (cli) (built: Jun 23 2009 14:49:15) 
Copyright (c) 1997-2009 The PHP Group
Zend Engine v2.2.0, Copyright (c) 1998-2009 Zend Technologies
    with eAccelerator v0.9.5.2, Copyright (c) 2004-2006 eAccelerator, by eAccelerator
===pm-app-generic02===
PHP 5.2.9 (cli) (built: Jun 23 2009 14:49:15) 
Copyright (c) 1997-2009 The PHP Group
Zend Engine v2.2.0, Copyright (c) 1998-2009 Zend Technologies
    with eAccelerator v0.9.5.2, Copyright (c) 2004-2006 eAccelerator, by eAccelerator
===pm-app-generic03===
PHP 5.2.9 (cli) (built: Jun 23 2009 14:49:15) 
Copyright (c) 1997-2009 The PHP Group
Zend Engine v2.2.0, Copyright (c) 1998-2009 Zend Technologies
    with eAccelerator v0.9.5.2, Copyright (c) 2004-2006 eAccelerator, by eAccelerator
===pm-app-generic04===
PHP 5.2.9 (cli) (built: Jun 23 2009 14:49:15) 
Copyright (c) 1997-2009 The PHP Group
Zend Engine v2.2.0, Copyright (c) 1998-2009 Zend Technologies
    with eAccelerator v0.9.5.2, Copyright (c) 2004-2006 eAccelerator, by eAccelerator
===pm-app-generic05===
PHP 5.2.9 (cli) (built: Jun 23 2009 14:49:15) 
Copyright (c) 1997-2009 The PHP Group
Zend Engine v2.2.0, Copyright (c) 1998-2009 Zend Technologies
    with eAccelerator v0.9.5.2, Copyright (c) 2004-2006 eAccelerator, by eAccelerator
===pm-app-generic06===
PHP 5.2.9 (cli) (built: Jun 23 2009 14:49:15) 
Copyright (c) 1997-2009 The PHP Group
Zend Engine v2.2.0, Copyright (c) 1998-2009 Zend Technologies
    with eAccelerator v0.9.5.2, Copyright (c) 2004-2006 eAccelerator, by eAccelerator
[root@mradm02 ~]# /data/bin/issue-generic-command rpm -qf /etc/httpd/modules/libphp5.so
===pm-app-generic01===
php-5.2.9-2.rhel5
===pm-app-generic02===
php-5.2.9-2.rhel5
===pm-app-generic03===
php-5.2.9-2.rhel5
===pm-app-generic04===
php-5.2.9-2.rhel5
===pm-app-generic05===
php-5.2.9-2.rhel5
===pm-app-generic06===
php-5.2.9-2.rhel5
Isn't support-stage-new on a VM, not on the generic cluster?
doh.  forgot we were talking about stage...

and the box I looked at the first time when I said it was installed already is apparently the wrong one.  It's staged on mrapp-stage04 rather than mrapp-stage02.

mrapp-stage04 does *not* have php-mbstring installed.  I'm installing it now.

I also notice it's using the upstream php 5.1.6 build rather than our internally-packaged 5.2.9.  Will that be an issue?
Installed:
  php-mbstring.x86_64 0:5.1.6-27.el5
(In reply to comment #16)
> Installed:
>   php-mbstring.x86_64 0:5.1.6-27.el5

I think PHP <5.2 may be an issue. There were a couple non-backwards-compatible changes in 5.2. Since we already have the 5.2.9 RPM, let's just use that.
This is still blocking us and QA. Any chance we can get this done sooner than later?
looking into it.
I got the rest of the packages upgraded except memcached.

Getting this error with it.

[root@mrapp-stage04 yum.repos.d]# yum -y --skip-broken install memcached-1.4.4-1.el5.rf
Loaded plugins: rhnplugin, security
Excluding Packages from Extra Packages for Enterprise Linux 5 - x86_64
Finished
Excluding Packages from Base git repository
Finished
Excluding Packages from Red Hat Enterprise 5Server - RPMforge.net - dag
Finished
Setting up Install Process
Resolving Dependencies
--> Running transaction check
---> Package memcached.x86_64 0:1.4.4-1.el5.rf set to be updated
--> Processing Dependency: libevent-1.1a.so.1()(64bit) for package: memcached
--> Finished Dependency Resolution
memcached-1.4.4-1.el5.rf.x86_64 from rpmforge has depsolving problems
  --> Missing Dependency: libevent-1.1a.so.1()(64bit) is needed by package memcached-1.4.4-1.el5.rf.x86_64 (rpmforge)

Packages skipped because of dependency problems:
    memcached-1.4.4-1.el5.rf.x86_64 from rpmforge
[root@mrapp-stage04 yum.repos.d]#
okay, removed nfs-utils and got memcached installed.
we are missing python 2.6 mod_wsgi pkgs, oremj is working on building them.
We narrowed this down to a bad memcache library on the system.  For now, I have disabled memcache within the application and it seems to be working okay.  This is the error I see when I run php on the command line.


[root@mrapp-stage04 db]# php
PHP Warning:  PHP Startup: memcache: Unable to initialize module
Module compiled with module API=20050922, debug=0, thread-safety=0
PHP    compiled with module API=20060613, debug=0, thread-safety=0
These options need to match
 in Unknown on line 0

I don't see this error on mrapp-stage02.
the nfs-utils/libevent conflict is a symptom of the system being in a partial state of upgrade -- half the packages are from RHEL 5.4 and half from RHEL 5.5.  Completing the RHEL 5.5 upgrade will make those errors go away.
Or in this case it actually looks like the memcached package is what's from RHEL 5.4.  But it's from rpmforge, and it doesn't look like they rebuilt it for 5.5 yet.
I rebuilt memcached 1.4.4 against the new libevent and dropped it in the mozilla repo.  It's been installed on mrapp-stage04, and nfs-utils is back as well (you can't mount network shares without that).
Can someone confirm if this is working now or not?
(In reply to comment #27)
> Can someone confirm if this is working now or not?

Yes, this works now [1], though it times out nearly every time I try to approve article changes (different, bug, of course).

[1] https://support-stage-new.mozilla.com/tiki-pagehistory.php?locale=en-US&page=How%20to%20clear%20the%20cache
Resolved FIXED. Thanks Dave & Aravind. I'll let Stephen verify.
Status: NEW → RESOLVED
Closed: 12 years ago
Resolution: --- → FIXED
Verified, per comment 28.
Status: RESOLVED → VERIFIED
Duplicate of this bug: 561208
This opens a pop-up and loads the JS:
https://support-stage.mozilla.com/en-US/forum/1?openpost=1
This doesn't:
https://support-stage-new.mozilla.com/en-US/forum/1?openpost=1

Logged in, here's the output I get at https://support-stage-new.mozilla.com/tiki-js-ask_a_question.php?locale=en-US:
---
<br />
<b>Fatal error</b>:  Call to a member function get() on a non-object in <b>/data/www/support-stage-new.mozilla.com/webroot/lib/cache/memcachelib.php</b> on line <b>86</b><br />
---

Probably php-memcache(d) is either still not installed properly or not configured correctly

MemcacheLib requires $memcached_servers and $memcached_options to be configured in webroot/db/local.php. Can we get some insight on this?


I didn't pay attention to this, so here's a good tip for QA when verifying: if memcache works, you will see something like this at the bottom of the page source (after </html>):
<!-- memcache sumo_fe8ad620ea653c44ba26af84b3301558-->

This is not present on stage-new AFAICT.
Assignee: justdave → server-ops
Status: VERIFIED → REOPENED
Resolution: FIXED → ---
Summary: Fatal error: call to undefined function mb_ereg_replace() when approving KB article edits → Fatal error: memcache is not installed or not configured correctly
We still php/memcache version compatibility issues.  Tossing this to Dave.
Assignee: server-ops → justdave
oh. and memcache is currently disabled in the app.
ok, turns out there's a newer version of php-pecl-memcache in rpmforge than the one we rebuilt against 5.2.9, and it's built against 5.1.6 (because that's what normally ships with RHEL).  Jeremy rebuilt it against 5.2.9 before, and volunteered to do so again, so over to him.
Assignee: justdave → jeremy.orem+bugs
Status: REOPENED → RESOLVED
Closed: 12 years ago12 years ago
Resolution: --- → FIXED
Verified FIXED; ran through comment 0 again and didn't see the error.
Status: RESOLVED → VERIFIED
Gotta reopen:

We're supposed to see something like:

"<!-- memcache sumo_fe8ad620ea653c44ba26af84b3301558-->" in the source of the homepage; we do on prod, but not on:

http://support-stage.mozilla.com/en-US/kb/
Status: VERIFIED → REOPENED
Resolution: FIXED → ---
To clarify: if the package was rebuilt and installed OK, it may be a configuration issue. webroot/db/local.php should contain these details.

It looks like memcache was disabled at some point:
(In reply to comment #34)
> oh. and memcache is currently disabled in the app.

So I'm not sure if it was enabled yet.
Just had to enable it in local.php
Status: REOPENED → RESOLVED
Closed: 12 years ago12 years ago
Resolution: --- → FIXED
Weird, I am seeing it.
(In reply to comment #42)
> Weird, I am seeing it.

I am now too; thanks.  And I still don't get errors.

Verified FIXED.
Status: RESOLVED → VERIFIED
Product: mozilla.org → mozilla.org Graveyard
You need to log in before you can comment on or make changes to this bug.