Si eres administrador de servidores web y trabajas con aplicaciones de uso intensivo de sesiones, como Moodle (muchos alumnos), en un entorno con OpenLiteSpeed / CyberPanel, seguramente te has encontrado con la promesa de LSMCD (LiteSpeed Memcached Daemon): un reemplazo optimizado de Memcached pensado para mejorar el rendimiento de aplicaciones web. Sin embargo, la experiencia práctica puede ser más compleja de lo esperado.
En este artículo comparto un caso real que viví con mi campus Moodle “Academia Desarrollo Web”, los errores que surgieron y cómo solucionarlos definitivamente.
El problema
Todo comenzó con errores recurrentes al cargar Moodle.
Server error logs:
PHP Warning: session_start(): error getting session from memcached: CONNECTION FAILURE, server has disconnected
PHP Warning: session_start(): Failed to read session data: memcached
Al revisar el dashboard de CyberPanel y los logs de PHP, noté que LSMCD estaba corrompiendo los locks de sesión. Más tarde, explorando los logs de LSMCD (/tmp/lsmcd.log), aparecieron mensajes como:
Program crashed and may have produced a core file. Automatically restarted
[ERROR] [SHM] Unable to setup SHM MapFile [/dev/shm/lsmcd/data5.shm]. Message type: LSSHM_BADVERSION
Diagnóstico
- LSMCD usaba memoria compartida (SHM) para almacenar locks y datos de sesiones.
- Los errores
LSSHM_BADVERSIONindicaban que los archivos SHM estaban corruptos o incompatibles. - Cada vez que LSMCD fallaba y se reiniciaba automáticamente, Moodle perdía la capacidad de leer/escribir sesiones, causando warnings y errores de login.
En otras palabras, aunque el proceso parecía “activo”, el backend de sesiones era inestable.
Primera prueba: LSMCD funcionando
Un test con PHP puro mostró que el cliente memcached podía conectarse:
php -r '$m = new Memcached(); $m->addServer("127.0.0.1",11211); var_dump($m->set("testkey","hola")); var_dump($m->get("testkey"));'
Salida:
bool(true)
string(4) "hola"
Esto confirmó que la conexión básica funcionaba, pero los errores de sesiones en Moodle eran intermitentes y relacionados con la gestión interna de SHM de LSMCD.
La decisión: migrar a Memcached estándar
Dado que los problemas podían volver en cualquier momento, decidí reemplazar LSMCD por memcached “ortodoxo”, el daemon estándar y ampliamente probado:
Pasos realizados:
Detener y deshabilitar LSMCD:
systemctl stop lsmcd
systemctl disable lsmcd
Instalar Memcached estándar (el giro a lo «ortodoxo»:
dnf install memcached -y
Activar y arrancar el servicio:
systemctl enable memcached --now
systemctl status memcached
Ajustar parámetros según la memoria del servidor (4 - 8 GB):
# /etc/sysconfig/memcached
PORT="11211"
USER="memcached"
MAXCONN="2048"
CACHESIZE="512" # MB
OPTIONS="-l 127.0.0.1,::1"
Reiniciar el daemon para aplicar la configuración:
systemctl daemon-reexec
systemctl restart memcached
Cinsiderando que Moodle ya estaba configurado con:
$CFG->session_handler_class = '\core\session\memcached';
$CFG->session_memcached_save_path = 'localhost:11211';
$CFG->session_memcached_prefix = 'memc.sess.key.';
no hubo necesidad de modificar parámetros pues lsmcd utilizaba la misma configuración de memcached, y ahora funcionó sin errores de sesión.
Resultados
- Moodle cargó correctamente y los logins funcionaron simultáneamente en múltiples navegadores.
- La inestabilidad de sesiones desapareció por completo.
- Se confirmó que LSMCD no es recomendable para aplicaciones críticas con muchas sesiones simultáneas, a menos que se ajusten parámetros internos complejos y se monitorice continuamente.
Conclusión
La experiencia demuestra que:
- Aunque LSMCD es útil para cache web ligera en OpenLiteSpeed, no siempre es confiable para manejar sesiones de aplicaciones complejas como Moodle.
- La alternativa más segura y estable es usar Memcached estándar (ortodoxo) en servidores Linux, con configuraciones de memoria y conexiones adecuadas.
- Compartir este tipo de experiencias puede ayudar a otros administradores a prevenir problemas de sesión y caídas intermitentes.
Como dicen en la documentación oficial de LiteSpeed:
“If you have experienced an error while using LSMCD Secure User Data in a CloudLinux/cPanel environment, you will probably require administrator intervention.”
Fuente
💡 Lección final: conocer bien el backend de sesiones que utiliza tu aplicación y los límites de tu servidor evita errores difíciles de diagnosticar. Cuando un componente crítico falla intermitentemente, a veces lo más prudente es migrar a la solución más compatible y probada, en lugar de intentar mantener un sistema inestable.
Save as PDFAbout the Author
