Risolvi il problema dei processi Cron di Nextcloud che non vengono eseguiti automaticamente con systemd

Per eseguire automaticamente i processi in background di Nextcloud con systemd, configura un servizio "one-shot" che venga eseguito cron.phpcon l'utente del server web, quindi abilita un timer che avvii tale servizio ogni cinque minuti. I controlli fondamentali sono: il timer è abilitato e ha un orario di esecuzione successivo impostato, il servizio punta ai percorsi corretti di Nextcloud e PHP e il registro del servizio mostra un'uscita avvenuta con successo. Un servizio "one-shot" potrebbe risultare "inattivo (terminato)" tra un'esecuzione e l'altra; questo è normale dopo la sua conclusione.

Questa configurazione è per un'installazione convenzionale di Nextcloud su Ubuntu utilizzando systemd, con i file di Nextcloud disponibili sull'host. Se Nextcloud viene eseguito all'interno di Docker, Snap o un'appliance come Nextcloud All-in-One, utilizzare il metodo di pianificazione documentato di tale distribuzione anziché puntare un'unità host a un percorso riservato ai container. Gli esempi seguenti utilizzano /var/www/nextcloude www-data; sostituirli con il percorso di installazione effettivo e l'utente HTTP sul server.

Cosa dovrebbe fare il timer

Nextcloud cron.phpesegue attività in background in coda, come la manutenzione e le attività delle app. Il timer di systemd funge da orologio; il servizio è il comando che viene eseguito allo scadere del timer. Sono necessari entrambi. Creare i file senza abilitare il timer lascia la pianificazione inattiva, mentre abilitare un timer che punta al percorso PHP o Nextcloud errato può causare ripetuti errori di esecuzione.

Nextcloud consiglia di utilizzare cron di sistema per le attività in background in ambiente di produzione. Il manuale di amministrazione attuale documenta anche i timer di systemd come alternativa. La pianificazione di esempio si avvia cinque minuti dopo l'avvio del sistema e si ripete cinque minuti dopo ogni attivazione di un servizio. In questo modo si evita di dover richiedere all'utente di accedere all'interfaccia web.

1. Conferma il percorso di installazione, l'utente e PHP CLI

Prima di modificare le unità, individua la directory Nextcloud effettiva e verifica quale comando PHP si aspetta l'installazione del server web. In una tipica installazione da archivio Ubuntu, il percorso potrebbe essere /var/www/nextcloud, l'utente web è spesso www-datae PHP CLI è /usr/bin/php. Verifica invece di dare per scontato:

ls -l /var/www/nextcloud/cron.php
command -v php
php -v

Se la directory di Nextcloud si trova altrove, sostituiscila in entrambi i comandi unitari seguenti. Se il server web utilizza una versione di PHP separata, usa l'eseguibile CLI di tale versione in ExecStarte ExecCondition. Un servizio systemd non eredita il PATH o l'ambiente della shell interattiva, quindi i percorsi espliciti sono più affidabili.

Esegui il controllo dello stato con lo stesso utente che verrà utilizzato da systemd:

sudo -u www-data /usr/bin/php -f /var/www/nextcloud/occ status -e

Il comando di Nextcloud occdeve essere eseguito come utente HTTP per preservare la corretta proprietà e i permessi dei file. Se questo test segnala un errore PHP, la modalità di manutenzione o un file mancante, risolvere prima questo problema; il timer non può compensare un comando Nextcloud non riuscito.

2. Creare il servizio one-shot

Crea /etc/systemd/system/nextcloudcron.service:

sudo nano /etc/systemd/system/nextcloudcron.service

Accedere a questa unità, regolando il percorso e l'utente se la propria installazione è diversa:

[Unit]
Description=Nextcloud cron.php job

[Service]
User=www-data
ExecCondition=/usr/bin/php -f /var/www/nextcloud/occ status -e
ExecStart=/usr/bin/php -f /var/www/nextcloud/cron.php
KillMode=process

ExecConditionVerifica se Nextcloud funziona correttamente prima di avviare il job in background. Se la condizione non è soddisfatta, systemd salta l'esecuzione; consultare il registro per comprenderne il motivo. KillMode=processConsente ai programmi esterni avviati da un job in background di continuare a funzionare anche dopo la chiusura del processo cron principale. L'esempio attuale di Nextcloud non richiede una [Install]sezione in questo file di servizio.

L'utilizzo di questa opzione /usr/bin/phpè appropriato solo se si tratta dell'interprete CLI corretto sul server. Ad esempio, un repository PHP personalizzato potrebbe installare un binario con versione. Utilizzare la stessa versione di PHP compatibile richiesta da Nextcloud e utilizzata dalla configurazione del suo server web.

3. Crea il timer

Crea /etc/systemd/system/nextcloudcron.timer:

sudo nano /etc/systemd/system/nextcloudcron.timer

Aggiungere:

[Unit]
Description=Run Nextcloud cron.php every 5 minutes

[Timer]
OnBootSec=5 min
OnUnitActiveSec=5 min
Unit=nextcloudcron.service

[Install]
WantedBy=timers.target

OnBootSecPianifica la prima esecuzione cinque minuti dopo l'avvio di systemd all'avvio del sistema. OnUnitActiveSecPianifica un'altra esecuzione cinque minuti dopo l'ultima attivazione del servizio. Il timer non è lo stesso del servizio: abilita e avvia l' .timerunità per far sì che la pianificazione venga eseguita automaticamente.

4. Ricarica systemd e abilita il timer

Chiedi a systemd di leggere i nuovi file di unità, quindi abilita e avvia il timer con un unico comando:

sudo systemctl daemon-reload
sudo systemctl enable --now nextcloudcron.timer

Controlla il timer:

systemctl status nextcloudcron.timer
systemctl list-timers --all | grep nextcloudcron

Il timer dovrebbe essere caricato e attivo e list-timersdovrebbe mostrare un orario futuro sotto NEXT. Se è disabilitato, non caricato o non ha una prossima attivazione, verifica che il nome del file termini con .timer, che la [Install]sezione contenga WantedBy=timers.targete che tu abbia eseguito daemon-reloaddopo aver salvato i file.

5. Eseguire un test e analizzarne il risultato.

È possibile avviare il servizio una sola volta senza attendere il successivo tick del timer:

sudo systemctl start nextcloudcron.service
sudo systemctl status nextcloudcron.service
sudo journalctl -u nextcloudcron.service -n 50 --no-pager

Controlla il risultato del servizio e gli eventuali errori PHP o Nextcloud. Dopo il completamento del comando, nextcloudcron.servicepotrebbe verificarsi un ritorno a inactive (dead)perché si tratta di un'attività una tantum. Questo da solo non significa che sia fallita. Il timer dovrebbe rimanere attivo e pianificare l'esecuzione successiva; il registro dovrebbe indicare se l'esecuzione precedente è terminata correttamente.

Nelle impostazioni di amministrazione di Nextcloud, apri l'area relativa allo stato dei processi in background e verifica che l'ora dell'ultima esecuzione del processo aumenti dopo lo scatto del timer. L'avviso di panoramica dovrebbe scomparire quando Nextcloud rileva attività in background recenti. Attendi almeno un intervallo di tempo dopo l'attivazione del timer prima di considerare che la pianificazione non sia stata eseguita.

Diagnosticare i modelli di guasto più comuni

Per maggiori dettagli, consultare i registri di servizio recenti e il file di registro di Nextcloud:

sudo journalctl -u nextcloudcron.service --since "30 minutes ago" --no-pager
sudo -u www-data /usr/bin/php -f /var/www/nextcloud/occ background-job:list

L'elenco dei processi mostra le attività registrate, ma di per sé non è una prova che il timer sia in esecuzione. Utilizza congiuntamente l'ora dell'ultima e della prossima attivazione del timer, il registro dei servizi e l'indicatore dell'ultima esecuzione di Nextcloud.

Quando utilizzare uno scheduler diverso

I timer di Systemd funzionano bene quando il server esegue systemd e si desidera una pianificazione locale gestita dal servizio. Se si utilizza già un demone cron standard e se ne può verificare il crontab, è supportata anche una voce cron di sistema che richiama lo stesso cron.phpmetodo www-data. Non pianificare entrambi i metodi per la stessa istanza di Nextcloud; le invocazioni sovrapposte possono sprecare risorse e complicare la risoluzione dei problemi.

La pianificazione AJAX dipende dagli utenti che visitano Nextcloud ed è meno affidabile per un server molto occupato o multiutente. Le chiamate Webcron cron.phptramite HTTP possono essere adatte per istanze di piccole dimensioni in cui l'accesso al sistema non è disponibile, ma Nextcloud fa notare che l'esecuzione web limita la quantità di lavoro che può essere eseguita per chiamata. Se Nextcloud è containerizzato o gestito da un'appliance, utilizzare lo scheduler o la configurazione del container supportati; un servizio host che utilizza /var/www/nextcloudnon funzionerà se tale percorso non è presente sull'host.

Una configurazione ottimale prevede un timer abilitato con un orario NEXT ricorrente, esecuzioni del servizio che si completano senza errori PHP e un orario dell'ultima esecuzione di Nextcloud che avanza. Se tutte e tre le condizioni sono soddisfatte ma una particolare attività dell'app risulta ancora in ritardo, è possibile che lo scheduler stia lavorando mentre l'attività in questione attende la propria pianificazione, una finestra di manutenzione o il completamento delle condizioni della coda. Diagnosticare l'attività separatamente prima di modificare l'intervallo del timer.

Riferimenti ufficiali

• Manuale di amministrazione di Nextcloud 35: processi in background e timer di systemd
• Manuale di amministrazione di Nextcloud: utilizzo del comando occ
• Manuale di amministrazione di Nextcloud 35: comandi per i processi in background
• Manuale del timer systemd di Ubuntu 24.04