Este molesto error aparece en algunos servidores que puedan tener instalados cPanel con eAccelerator. Puede ser que alguna actualización de cPanel cambie valores por defecto del php.ini de PHP y en mi opinión una de las posibles y frecuentes causas de este fallo.

Para solucionarlo, encuentra el php.ini de tu sistema cPanel, normalmente ubicado en /usr/local/lib/php.ini

Se trata de buscar la variable “eaccelerator.shm_max” y ponerle un valor mayor o igual a 2 MB. Puedes hacer un filtrado de la cadena para asegurarte que la tienes y con que valor con:

1

cat /usr/local/lib/php.ini | grep eaccelerator.shm_max

Por ejemplo puede salirte algo como:

1

eaccelerator.shm_max="0"

Es decir, que usa 0 o el valor por defecto.

Luego si tienes dicha variable puedes cambiarlo con este comando de sed (stream editor) rápidamente:

1

sudo sed -i 's/eaccelerator.shm_max=\"0\"/eaccelerator.shm_max=\"2M\"/g' /usr/local/lib/php.ini

O bien editar por ejemplo con el editor nano:

1

nano /usr/local/lib/php.ini

Y poner:

1

eaccelerator.shm_max="2"

También puedes jugar con la variable eaccelerator.shm_size.

Si te sigue dando problemas eAccelerator otra solución más drástica es desactivarlo, es decir, poner un “;” delante del extension="eaccelerator.so" (puede variar la ruta).

Debes tener en cuenta que el valor por defecto del tamaño de memoria compartida para el kernel 2.6 es de 32 mb.

Puedes cambiar este tamaño al valor deseado en /proc/sys/kernel/shmmax.

Por ejemplo con:

1

echo VALOR > /proc/sys/kernel/shmmax

O añadir la linea kernel.shmmax=VALOR a /etc/sysctl.conf así no tendrás que establecerlo manualmente cada vez que reinicies.

Por otro lado, si estas usando un VPS, asegúrate de que la memoria compartida y los buffers para sockets en la configuración del VPS son suficientes.

Para OpenVZ o tipos similares, puede comprobarlo con:

1

cat /proc/user_beancounter

Para un caso normal, el fail count (failcnt) debería ser cero. Si necesitaras más, deberías preguntar a tu proveedor VPS para agrandar el límite hasta que eAccelerator no fallara.

Fuentes

Documentacion eAccelerator: shm_max

Documentacion eAccelerator: shm_size

FAQ eAccelerator

Si utilizas CenOS y por ejemplo has decidido hacer una actualización de tu versión de Python ya que puede que estuvieras usando la versión 2.4 o 2.6 y quieres actualizar a 2.6 o 2.7 respectivamente, puede ser que te encuentres el error siguiente al ejecutar yum:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15

# yum
/usr/lib/python2.6/site-packages/rpm/__init__.py:7: RuntimeWarning: Python C API version mismatch for module _rpm: This Python has API version 1013, module _rpm has version 1012.
  from _rpm import *
There was a problem importing one of the Python modules
required to run yum. The error leading to this problem was:
   No module named sqlitecachec
Please install a package which provides this module, or
verify that the module is installed correctly.
It's possible that the above module doesn't match the
current version of Python, which is:
2.6.5 (r265:79063, Jun  4 2010, 21:43:07)
[GCC 4.1.2 20080704 (Red Hat 4.1.2-48)]
If you cannot solve this problem yourself, please go to
the yum faq at:
  http://wiki.linux.duke.edu/YumFaq

Este error se debe, a que yum, esta buscando sus bibliotecas para ejecutarse y no las encuentra. Posiblemente por que tu versión de yum esta instalada en otra versión de python anterior y la nueva no tiene dicha versión.

Existen varias formas de solucionar esto, pero en CentOS no esta documentada y a fecha de hoy en google no puedes encontrar ninguna solución. Es más acudiendo al IRC de centos pidiendo ayuda, su respuesta liberal en ingles fue “Date una bofetada o directamente disparate en la cabeza por lo que has hecho“.

Esta respuesta me indigno mucho, sobre todo porque me pareció pésimo el soporte, que sin darme solución, encima me respondía de esa forma, aparte el problema realmente reside en que ellos no son capaces de solucionártelo y puesto que no actualizan la versión de python en años “para que sea estable“, los usuarios y sysadmin deben ingeniárselas solucionando los problemas.

Luego después de experimentar mis soluciones fueron las siguientes:

- Reinstalar yum a traves de rpm: esto probablemente funcionaría, pero no, ya que se instalaría incorrectamente con la nueva versión de python y no conseguí hacer nada, quizás hice mal algún paso.

- Reinstalar el paquete yum-metadata-parser que contiene las dependencias de yum. Igualmente al reinstalarlo no tuvo efecto ya que estaría cogiendo una mezcla de paths.

- Modificar la variable de entorno PYTHONPATH. De igual forma no funciono ni poniendo versiones más antiguas.

La solución final, que aunque fue cutre, conseguí hacerlo funcionar, fue la siguiente:

Buscar el binario de yum:

1

# which yum

En mi caso la salida fue:

1
2

# which yum
/usr/bin/yum

Luego tras comprobar que el tipo del archivo era un script en python:

1
2

# file /usr/bin/yum
/usr/bin/yum: python script text executable

Me fije en el archivo para editarlo:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33

# cat /usr/bin/yum
#!/usr/bin/python
import sys
try:
 import yum
except ImportError:
 print >> sys.stderr, """\
There was a problem importing one of the Python modules
required to run yum. The error leading to this problem was:
 
 %s
 
Please install a package which provides this module, or
verify that the module is installed correctly.
 
It's possible that the above module doesn't match the
current version of Python, which is:
%s
 
If you cannot solve this problem yourself, please go to 
the yum faq at:
 http://wiki.linux.duke.edu/YumFaq
 
""" % (sys.exc_value, sys.version)
 sys.exit(1)
 
sys.path.insert(0, '/usr/share/yum-cli')
try:
 import yummain
 yummain.user_main(sys.argv[1:], exit_code=True)
except KeyboardInterrupt, e:
 print >> sys.stderr, "\n\nExiting on user cancel."
 sys.exit(1)

Si os fijáis, nuestro error se da en este preciso archivo, ya que falla una excepción con el ImportError. Y en la primera línea tenemos un:

1

#!/usr/bin/python

Basta con cambiar esa línea para decirle al script que ejecute una versión antigua de python (la que funcionaba) de nuestro sistema. Es decir, cambiar (en mi caso a python 2.4):

1

#!/usr/bin/python2.4

Y listo, yum funcionará sin problemas. Obviamente, con un mejor análisis de la situación, se podría hacer que yum cogiera realmente la última versión de python y sus bibliotecas (probablemente por el path), pero eso requiere de mayor trabajo y tiempo y para mí esta solución fue valida. Sin embargo, si alguien esta dispuesto a comentar una mejor solución, estaré agradecido.

Si utilizas Cpanel y Centos 5.5 o cualquier sistema similar donde encuentres este error en tus error_log de apache:

1
2

[04-Aug-2010 10:32:08] PHP Warning:  PHP Startup: Unable to load dynamic library '/usr/local/lib/php/extensions/no-debug-non-zts-20090626/pdo_sqlite.so'
- /usr/local/lib/php/extensions/no-debug-non-zts-20090626/pdo_sqlite.so: undefined symbol: sqlite3_libversion in Unknown on line 0

Puedes llegar a saturarte el disco de mensajes de error y para evitar dicho error y solucionar el problema, simplemente debes desactivar la extensión pdo_sqlite.so de tu php.ini global y puedes hacerlo fácilmente con el siguiente comando:

1

sudo sed -i 's/extension=pdo_sqlite.so/;extension=pdo_sqlite.so/g' /usr/local/lib/php.ini

Esta es una solución para evitar el problema, pero la solución buena sería conseguir detectar el error que lo produce y solucionar para que no se tenga que desactivar dicha extensión.

Si conoces como solucionarlo bien, me encantaría leerlo en los comentarios.