Job en RUNNING todo el tiempo about elkarbackup-docker

[xezpeleta]

¿Los dos jobs se ejecutan de forma automática a una hora, o han sido ejecutados de forma manual mediante el botón "Run now"?

¿Puedes adjuntar los logs del directorio /var/log/elkarbackup/?

[vnetmx]

Estos Job en particular los ejecute de manera manual sobre "Run now"

Voy a adjuntar los logs, pero hay mucha basura de bots y worms.
log.elkarbackup.tar.gz

[vnetmx]

Hay alguna forma de agregar en la config de rsnapshot que guarde a log?

[xezpeleta]

Puedes ver la configuración de rspanshot que se está usando:

https://github.com/elkarbackup/elkarbackup/wiki/FAQ#is-there-a-way-to-see-the-generated-rsnapshot-configuration-file

[vnetmx]

Sip, ya había visto ese Link, pero no veo la forma de agregar Debugging a la config del Rsnapshot. Seguí investigando y al terminar el rsnapshot no se borra el config file que se genera en el directorio /tmp, aunque el proceso ya no existe en el web gui esta como "RUNNING" y ningún proceso más. Cuando le pongo Abort, se queda ahora en Aborting.

Ejecute manual el rsnapshot con el archivo de config de tmp rsnapshot -c /tmp/rsnapshot1_3.cfg Weekly en este caso y dice que termina con "warnings", no se ven los warnings pero me imagino q el exit code es diferente al que espera el código que ejecuta el comando en el sistema, que es 2.

Es lo único, porque el pidfile si se elimina, pero creo ese es tarea de rsnapshot y no de elkarbackup.

Saludos

[xezpeleta]

Hola @vnetmx , ¿tienes algún tipo de configuración específica que reproduzca este problema? De lo contrario, es díficil conseguir averiguar qué está pasando.

En principio, el exit code 2 no debería ocasionar ningún error diferente al exit code 1 (se trata exactamente igual). Elkarbackup detecta que ha terminado en error y pasa a la siguiente tarea. Por lo tanto, me inclino a pensar que la causa debe ser otra diferente.

¿Cuantos GB ocupan los backups de esa tarea?

Gracias

[vnetmx]

Hola xezpeleta, ninguna config especial, ese backup en particular tiene 147GB, pero tengo otro de 400GB y corre sin problemas. Lo raro de esto es que la razón de por qué no termina es porque los procesos se mueren, es decir, el conf file en TMP no se borra, ni el pid, pero lo que se me hace más extraño es que PHP no reporta que haya crash el proceso, es como si se muriera todo.

[xezpeleta]

Hola xezpeleta, ninguna config especial, ese backup en particular tiene 147GB, pero tengo otro de 400GB y corre sin problemas

¿Es posible que en este caso sean muchos ficheros y más pequeños y por ello necesite más tiempo para realizar la copia? La única explicación que se me ocurre es que por una duración muy prolongada el PHP tenga un límite y se pare antes de terminar, abortando también el rsnapshot de forma brusca.

¿Podrías ejecutar el backup manualmente con rsnapshot y medir el tiempo necesario?

En cualquier caso, dudo mucho que tenga alguna relación con el exit code 2. He conseguido provocar errores de ese tipo y no hay ningún problema. La tarea termina con estado de error, y en el mensaje de error aparece lo siguiente: "WARNING: /usr/bin/rsnapshot \ -V -c /tmp/rsnapshot.20_51.cfg sync: completed, but with some warnings"

[vnetmx]

La única explicación que se me ocurre es que por una duración muy prolongada el PHP tenga un límite y se pare antes de terminar, abortando también el rsnapshot de forma brusca.

Revisé esos timers y no hay forma de que se muriera el proceso antes debido a esto.

¿Podrías ejecutar el backup manualmente con rsnapshot y medir el tiempo necesario?

Ya lo hice y termina la ejecución normal o con warnings, el warning creo era porque respaldaba archivos de registro y estos se estaban escribiendo durante el respaldo.

Lo que se me hace raro es que muera el proceso de php y por consiguiente rsnapshot, ya que todos los files siguen ahí, simplemente murió todo. Sería bueno agregar una opción de "Debug" en el Job para crear un file con el debug del process no? Que opinas de esto?

[xezpeleta]

Sería bueno agregar una opción de "Debug" en el Job para crear un file con el debug del process no? Que opinas de esto?

Podría ser interesante, pero a corto plazo no lo tenemos previsto ya que vemos otras cosas más prioritarias a implementar.

Si quieres hacer debug ahora mismo entiendo que tener un botón no es imprescindible. ¿Puedes usar alguna herramienta externa tipo strace etc. para tu propósito? https://derickrethans.nl/what-is-php-doing.html

Hasta luego

[xezpeleta]

Hay más gente con una problemática similar (elkarbackup/elkarbackup#221)

Sospechamos que puede ser debido al oom-killer que mata el proceso por el consumo de memoria del PHP.

Por favor, ¿puedes comprobar si en el log /var/log/messages tienes mensajes donde aparezca la cadena "oom"?