Síntomas característicos
Algunas plataformas Moodle del servidor dejan de cargar de forma intermitente con error 503 Service Unavailable.
Otras plataformas alojadas en el mismo servidor siguen funcionando con normalidad.
La caída aparece y desaparece sin un patrón claro para el cliente; muchas veces el servicio se restablece al reiniciar Apache/LiteSpeed/MySQL.
Tras un reinicio, todo vuelve a la normalidad pero el problema reaparece minutos u horas después.
El cliente convive con esto repitiendo varias caídas al día.
Por qué ocurre
Cuando una sola cuenta cPanel concentra varias plataformas Moodle en subdominios (por ejemplo plataforma1.tudominio.com, plataforma2.tudominio.com, etc.), todas comparten el mismo pool de procesos PHP-LSAPI.
El servidor LiteSpeed define cuántos hijos puede arrancar PHP en paralelo para esa cuenta a través del parámetro PHP_LSAPI_CHILDREN. Si ese pool se queda corto frente a la carga real, LiteSpeed empieza a rechazar peticiones con 503 y en el error_log del servidor aparecen entradas como:
connection to [uds://tmp/lshttpd/lsphpXX.sock...] ... Resource temporarily unavailable
Las causas típicas de saturación del pool en este escenario son:
Decenas de tareas cron de Moodle programadas todas a los 00 segundos de cada minuto, que arrancan a la vez muchos procesos
php-cgi.Tráfico SCORM y descargas vía
pluginfile.phpque mantienen conexiones largas y pesadas.Subidas de archivos grandes, copias de seguridad de Moodle o reportes que se ejecutan a la vez.
Cron jobs personalizados mal configurados que reinician servicios del sistema con más frecuencia de la prevista.
Por qué solo se cae una parte de las plataformas
El pool PHP-LSAPI se aplica a la cuenta cPanel, no al servidor entero. Por eso las plataformas Moodle alojadas en otras cuentas del mismo servidor siguen respondiendo sin problemas: solo la cuenta que concentra muchas instalaciones agota su pool.
De ahí que el cliente vea caídas "selectivas" en sus propias plataformas y le resulte difícil de diagnosticar.
Cómo lo diagnostica soporte
Cuando un ticket reporta este patrón, el equipo técnico revisa:
Los logs
/usr/local/apache/logs/error_logbuscando las líneasResource temporarily unavailableapuntando al socketlsphpXX.sock.Los domlogs de los subdominios afectados para confirmar los 503 reales en URLs típicas (SCORM,
pluginfile.php,login/index.php, etc.).Los cron jobs de la cuenta en
/var/spool/cron/<cuenta>para detectar tareas Moodle ejecutándose en paralelo.El valor de PHP_LSAPI_CHILDREN en la configuración de LiteSpeed para la versión de PHP que usa la cuenta.
Cron jobs anómalos del sistema (por ejemplo, reinicios programados de Apache que no respondan a lo esperado).
Acciones que aplica soporte
Ampliar el valor de PHP_LSAPI_CHILDREN para esa versión de PHP (en casos reales se ha pasado de 35 a 100) para que la cuenta pueda servir más peticiones PHP en paralelo.
Eliminar o reescribir cron jobs problemáticos. Un ejemplo real detectado:
* */6 * * * systemctl restart httpd.service. Esa línea no reinicia "cada 6 horas", sino que reinicia Apache cada minuto durante las horas 00, 06, 12 y 18, generando interrupciones constantes.Reiniciar LiteSpeed/Apache y MySQL una vez aplicados los cambios para liberar procesos colgados.
Qué puede hacer el cliente para reducir la saturación
Distribuir los cron de Moodle: evitar tener todas las plataformas con el cron a los
0 * * * *(cada minuto al segundo 0). Programar minutos distintos según la plataforma reduce el pico simultáneo.Si una plataforma tiene picos previsibles (lanzamientos de cursos, exámenes con SCORM, etc.), planificarlo con soporte para escalar recursos temporalmente.
Revisar cron jobs propios añadidos directamente al servidor o vía cPanel y eliminar los que no estén justificados.
Cuando una sola cuenta cPanel concentra muchas instalaciones grandes de Moodle, valorar separarlas en cuentas distintas o pasar a un servidor cloud dedicado a Moodle, donde el pool y los recursos se ajustan a esa carga.
Diferencias con otros patrones de 503
No es lo mismo que un 503 por bots agresivos haciendo scraping (eso se ataca con reglas
.htaccessy robots.txt).No es lo mismo que un 503 por kernel connection limit (límite de conexiones por cliente del propio kernel).
No es lo mismo que un 503 por fallo del CageFS de CloudLinux (que afecta a una cuenta entera, incluido el Terminal de cPanel).
No es lo mismo que un 503 generalizado por actualizaciones críticas de cPanel/WHM que reinician todos los servicios.
La señal distintiva de este caso es: varias plataformas Moodle en la misma cuenta, cron simultáneos, error en el socket lsphpXX.sock y caídas que afectan solo a esa cuenta.