Come risolvere l’errore di comunicazione con snapd.socket su Linux

Quando snapd.socket smette di rispondere

Su Linux, l’errore di comunicazione con snapd.socket di solito non è un problema “di snap” in senso astratto: è quasi sempre un guasto nel livello di attivazione socket, nel demone snapd, nei permessi del socket Unix, oppure un effetto collaterale di servizi mancanti, filesystem pieno o policy di sicurezza troppo strette. Il punto non è riavviare alla cieca, ma capire dove si interrompe il flusso tra client, socket e demone.

Il comportamento atteso è semplice: il socket /run/snapd.socket deve accettare connessioni locali e attivare snapd.service quando serve. Quello osservato, nei casi rotti, è uno di questi tre scenari: il socket non esiste, esiste ma non si ascolta, oppure il socket ascolta ma il demone fallisce subito dopo l’attivazione. Cambia il sintomo, ma la diagnostica iniziale è la stessa.

Prima distinzione: socket rotto o demone rotto?

La prima verifica serve a separare il problema di trasporto dal problema applicativo. Se il socket è sano, il client snap riceve una risposta o almeno arriva al demone; se il socket è guasto, il fallimento è immediato e locale. Questa distinzione evita di perdere tempo su configurazioni di snap quando il problema è più banale, come un mount in sola lettura o un’unità systemd disabilitata.

1. Verifica lo stato delle unità:

   systemctl status snapd.socket snapd.service --no-pager

   Atteso: snapd.socket in stato listening o active (running), e snapd.service che parte su richiesta o è già attivo. KO tipico: failed, inactive (dead), oppure messaggi di bind sul socket.

2. Controlla se il socket esiste davvero:

   ls -l /run/snapd.socket /run/snapd-snap.socket 2>/dev/null

   Atteso: almeno /run/snapd.socket presente con tipo socket. Se manca, il problema è prima ancora di Snap: runtime directory non creata, unità non partita, o errore di avvio del servizio.

3. Guarda i log più recenti:

   journalctl -u snapd.socket -u snapd.service -b --no-pager -n 100

   Atteso: nessun errore ripetuto di bind, permission denied, filesystem read-only, o crash loop del demone. Se trovi cannot create socket, permission denied o read-only file system, hai già una pista concreta.

Cause più probabili, in ordine pratico

In produzione o su una macchina amministrata male, le cause ricorrenti sono poche. Ordinarle per probabilità aiuta a fare una correzione minima e reversibile, invece di toccare metà sistema per inseguire un messaggio generico.

1. snapd non parte o crasha subito. Il socket resta presente, ma l’attivazione fallisce perché il servizio si chiude per errore interno, dipendenza mancante o filesystem non scrivibile.

2. problema sul socket systemd. L’unità snapd.socket è disabilitata, mascherata, o ha un conflitto con un altro processo che occupa la porta o il path Unix.

3. conflitto ambientale. Disco pieno, /run non montato correttamente, policy AppArmor/Selinux troppo restrittiva, oppure update interrotto che ha lasciato pacchetti e unità in stato incoerente.

La falsificazione rapida, entro cinque minuti, è semplice: se systemctl start snapd.service fallisce con errore esplicito, la causa è il demone o l’ambiente; se invece il servizio parte ma i client continuano a dire che non riescono a comunicare, allora il problema è più spesso nel socket o nei permessi sul path di comunicazione.

Verifiche immediate che non sporcano il sistema

1. Verifica la presenza del pacchetto e della versione:

   snap version

   Atteso: output con versioni di snap, snapd e del kernel. Se il comando non risponde o segnala errore di connessione a snapd, non significa ancora che il client sia rotto: significa che il canale di controllo non è disponibile.

2. Controlla se il socket è in ascolto:

   ss -xlpn | grep snapd

   Atteso: una riga che mostri /run/snapd.socket con systemd come processo proprietario. Se non compare nulla, l’unità socket non è attiva o non ha creato il file.

3. Esamina i dettagli dell’unità:

   systemctl cat snapd.socket
   systemctl cat snapd.service

   Atteso: un’unità standard senza override sospetti. Se trovi drop-in in /etc/systemd/system/snapd.socket.d/ o /etc/systemd/system/snapd.service.d/, trattali come candidato forte: basta poco per rompere un socket activation.

4. Controlla lo spazio disponibile:

   df -h /
   df -h /run

   Atteso: margine sufficiente. Un root filesystem pieno o una /run anomala può impedire la creazione dei socket e dei file runtime.

5. Guarda se il sistema ha segnali di OOM o kill del demone:

   journalctl -k -b --no-pager | grep -Ei 'oom|killed process|out of memory'

   Atteso: nessun kill recente di snapd. Se c’è, la comunicazione fallisce per effetto secondario e non per guasto logico del socket.

Ripristino controllato: procedura minima e reversibile

Qui l’obiettivo non è “aggiustare tutto”, ma riportare il canale di comunicazione in uno stato sano con il minor blast radius possibile. Le azioni sotto non toccano dati utente e, se eseguite nell’ordine giusto, sono reversibili con un semplice rollback dell’unità o del pacchetto.

1. Ricarica systemd e riattiva il socket:

   sudo systemctl daemon-reload
   sudo systemctl enable --now snapd.socket

   Verifica: systemctl status snapd.socket --no-pager deve mostrare active (listening). Se fallisce, non andare oltre finché non hai il motivo nel journal.

2. Avvia il demone manualmente per isolare l’errore:

   sudo systemctl restart snapd.service
   sudo systemctl status snapd.service --no-pager

   Verifica: il servizio deve restare attivo. Se passa a failed, leggi subito journalctl -u snapd.service -b --no-pager -n 50 per il messaggio esatto.

3. Se il servizio non parte per errore di runtime, controlla i log applicativi di snapd:

   journalctl -u snapd.service -b --no-pager | tail -n 100

   Verifica: cerca errori su mount, permessi, database interno o AppArmor. Un singolo errore ripetuto è più utile di dieci riavvii.

4. Se il socket è presente ma i client non comunicano, prova a forzare un test minimale:

   sudo snap list

   Verifica: una lista di snap installati o, in caso di errore, un messaggio coerente. Se il comando resta in timeout, il problema è quasi certamente sull’attivazione o sul demone bloccato.

5. Se hai trovato un override locale, disabilitalo temporaneamente con backup del file:

   sudo mkdir -p /root/backup-snapd-systemd
   sudo cp -a /etc/systemd/system/snapd.socket.d /root/backup-snapd-systemd/ 2>/dev/null || true
   sudo cp -a /etc/systemd/system/snapd.service.d /root/backup-snapd-systemd/ 2>/dev/null || true

   Poi rimuovi solo il drop-in sospetto e ricarica systemd. Blast radius: limitato al comportamento di snapd. Rollback: ripristini i file dal backup e rifai systemctl daemon-reload.

Se il problema è legato a un aggiornamento interrotto, spesso basta completare o riparare la transazione del pacchetto. Su Debian/Ubuntu, ad esempio, verifica lo stato dei pacchetti prima di intervenire:

dpkg -l | grep -E '^ii|^iU|^rc' | grep snapd

Se vedi stati incoerenti, la correzione tipica è una reinstallazione controllata del pacchetto, non una rimozione aggressiva. Prima verifica la disponibilità di rete e repository, poi esegui l’operazione solo se serve davvero.

Quando il problema è nel filesystem o nei permessi

Molti casi di “comunicazione impossibile” sono in realtà errori di scrittura su filesystem. Snapd usa file runtime e directory di stato che devono essere accessibili, e un mount in sola lettura manda tutto in crisi. Non è raro trovarsi davanti a un server che sembra sano ma ha il root filesystem degradato dopo un crash o una corruzione lieve.

1. Controlla se il filesystem è read-only:

   mount | grep ' on / '
   findmnt -no OPTIONS /

   Atteso: niente opzione ro. Se c’è ro, il fix non è su snapd: devi risolvere il problema del mount, poi riavviare il servizio.

2. Verifica i permessi del runtime directory:

   ls -ld /run /run/snapd* /var/lib/snapd

   Atteso: ownership e permessi coerenti con i servizi di sistema. Se trovi permessi strani o owner inattesi, c’è probabilmente stato un intervento manuale o un restore incompleto.

3. Controlla eventuali errori di AppArmor o Selinux:

   journalctl -k -b --no-pager | grep -Ei 'apparmor|selinux|denied'

   Atteso: nessuna denial correlata a snapd. Se ci sono denial, il problema è di policy e non di rete o socket.

Se il client snap restituisce timeout o handshake fallito

Quando il messaggio parla di timeout, la tentazione è pensare alla rete. In questo caso, però, la rete non c’entra quasi mai: il canale è locale, via socket Unix. Il timeout indica spesso che il client aspetta una risposta dal demone che non arriva, perché snapd è bloccato in avvio, in deadlock, o sta fallendo ripetutamente.

1. Verifica se il processo esiste e consuma CPU o memoria in modo anomalo:

   ps -eo pid,ppid,stat,pcpu,pmem,cmd | grep '[s]napd'

   Atteso: un processo snapd vivo e stabile. Se vedi restart continui o stato D/R anomalo, il problema è nel demone o nelle sue dipendenze.

2. Controlla i journal con timestamp recenti:

   journalctl -u snapd.service --since '15 min ago' --no-pager

   Atteso: un evento chiaro vicino al momento del guasto. Se non c’è nulla, la causa può essere precedente o il servizio non è proprio partito.

3. Se il demone è in crash loop, valuta un riavvio pulito del nodo solo dopo aver salvato i log utili:

   sudo journalctl -u snapd.service -b --no-pager > /root/snapd-service.log

   Poi esegui un restart controllato. Rollback: il file di log salvato ti consente di confrontare il comportamento prima e dopo senza perdere evidenza.

Riparazione strutturale: cosa correggere per non rivedere l’errore

Una volta ripristinato il servizio, conviene chiudere la causa radice. Se lasci solo il riavvio, il problema tornerà al prossimo reboot, al prossimo update o al prossimo evento di saturazione disco.

1. Se hai trovato spazio disco insufficiente, imposta un controllo periodico su root e su /var. Un semplice alert su soglia bassa evita che snapd sia il primo sintomo visibile di un problema più ampio.

2. Se il guasto deriva da un upgrade incompleto, allinea la gestione pacchetti con una finestra di manutenzione e verifica che snapd non venga bloccato da hold o da repository non raggiungibili.

3. Se il problema è legato a una policy di sicurezza, documenta l’eccezione minima necessaria invece di allargare permessi in modo permanente. Meglio una regola mirata che un abbassamento generalizzato del profilo di confinamento.

4. Se trovi override systemd, versionali come configurazione applicativa. Un file in /etc/systemd/system/ senza tracciamento è una futura interruzione annunciata.

Controlli finali e rollback

La verifica finale deve confermare tre cose: il socket ascolta, il demone resta vivo, e i comandi snap tornano a rispondere. Solo a quel punto il problema può dirsi chiuso operativamente.

1. Conferma lo stato delle unità:

   systemctl is-active snapd.socket snapd.service

   Atteso: entrambe le unità restituiscono active oppure active/listening coerente con il tipo di unità.

2. Riprova un comando snap semplice:

   snap list

   Atteso: output normale senza timeout né errori di connessione.

3. Controlla che non ci siano nuovi errori nel journal dopo la prova:

   journalctl -u snapd.socket -u snapd.service -b --no-pager -n 30

   Atteso: assenza di nuovi messaggi di errore o restart ripetuti.

4. Se hai modificato drop-in o file di unità e il problema persiste, fai rollback ripristinando i backup salvati e ricaricando systemd:

   sudo cp -a /root/backup-snapd-systemd/* /etc/systemd/system/ 2>/dev/null || true
   sudo systemctl daemon-reload
   sudo systemctl restart snapd.socket snapd.service

   Rollback: reversibile finché conservi i file originali. Blast radius: limitato a snapd e alle sue unità.

Assunzione operativa: il server è Linux recente con systemd, e l’errore riguarda la comunicazione locale con snapd, non un problema di rete esterna o di DNS.

Se snapd.socket non comunica, la domanda giusta non è “come lo riavvio?”, ma “in quale punto del percorso socket → demone → filesystem si sta rompendo la catena?”.

Questa è la differenza tra un ripristino veloce e una toppa che ti lascia lo stesso guasto alla prima occasione utile.