Home
» UFFICIO MS
»
Come eseguire il debug dei log di connessione di Collabora Online con il livello di log coolwsd
Come eseguire il debug dei log di connessione di Collabora Online con il livello di log coolwsd
Il modello di configurazione pubblico corrente di Collabora Online espone ancora logging.levelin coolwsd.xml, con valori supportati che vanno da warninga debuge trace. In caso di errore di connessione, aumentare brevemente il livello, riprodurre una connessione non riuscita, esaminare la destinazione effettiva del log del servizio e ripristinare il livello normale al termine. Il valore mostrato nel file XML non è sempre il valore effettivo: un comando di avvio o un'impostazione del container possono sovrascriverlo e le aree ad alta verbosità, come la registrazione WebSocket, possono essere disabilitate separatamente.
Questa guida si concentra sulla diagnosi di un errore di connessione tra il browser e Collabora o di un problema di apertura di un documento. Utilizza il coolwsd.xml.inmodello sorgente pubblico corrente e il materiale ufficiale di Collabora, verificato il 6 ottobre 2026. Le impostazioni predefinite dei pacchetti e i nomi dei servizi possono variare a seconda della versione e dell'implementazione, quindi verifica l'istanza in esecuzione prima di copiare i percorsi o eseguire i comandi di riavvio.
Quali sono le modifiche al livello di log di coolwsd?
coolwsdè il demone WebSocket di Collabora Online, il processo server che gestisce le sessioni del browser e l'attività sui documenti. Il suo livello di log determina quanti dettagli vengono emessi dal processo. Il modello di origine corrente elenca i livelli denominati, tra cui fatal, critical, error, warning, notice, information, debuge trace, nonché i livelli numerici da 0 a 8. I valori numerici vanno dal meno al più dettagliato. Per una prima analisi diagnostica, debugè un buon punto di partenza; utilizzare tracesolo quando sono necessari dettagli di connessione più precisi.
L' level_startupimpostazione separata controlla la registrazione durante l'avvio iniziale, dopodiché la registrazione torna al livello specificato level. Il modello corrente imposta la registrazione all'avvio su trace; ciò non significa che il normale funzionamento rimanga a livello di traccia. Evitare di modificare l'impostazione level_startupquando il problema si verifica dopo che il servizio è già in esecuzione.
Un output più dettagliato può aumentare il volume dei log e includere URL, indirizzi, identificativi di sessione o altri dettagli operativi. Trattate i log come informazioni sensibili; raccogliete solo i dati relativi all'intervallo di tempo necessario e oscurate le informazioni riservate prima di condividerli.
Passaggio 1: Identificare come viene eseguita questa istanza di Collabora
Innanzitutto, verifica se Collabora Online viene eseguito come servizio di sistema, in Docker o Podman, oppure in Kubernetes. Questo è importante perché la modifica di un file all'interno di un container in esecuzione potrebbe non essere permanente e i log del container potrebbero essere scritti sull'output standard anziché su un file.
Pacchetto di sistema: verificare il servizio in esecuzione e il nome della sua unità, solitamente coolwsd. La configurazione è solitamente /etc/coolwsd/coolwsd.xml. Le versioni precedenti potrebbero utilizzare un loolwsdpercorso legacy.
Docker o Podman: identifica il nome del container e come viene fornita la sua configurazione. Un file montato tramite bind o una variabile di distribuzione sono solitamente la fonte persistente della configurazione.
Kubernetes: ispeziona i valori Helm, ConfigMap o il manifesto di distribuzione che fornisce coolwsd.xml. La modifica diretta di un pod è temporanea.
L'attuale modello di configurazione pubblico mostra valori separati per la registrazione normale e per la fase di avvio iniziale.
Prima di apportare modifiche, esegui un backup del file di configurazione effettivo o salva una copia dei valori di distribuzione. Se non sei sicuro di quale file venga letto dal processo in esecuzione, controlla prima la definizione del servizio o il comando di avvio. Una causa comune di un'apparente inattività è la modifica di un file di esempio anziché della configurazione attiva.
Passaggio 2: Aumentare temporaneamente il livello attivo
Nella sezione attiva coolwsd.xml, individua la <logging>sezione e modifica solo il valore al suo interno <level>. Inizia con debug. Se il tentativo di connessione non produce ancora dettagli sufficienti, usa brevemente traceper una riproduzione. Mantieni level_startupinvariate le impostazioni dei file e le configurazioni non correlate esistenti.
Utilizzare la traccia temporaneamente quando il debug non mostra dettagli sufficienti; conservare le impostazioni di avvio e le altre opzioni XML.
Questo è un esempio abbreviato della struttura XML pertinente, non un sostituto del file di configurazione completo. Per le distribuzioni in container, impostare l'opzione tramite il meccanismo persistente supportato da tale immagine o grafico. Il codice sorgente ufficiale di Collabora include override di configurazione da riga di comando, quindi se il valore sembra ignorato, verificare gli argomenti di avvio o i parametri di distribuzione per un secondo logging.levelvalore.
Se i log vengono scritti su un file, il modello di origine corrente documenta il percorso del file in logging.file, solitamente /var/log/coolwsd.log. La registrazione su file potrebbe essere disabilitata in una build di produzione. Se si abilita l'output su file o si utilizza un percorso personalizzato, verificare che l' coolaccount di servizio abbia i permessi di scrittura in quella posizione e che systemd consenta al servizio di scrivere in tale posizione. Non rendere il file di log leggibile da tutti per risolvere un problema di permessi.
Passaggio 3: riavviare o ridistribuire, quindi riprodurre una volta
La maggior parte delle configurazioni predefinite entra in vigore dopo il riavvio del servizio. Riavviare durante un'apposita finestra di manutenzione o un'istanza di test, poiché le sessioni di modifica attive potrebbero essere interrotte. Per un servizio systemd, un comando tipico è:
sudo systemctl restart coolwsd
sudo systemctl status coolwsd --no-pager
Utilizza il nome effettivo del servizio sul tuo host. Per un container, aggiorna la configurazione persistente e riavvia o ridistribuisci il container. Per Kubernetes, applica la modifica al manifest o a Helm tramite il normale processo di rilascio. Verifica che il processo si avvii correttamente prima di riprodurre il problema.
Registra l'ora esatta, l'utente interessato o l'account di test, la fase di apertura del documento e l'errore visibile nel browser. Riproduci l'errore una sola volta, quindi interrompi la generazione di richieste. Un singolo tentativo con timestamp è più facile da correlare tra Collabora, il proxy inverso e l'host di archiviazione o WOPI rispetto a una lunga serie di sessioni non correlate.
Passaggio 4: Leggi il file di log relativo alla tua distribuzione.
Per un servizio systemd, segui il registro degli eventi mentre riproduci il problema:
sudo journalctl -u coolwsd -f
Per ispezionare una finestra temporale recente delimitata, utilizzare sudo journalctl -u coolwsd --since "10 minutes ago". Se l'unità ha un nome diverso, sostituirlo. Per Docker, utilizzare docker logs --since 10m --follow CONTAINER_NAMEe sostituire CONTAINER_NAMEcon il nome o l'ID effettivo del container. Podman e Kubernetes hanno i propri comandi di log; consultare la documentazione di runtime del deployment anziché presumere l'esistenza di un file host.
Leggi dal log sink attivo; il testo container-name nel comando Docker è un segnaposto da sostituire con il tuo container effettivo.
Se la registrazione dei file è abilitata, controlla il percorso configurato, ad esempio sudo tail -F /var/log/coolwsd.log. Il percorso nel tuo file potrebbe essere diverso. Un file mancante non significa di per sé che il servizio non abbia prodotto log; potrebbe invece scrivere nel journal o nell'output del container.
Passaggio 5: Correlare la sequenza di connessione
Inizia con le voci al timestamp registrato. Cerca indicatori di avviso ed errore e termini relativi alla connessione come WOPI, WebSocket, Socket, o il percorso della richiesta pertinente. In un file, un primo filtro mirato può essere:
Seguite quindi la sequenza: il browser ha raggiunto l'URL pubblico? Il proxy inverso ha inoltrato la richiesta? L'aggiornamento WebSocket è stato completato? Collabora ha contattato l'host del documento? I log di accesso e di errore di un proxy possono rispondere a domande a cui il log di coolwsd non può rispondere, come ad esempio se la richiesta ha effettivamente raggiunto il servizio. Se il browser segnala un errore di connessione WebSocket ma coolwsd non registra alcuna richiesta corrispondente, prima di modificare le autorizzazioni del documento, verificate DNS, terminazione TLS, regole del firewall e routing del proxy inverso.
Il modello di configurazione corrente elenca Socket, WebSocket, Admin, e Pixeltra le opzioni predefinite disabled_areasper l'output dettagliato. Se la registrazione delle tracce è attiva ma mancano i dettagli del socket, esaminare questa impostazione. Per una breve diagnostica, rimuovere solo l' area Socketo pertinente WebSocketdall'elenco di elementi disabilitati separati da virgole, mantenendo intatte le esclusioni non correlate. Riavviare o ridistribuire e ripetere lo stesso test controllato. Ripristinare l'elenco originale dopo aver raccolto le prove.
Passaggio 6: Ripristinare la registrazione normale e proteggere le prove
Riportare <level>al valore di produzione precedente, solitamente warningnel modello sorgente pubblico, e ripristinare eventuali modifiche disabled_areas. Riavviare o ridistribuire nuovamente se richiesto dal processo di packaging. Verificare che il servizio sia integro e che non vengano più visualizzati nuovi messaggi di debug o di traccia. Conservare in una posizione con accesso limitato solo l'estratto diagnostico a tempo limitato.
Ripristina il livello di log normale dopo il test, quindi esamina un estratto ristretto e pertinente anziché condividere un dump completo del log.
Prima di inviare un estratto del registro al supporto di Collabora o a un amministratore, rimuovere, ove possibile, token di accesso, intestazioni di autorizzazione, URL firmati, nomi utente, nomi host privati e nomi dei documenti. Conservare i timestamp e il contesto di errore non sensibile necessario per riprodurre la sequenza.
Errori comuni durante il debug
Modifica solo level_startup: questa impostazione si applica alla fase di avvio iniziale e poi torna a level. In caso di errore dopo l'avvio, modificare level.
Presupponendo che tracetutte le categorie siano abilitate: le aree disabilitate possono sopprimere i messaggi socket o WebSocket ad alta verbosità. Consultare l'elenco dei filtri.
Cercare nel posto sbagliato: il registro di sistema, l'output del container e un file sono destinazioni di log diverse. Prima di tentare di risolvere un problema con un file vuoto, è necessario determinare quale sia quella attiva.
Lasciare la traccia abilitata: la registrazione di grandi volumi di dati può crescere rapidamente ed esporre maggiori dettagli operativi. Ripristinare il valore precedente non appena il test è completato.
Modificando più impostazioni contemporaneamente, diventa più difficile identificare quale impostazione abbia influenzato il risultato. Regola un valore, riproduci l'errore e registra l'esito.