Solucionar el problema de ejecución de la tarea programada (Cron Job) de ownCloud: Configurar un temporizador systemd fiable

Al abrir la página de administración de ownCloud, observa que las tareas en segundo plano no se han ejecutado recientemente, o que la limpieza, la actividad, el almacenamiento externo y otras tareas en cola parecen retrasarse. Una reacción común es editar cron.phpo añadir una nueva entrada en crontab. Sin embargo, según la documentación actual de ownCloud Server, este no es el mejor punto de partida: ownCloud recomienda el modo en segundo plano de Cron y el occ system:croncomando correspondiente. En un sistema Linux, un temporizador de systemd puede proporcionar la capa de programación en lugar del crontab tradicional.

Esta guía se centra en una instalación de tipo paquete o bare-metal donde ownCloud reside en una ruta como /var/www/owncloud. Si utiliza la imagen oficial de Docker de ownCloud, deténgase antes de crear un temporizador de host: ownCloud documenta que la imagen ya configura cron internamente, controlado por variables como OWNCLOUD_CROND_ENABLEDy . Consulte la documentaciónOWNCLOUD_CROND_SCHEDULE actual de trabajos en segundo plano de ownCloud .

Qué está verificado, qué depende de su servidor y qué aún necesita revisión.

• Verificado: ownCloud recomienda Cron en lugar de AJAX para una ejecución en segundo plano fiable, y documenta occ system:croneste comando para ejecutar trabajos en segundo plano en cola.
• Depende de tu instalación: el directorio de ownCloud, el binario de PHP, la cuenta del servidor web, el entorno de PHP y si ejecutas una instalación de paquete, un contenedor, un dispositivo o una implementación personalizada.
• No es posible determinar, con una guía genérica, el motivo del fallo de la tarea actual. Podría tratarse de un problema con el planificador, pero también podría deberse a permisos incorrectos, una ruta errónea, una configuración diferente de la interfaz de línea de comandos de PHP, problemas de conectividad con la base de datos, bloqueo de archivos o un fallo en una tarea en segundo plano a nivel de aplicación.

Acción: no cree un temporizador hasta que el comando ownCloud exacto funcione manualmente con la misma cuenta que utilizará el temporizador.

Paso 1: Confirme el modo Cron y pruebe ownCloud manualmente.

Para una instalación típica de Apache/Debian, el usuario web es www-data. Reemplace tanto el usuario como la ruta si su entorno es diferente.

sudo -u www-data /var/www/owncloud/occ background:cron
sudo -u www-data /var/www/owncloud/occ system:cron

El primer comando selecciona el modo de ejecución en segundo plano de Cron de ownCloud. El segundo ejecuta las tareas en segundo plano que están en cola. La documentación del comando occ de ownCloud indica que system:cronestá diseñado para la ejecución programada y que la salida de progreso no debe habilitarse en un planificador no interactivo.

Un error común: el "modo cron" en ownCloud no implica que debas usar el crondemonio específicamente. Significa que ownCloud espera que un planificador externo ejecute su programador de tareas en segundo plano. Un temporizador de systemd puede ser ese planificador.

Acción: si el comando manual falla, corrija primero ese error. Un temporizador solo repetirá el mismo fallo según un cronograma.

Paso 2: Encuentra las rutas correctas de PHP y ownCloud.

Algunas instalaciones se occejecutan directamente; otras son más predecibles cuando se invocan con el binario de la CLI de PHP. Confirme ambas:

command -v php
readlink -f /var/www/owncloud/occ
sudo -u www-data /usr/bin/php -f /var/www/owncloud/occ system:cron

La documentación de ownCloud advierte explícitamente que las tareas programadas necesitan encontrar PHP y, por lo tanto, muestra rutas completas en los ejemplos de cron. Esto es igualmente importante en systemd, ya que los servicios reciben un entorno controlado en lugar del entorno interactivo de la consola.

Acción: reemplace /usr/bin/php, /var/www/owncloud, y www-dataen los ejemplos restantes con los valores que funcionaron en su host.

Paso 3: Crear un servicio systemd de ejecución única

Crear /etc/systemd/system/owncloud-cron.service:

[Unit]
Description=Run ownCloud background jobs
After=network.target

[Service]
Type=oneshot
User=www-data
Group=www-data
WorkingDirectory=/var/www/owncloud
ExecStart=/usr/bin/php -f /var/www/owncloud/occ system:cron

Normalmente no se necesita una [Install]sección para el servicio, ya que el temporizador lo activa. Mantener el servicio como tal Type=oneshottambién facilita la interpretación de su ciclo de vida: se inicia, ejecuta el comando una vez, finaliza y vuelve a estar inactivo.

Un error común: un servicio de ejecución única inactivo no se considera automáticamente averiado. Tras una ejecución exitosa, un servicio de ejecución única RemainAfterExit=yesnormalmente pasa a estar inactivo.

Acción: juzgue el éxito por el código de salida y el registro, no por la expectativa de que este servicio permanezca "en funcionamiento".

Paso 4: Crear el temporizador systemd

Crear /etc/systemd/system/owncloud-cron.timer:

[Unit]
Description=Run ownCloud background jobs every 15 minutes

[Timer]
OnCalendar=*:0/15
Persistent=true
Unit=owncloud-cron.service

[Install]
WantedBy=timers.target

La documentación de host-cron de ownCloud recomienda una programación de 15 minutos. El temporizador anterior sigue esa cadencia. Persistent=trueEs útil con un OnCalendartemporizador porque systemd puede activar el calendario si se omitió una vez que la máquina vuelva a estar disponible. El comportamiento exacto depende de la versión de systemd y del tiempo que la máquina estuvo inactiva.

Acción: si necesita un intervalo diferente, cámbielo deliberadamente en lugar de copiar un valor de otro servidor. Una ejecución más frecuente puede aumentar la carga en segundo plano; una ejecución menos frecuente puede retrasar el trabajo en cola.

Paso 5: Reinicie systemd y habilite el temporizador.

sudo systemctl daemon-reload
sudo systemctl enable --now owncloud-cron.timer
sudo systemctl status owncloud-cron.timer

daemon-reloadHace que systemd vuelva a leer los archivos de unidad. enable --nowHabilita el temporizador para futuros arranques y lo inicia inmediatamente.

Acción: si el temporizador no está activo, verifique la configuración systemctl status owncloud-cron.timerantes de volver a modificar la configuración de ownCloud.

Paso 6: Verificar las ejecuciones del temporizador siguiente y anterior.

systemctl list-timers owncloud-cron.timer
systemctl list-timers --all | grep owncloud-cron

list-timersEs la forma más rápida de confirmar que systemd ha programado una nueva activación y de ver cuándo se activó el temporizador por última vez. Esto permite distinguir entre "el temporizador nunca se ejecutó" y "el temporizador se ejecutó, pero ownCloud falló dentro del servicio".

Acción: si falta NEXT o el temporizador no aparece en la lista, vuelva a comprobar el nombre del archivo del temporizador, [Install]la sección y si la unidad estaba habilitada.

Paso 7: Compruebe el registro de servicio, no solo el temporizador.

systemd registra la salida del servicio en el registro a menos que se redirija deliberadamente a otro lugar. La documentación oficial de journalctl describe cómo filtrar las entradas del registro por unidad de systemd.

sudo journalctl -u owncloud-cron.service --since today
sudo journalctl -u owncloud-cron.service -n 100 --no-pager

Error común: «El temporizador está activo, por lo que el cron de ownCloud funciona». Un temporizador activo solo demuestra que el planificador está listo para ejecutarse. Aún se requiere una invocación exitosa del servicio.

Acción: busque errores de PHP, mensajes de permiso denegado, archivos faltantes, errores de base de datos o un código de salida distinto de cero. Solucione el primer error concreto en lugar de reiniciar el temporizador repetidamente.

Paso 8: Inicie una ejecución bajo demanda y verifique ownCloud.

No es necesario esperar 15 minutos para la prueba final:

sudo systemctl start owncloud-cron.service
sudo systemctl status owncloud-cron.service
sudo -u www-data /usr/bin/php -f /var/www/owncloud/occ status

Tras una ejecución exitosa de un solo intento, systemctl statusse puede informar legítimamente que el servicio está inactivo y, además, mostrar status=0/SUCCESS. El resultado importante es que el comando se completó correctamente.

Acción: después de que la prueba de servicio manual sea exitosa, espere al menos una activación programada del temporizador y confirme que aparece una nueva entrada en el diario sin intervención manual.

Si aún no funciona: solucione el problema por capas.

Una nota sobre cron.php y las guías antiguas

Las instrucciones antiguas de ownCloud a menudo invocan cron.phpdirectamente. La documentación actual de ownCloud recomienda occ system:cron, y las notas de la versión de ownCloud explican la migración desde el cron.phpenfoque directo anterior. Consulte las notas de la versión de ownCloud Server .

Acción: si heredaste una unidad crontab o systemd antigua que ejecuta cron.php, compárala con la documentación de tu versión instalada de ownCloud antes de conservarla.

Lista de verificación final

• ownCloud está configurado para ejecutar tareas en segundo plano mediante Cron.
• El comando exacto occ system:cronse ejecuta correctamente con la cuenta de servidor web prevista.
• owncloud-cron.timerestá habilitado y active (waiting).
• systemctl list-timersMuestra tanto la activación siguiente como la anterior después de que haya transcurrido el tiempo suficiente.
• journalctl -u owncloud-cron.serviceMuestra ejecuciones programadas exitosas.
• Esta configuración no duplica el cron que ya proporciona la imagen oficial de Docker de ownCloud ni ningún otro programador de tareas.

Cuando todas esas comprobaciones se superan, habrás verificado algo más que "existe un temporizador": habrás demostrado que systemd programa la tarea, invoca ownCloud con la cuenta correcta y completa correctamente el ejecutor de tareas en segundo plano.