Encolando encolando, triunfé trabajando
Bueno, pues primer post sobre trabajo.
Llevo una semana debuggeando un proceso que tenemos en mi empresa para procesar trabajos de colas. Por diferentes motivos, utilizamos una librería vieja llamada php-resque. Es… viejita. Y, además, hemos hecho un fork, así que también es difícil.
El Problema
Básicamente, estamos en medio de una actualización de imagen base (de 18.04 a 22.04), actualización de PHP (de 7.4 a 8.2) y actualización de algunas librerías. Pues parece que eso a resque no le mola, pero no de la manera que estás creyendo.
Al ser colas, tenemos automatizado en demonios la ejecución de dichas colas. Por lo que delegamos en systemd que se ejecuten las colas y listo.
Pues el problema es que, ejecutando el proceso de colas a mano funciona pero mediante systemd no.
SystemD bajo lupa
Aquí empezamos a investigar qué narices pasaba con systemd y que diferencias podría haber con una shell. Pero no había nada raro. Después de los logs, cambios en la forma de ejecutarlo desde la shell para asimilar a systemd,… No encontramos nada
Y, entonces, empecé a investigar htop y vi que el estado de la mayor parte de los procesos estaba en D (Uninterruptible sleep). Estaban todos esperando I/O? Bueno, normal, no? Hace un sleep para chequear la cola y, entonces, ejecutar el job. Así que eso no debería ser… Pero habrá pasado algo con el proceso?
La magia de /proc
Mira que he estado administrando sistemas Linux y desplegando cosas, pero nunca me había puesto a debuggear el cómo se ejecutaba un proceso en Linux y como se podía investigar. Resulta que /proc tiene la magia al respecto de investigar procesos, y me puse a ello.
En este caso, me centré más en syscall y stack, para intentar adivinar qué narices pasa.
Y en syscall, si que me he encontrado esto en muchos de esos procesos:
-1 0x7fff031e2338 0x7f7f76fdba70
Alarmas, el -1 es un error. Pero por qué? Si no aparece nada en el journal del proceso…
Una idea! Cambiar los fwrite a echo para evitar escribir de aquella manera a los file descriptors!
Al final sí que era SystemD aka La Solución
Pues, investigando investigando, vimos que todos los procesos de TVL estaban dentro de un slice. Un slice es una entidad de SystemD en el cual todos los procesos dentro comparten unas configuraciones. En este caso, era que existía un límite de memoria por proceso y, por lo que fuera, la memoria por proceso había subido, por lo que se quedaba congelado, pero no teníamos ningún tipo de información al respecto.
Subimos la configuración y todo quedó listo.
Epílogo
A ver, con esto se que he aprendido algo más, pero ha sido una investigación lo suficientemente larga como para que me haya cansado/hartado de SystemD durante un tiempo. También sé que tengo que mejorar mucho y estudiar toda la parte de infraestructura, y probablemente me ponga a ello.
No es que haya sido un dolor investigarlo per se, sino que ha sido difícil no saber que herramientas tiene.