Come risolvere l'errore "Timeout del meccanismo di blocco" di ownCloud

Se ownCloud segnala un timeout di blocco file durante la sincronizzazione, il caricamento, lo spostamento, la ridenominazione o l'assemblaggio di blocchi, la prima cosa da sapere è che l'errore di solito riguarda il blocco transazionale dei file , non la funzione di blocco manuale dei file visibile all'utente. Il blocco transazionale è un meccanismo di sicurezza interno che impedisce a due richieste di salvare o modificare lo stesso file contemporaneamente. È abilitato per impostazione predefinita in ownCloud e può utilizzare il database o Redis come backend di blocco.

La documentazione attuale di ownCloud 11 raccomanda ancora Redis per il blocco transazionale dei file, poiché i blocchi basati su database creano un carico significativo sul database stesso. Nelle installazioni cluster, ogni nodo dell'applicazione deve utilizzare la stessa istanza Redis condivisa per il blocco. Questa è la soluzione definitiva da comprendere prima di modificare i valori di timeout o eliminare i record di blocco.

Questa guida analizza il problema dal punto di vista di un amministratore principiante: cosa significa il blocco, cosa eseguire il backup, come identificare il componente difettoso, come configurare Redis, come i cluster modificano il quadro generale e quali scorciatoie possono peggiorare la situazione.

Cosa significa l'errore

Quando ownCloud modifica un file, acquisisce un blocco in modo che un'altra richiesta non possa eseguire una modifica incompatibile contemporaneamente. Il blocco può anche riguardare una directory padre, impedendone la ridenominazione mentre si sta lavorando al suo interno. Se il blocco non può essere acquisito in tempo, l'operazione può fallire con un errore di risorsa bloccata o di timeout, anziché rischiare di danneggiare il file.

Secondo la documentazione di ownCloud 11 relativa al blocco transazionale dei file , questo meccanismo gestisce anche i caricamenti interrotti, i file condivisi, l'archiviazione esterna e i file crittografati.

Questo è diverso dal blocco manuale dei file , la funzionalità opzionale di check-in/check-out basata su WebDAV che consente a un utente di bloccare deliberatamente un file nell'interfaccia web. I blocchi manuali hanno valori di scadenza configurabili dall'utente. La modifica di tali valori non risolve i problemi di un backend di blocco transazionale sovraccarico o configurato in modo errato.

Prima di iniziare

• Eseguire il backup del database di ownCloud e config/config.php.
• Annota la tua versione di ownCloud e il tipo di implementazione: pacchetto tradizionale, Docker Compose o cluster multi-nodo.
• Identifica il motore del tuo database e verifica se Redis è già installato.
• Registra l'operazione esatta che non riesce, ad esempio la sincronizzazione del desktop, il caricamento tramite WebDAV, la ridenominazione di una cartella o il caricamento a blocchi.
• Indica se il problema riguarda un singolo file, un singolo utente o più utenti contemporaneamente.

Un'interruzione di servizio estesa che interessa molti utenti di solito indica un componente condiviso come il backend di blocco, il database, Redis o lo storage. Un errore ripetibile su un singolo file potrebbe invece essere dovuto a un'operazione effettivamente in corso o a un blocco obsoleto non ancora scaduto.

Passaggio 1: Individuare il meccanismo di bloccaggio difettoso

Iniziate analizzando i log di ownCloud, del server web, di PHP-FPM e lo stato del servizio Redis. Cercate eccezioni di risorse bloccate ripetute, errori di attesa di blocco del database, errori di connessione a Redis o uno schema in cui lo stesso percorso rimane bloccato a lungo dopo la conclusione dell'operazione originale.

Tra i controlli utili da effettuare su un host Linux si annoverano:

systemctl status redis-server
redis-cli PING
ps -ef | grep php
tail -n 200 /path/to/owncloud/data/owncloud.log

Un comando Redis funzionante correttamente dovrebbe restituire PONG. Se ownCloud è configurato per raggiungere Redis tramite un socket, un nome host del container, una password o un host remoto, testa lo stesso percorso di connessione effettivamente utilizzato da ownCloud anziché presumere che un redis-clitest locale dimostri la connettività dell'applicazione.

Se il log contiene un messaggio del database simile a "timeout di attesa del blocco superato", è necessario verificare anche la presenza di contesa sul database. Il vecchio backend di blocco del database è funzionante, ma la documentazione di ownCloud avverte esplicitamente che comporta un carico significativo sul database.

Passaggio 2: Spostare il blocco dei file transazionali su Redis

Per un'installazione tradizionale di ownCloud, configura Redis come memcache.lockingbackend in config/config.php. La documentazione attuale sulla cache di memoria di ownCloud fornisce un esempio di Redis TCP simile a questo:

'filelocking.enabled' => true,
'memcache.locking' => '\OC\Memcache\Redis',
'redis' => [
    'host' => 'localhost',
    'port' => 6379,
    'timeout' => 0,
    'password' => '',
],

Non copiare letteralmente la password vuota in una configurazione Redis esposta a Internet. La documentazione sulla cache di memoria di ownCloud raccomanda di proteggere Redis in modo appropriato. Idealmente, Redis dovrebbe essere raggiungibile solo da host ownCloud attendibili o dalla rete interna dei container.

Nella configurazione Docker ufficiale di ownCloud, Redis è abilitato tramite variabili d'ambiente. La documentazione attuale di ownCloud 11 mostra quanto segue:

OWNCLOUD_REDIS_ENABLED=true
OWNCLOUD_REDIS_HOST=redis
OWNCLOUD_REDIS_PORT=6379

Quando Redis è abilitato in quel modello di distribuzione, ownCloud imposta automaticamente sia la cache distribuita che la cache di blocco su Redis. Utilizza la configurazione specifica per la distribuzione documentata per la tua installazione anziché combinare variabili d'ambiente Docker con una configurazione gestita manualmente, config.phpa meno che tu non sappia quale livello ha la precedenza.

Passaggio 3: In un cluster, fai in modo che ogni nodo utilizzi lo stesso Redis

Un cluster è una distribuzione con più server applicativi ownCloud dietro un bilanciatore di carico. In questa architettura, un blocco creato su un nodo applicativo deve essere visibile a tutti gli altri nodi. Le cache APCu per nodo o le istanze Redis separate per nodo non possono fornire questo stato di blocco condiviso.

La guida di ownCloud per lo storage condiviso in cluster è esplicita: utilizzare un'istanza Redis condivisa raggiungibile da tutti i nodi dell'applicazione. Avverte inoltre di non fare affidamento su blocchi di filesystem o NFS per il blocco a livello di applicazione di ownCloud.

Verificate che ogni nodo utilizzi lo stesso endpoint Redis e le stesse credenziali. Un errore comune si verifica quando un nodo utilizza ancora il database o un'istanza locale di Redis, mentre gli altri utilizzano il servizio condiviso. Ciò crea un comportamento di blocco incoerente che può apparire intermittente, poiché il risultato dipende dal nodo applicativo che gestisce ciascuna richiesta.

Passaggio 4: Verificare la configurazione e riprovare l'operazione originale

Dopo aver configurato Redis, verifica le impostazioni attive di ownCloud con occ. A seconda dell'installazione, il comando può essere eseguito come utente del server web o tramite Docker Compose.

sudo -u www-data php occ config:system:get memcache.locking
sudo -u www-data php occ config:system:get filelocking.enabled

Il primo comando dovrebbe segnalare \OC\Memcache\Redis, e il blocco transazionale dei file dovrebbe rimanere abilitato. Non "risolvere" il problema disabilitando il blocco dei file. Ciò rimuove una misura di sicurezza per l'integrità dei dati invece di correggere il backend.

Ora riprova esattamente l'operazione che ha causato l'errore. Se il caricamento di un client desktop è andato in timeout, ripeti il ​​caricamento. Se lo spostamento di una cartella non è riuscito, ripeti lo spostamento. Monitora i log di ownCloud e Redis durante il test. Un nuovo tentativo riuscito, senza timeout di blocco ricorrenti, è una prova molto più convincente rispetto all'esecuzione di un comando di manutenzione non correlato.

Cosa succede se il file risulta ancora bloccato?

Innanzitutto, accertatevi che un'altra operazione stia effettivamente ancora utilizzando il file. Caricamenti di grandi dimensioni, chiamate a dispositivi di archiviazione esterni, spostamenti di file, crittografia o archiviazione lenta possono legittimamente mantenere i blocchi più a lungo del previsto. Interrompere il blocco mentre l'operazione è ancora attiva può creare la condizione di competizione che il blocco era stato progettato per prevenire.

I blocchi transazionali sono progettati per essere rilasciati dopo l'interruzione delle transazioni. Le versioni precedenti della documentazione di ownCloud descrivono anche un meccanismo di time-to-live (TTL) per i blocchi, in modo che i vecchi blocchi possano essere eliminati automaticamente. Poiché i dettagli di configurazione esatti possono variare a seconda della versione di ownCloud, verifica l'opzione nella documentazione corrispondente alla versione installata prima di modificarla. Non impostare un TTL estremamente breve solo per nascondere un problema di lentezza dello storage o del database.

Se i metadati stessi sono incoerenti, ownCloud fornisce comandi di scansione dei file orientati alla riparazione. La documentazione ufficiale del comando occ raccomanda di eseguire un backup del database prima di una scansione di riparazione. Una scansione di riparazione è indicata per i metadati dei file danneggiati o incoerenti; non è la soluzione di prima linea per i normali conflitti di blocco.

Non confondere il blocco transazionale con il blocco manuale dei file.

La documentazione attuale di ownCloud 11 afferma che il blocco manuale dei file è disabilitato per impostazione predefinita nell'interfaccia web. Quando è abilitato, il blocco tramite interfaccia web ha una durata predefinita di 30 minuti e un valore massimo predefinito di 24 ore. Questi valori sono documentati nella guida al blocco manuale dei file .

Se il problema riguarda specificamente un blocco manuale creato dall'utente, allora comandi come questi sono pertinenti:

docker compose exec owncloud occ config:app:set files lock_timeout_default --value 1800
docker compose exec owncloud occ config:app:set files lock_timeout_max --value 86400

Se il problema è un timeout interno durante la sincronizzazione o il salvataggio di un file, la modifica di questi valori di blocco manuale di solito non è la soluzione giusta.

Errori comuni che peggiorano i timeout di blocco

Eliminazione delle righe di blocco dal database mentre ownCloud è attivo

Questo può entrare in conflitto con le richieste in tempo reale e può rimuovere blocchi validi. Inoltre, tratta il sintomo senza correggere la configurazione del database o di Redis che ha causato il timeout.

Disabilitazione del blocco dei file transazionali

Il blocco transazionale serve a proteggere le operazioni sui file da modifiche simultanee. Mantienilo attivo e ripara il backend.

Utilizzo di APCu per il blocco condiviso in un cluster

APCu è una cache locale per nodo. È adatta per la memorizzazione nella cache locale, ma non fornisce uno stato di blocco condiviso tra più server applicativi. Per le cache distribuite e con blocco in implementazioni cluster, utilizzare Redis condiviso.

Eseguire un'istanza Redis per ogni nodo dell'applicazione.

Ciò significa che ogni server ha una visione diversa dei blocchi dei file. Tutti i nodi necessitano dello stesso servizio Redis condiviso per il coordinamento dei blocchi.

Aumento del tempo di attesa per il blocco del database senza risolvere il problema della contesa

Un timeout del database più lungo potrebbe solo far aspettare di più gli utenti. Spostare il traffico dei blocchi transazionali su Redis riduce il carico di lavoro di blocco del database e risolve il collo di bottiglia architetturale.

Rendere irrealisticamente breve la scadenza del blocco

Un'operazione lenta su un dispositivo di archiviazione esterno o un caricamento di grandi dimensioni possono legittimamente richiedere del tempo. La scadenza prematura del blocco può consentire a un'altra richiesta di modificare la stessa risorsa contemporaneamente.

Lista di controllo rapida per la risoluzione dei problemi

• Confermare che l'errore riguarda il blocco transazionale e non un blocco manuale creato dall'utente.
• Controlla i log di ownCloud, PHP, del database e di Redis intorno allo stesso orario.
• Verifica che Redis sia raggiungibile dal runtime di ownCloud, e non solo dalla tua shell.
• Imposta memcache.lockingsu \OC\Memcache\Redis.
• Mantieni filelocking.enabledattivo.
• In un cluster, configura ogni nodo in modo che punti alla stessa istanza di Redis.
• Riprova la sincronizzazione, il caricamento o lo spostamento originali monitorando i log.
• Utilizzate le scansioni di ripristino o le modifiche alla scadenza dei blocchi solo quando le prove indicano danni ai metadati o blocchi obsoleti.

In conclusione

La soluzione più affidabile per gli errori di timeout del blocco dei file di ownCloud non è rimuovere i blocchi o aumentare valori di timeout arbitrari. Inizia identificando se l'errore deriva dal blocco transazionale, quindi sposta il carico di lavoro di blocco su Redis e assicurati che ogni nodo di ownCloud veda la stessa istanza di Redis. Ripeti l'operazione esatta che ha causato l'errore e, se i blocchi rimangono attivi troppo a lungo, indaga sulla latenza del database o dello storage.

Questo approccio segue la documentazione attuale di ownCloud: il blocco transazionale dei file rimane abilitato, Redis gestisce lo stato di blocco condiviso e le impostazioni di timeout per il blocco manuale dei file sono trattate come una funzionalità separata piuttosto che come una soluzione universale per il timeout di blocco.