Linux: il montaggio CIFS / Samba si blocca per alcuni minuti

Ho una piccola rete locale che ha una scatola Gentoo e una scatola di Windows. Montare una condivisione originata dalla finestra di Windows sulla casella Gentoo con un comando come:

mount -t cifs -o username=WindowsUsername,password=thepassword,uid=pistos //192.168.0.103/Users /mnt/windowsbox

Il più delle volte, tutto funziona e posso leggere e scrivere senza problemi. Tuttavia, ogni poche settimane circa, la connessione o il punto di montaggio sembrano interrompersi o bloccarsi, in modo tale che qualsiasi processo che tenta di accedere al punto di montaggio rimanga bloccato nello stato D (disco o attesa I / O). Questi processi diventano impermeabili ai segnali TERM e KILL. Scollegare e ricollegare la scatola di Windows dalla rete non aiuta. Lo stato congelato dura 5+ minuti. È davvero frustrante e si intromette nel normale lavoro, perché congela i dialoghi, i lscomandi, ecc. Salva come se si genera un umountpunto di montaggio, si blocca o segnala che il punto di montaggio è in uso. Alla fine, lo stato morto si risolve da solo e il punto di montaggio viene smontato, o diventa possibile farlo umountsenza ritardo.

La mia ipotesi è che ciò avvenga quando la connessione / mount è inattiva o quando la macchina Windows è stata inattiva. Non ne sono davvero sicuro.

Perché sta succedendo questo e cosa posso fare per impedirlo? O come posso uccidere con successo questi processi di stato D a volontà?

Possibilmente correlato: i supporti CIFS si bloccano in lettura

linux cifs

— pistos
fonte

C'è qualche tipo di firewall in uso tra le due macchine?

— Schrute,

@Schrute: suppongo che qualsiasi impostazione predefinita sia su Linux (iptables?) E che Windows sia in esecuzione. Pensi che i firewall stiano scadendo le connessioni? Non avevo mai sentito parlare di una cosa del genere.

— Pistos,

Penso che questo potrebbe essere un problema della scatola di Linux. Ho visto un problema simile - non con cifs e Windows - ma con una condivisione nfs montata. Il salvataggio non è stato possibile - immagino che a causa di qualche processo sospeso durante l'accesso al server nfs inesistente. Questo di solito accade quando si verifica un arresto anomalo del server.

— cornelinux,

Il mio consiglio è di impostare una cattura di rete ring-buffer sulla macchina linux (cioè tcpdump -i eth0 -C 5 -W 10 -s 0 -v -w /tmp/cifs.pcap host 192.168.0.103 - Avrei anche eseguito sotto lo schermo per impedire il termine del processo quando ci si disconnette). Quando si verifica il problema, arrestare la traccia dopo alcuni secondi e si dovrebbe almeno essere in grado di determinare quale lato sta causando il problema quando si esamina la traccia del pacchetto (ovvero il server smette di rispondere, la sessione viene disconnessa ecc.).

— GeekyDeaks,

@Pistos - Wireshark è tuo amico! Le tracce possono sembrare confuse, ma WireShark decodificherà i frame per aiutare. Vuoi prima eliminare le nozioni di base, come il server o il client che rilascia la sessione (pacchetti FIN), quindi passare ad altri come il server smette di rispondere ecc. Se hai tempo c'è stato un video di Sharkfest su CIFS nel 2013 ( youtube.com/watch ? v = XbvFXSPig-w ) ma è piuttosto lungo :)

— GeekyDeaks

Risposte:

Non sei sicuro del motivo per cui si sta verificando il problema, ma come soluzione alternativa, hai provato a mettere qualcosa di simile touch /mnt/windowsbox/keepalive.txto echo "I am still alive." >/mnt/windowsbox/keepalive.txtad essere eseguito tramite cron ogni minuto? In questo modo la connessione dovrebbe rimanere attiva.

— Janne Pikkarainen
fonte

Buona idea. L'ho messo in atto e vedrò cosa succede.

— Pistos,

Questo sembra aver risolto il problema, dovrei menzionarlo.

— Pistos

Fantastico sentirlo!

— Janne Pikkarainen,

secondo la risposta di @ Pat, si potrebbe tagliare questo da un battito cardiaco ogni minuto a un battito cardiaco ogni 5 minuti (300 secondi), che sarebbe */5 * * * *nel programma crontab

— woodvi

Sto usando questo per ora. Entro 3 giorni, ho avuto tre macchine LTS Ubuntu Server 16 separate (due fisiche, una VM) che hanno lasciato cadere le loro connessioni SMB dopo poche ore dal riavvio. All'avvio, la connessione SMB viene montata senza problemi, ma alla fine non risponde.

— user38537,

Anch'io lo incontro ogni pochi mesi. sudo umount -lè la mia soluzione alternativa. /programming//a/96288/2097284

— Camille Goudeseune
fonte

Un'altra potenziale risposta ha suggerito di scrivere su un file sul mount a intervalli regolari tramite cron. Suggerirei invece di utilizzare il programma smbclient per connettersi alla condivisione e disconnettersi.

Ho scritto uno script bash come questo per ottenere ciò:

#!/bin/bash

su usernamehere -c "smbclient \\\\\\\\\\\\\\\\servernamehere\\\\\\\\sharenamehere passwordhere -c exit" >/dev/null 2>&1

Questo comando stabilisce una nuova connessione alla condivisione e quindi esegue il comando exit, chiudendo immediatamente la connessione appena stabilita sulla riga comandi. Dovrebbero esserci 8 barre prima del nome del server e 4 prima del nome della condivisione, poiché è necessario eseguire l'escape delle barre rovesciate e le escape devono essere salvate all'interno di una stringa tra virgolette doppie. Forse c'è un modo più intelligente per farlo, ma sembra funzionare.

Forse c'è un modo per renderlo ancora più affidabile rendendolo aperto per diversi minuti alla volta, ma è un po 'fuori dalla mia portata.

— RedScourge
fonte

Proposta interessante. Ci proverei se non avessi già avuto successo con l'altra soluzione.

— Pistos,

Non vedo come questo sarebbe utile? La soluzione di Janne sarebbe quella di mantenere viva la connessione stabilita dal client cifs, mentre ciò creerebbe una nuova connessione non correlata con il client smb - quindi come sarebbe d'aiuto?

— flungo,

Cordiali saluti, smbclient supporta le barre in avanti se si desidera utilizzarle anziché le barre rovesciate, quindi //servername/sharnameè molto più facile nei luoghi in cui è necessario un sacco di escape.

— Steve Friedl,