Può bash uscire dalla sincronizzazione con il filesystem?

12

Potrei non formulare correttamente la mia domanda, ma farò del mio meglio per spiegare i sintomi che sto vivendo. Innanzitutto, per il contesto, eseguo un server Ubuntu (senza interfaccia grafica), versione 12.04.3 LTS (secondo l'utilità lsb_release). Generalmente faccio tutto il mio lavoro su tmux, mi collego al server tramite Putty e uso vim per tutto il mio editing di testo.

Ora per i sintomi. Dato che uso tmux, di solito ho sempre alcune finestre aperte. Uno di questi ospita un server di nodi con cui ho giocato, e vive in una sottodirectory della home del mio account utente (in particolare, ~/battleship ). Il server interagisce con una pagina Web che sto ospitando al di fuori del server utilizzando nginx, e tutto il codice del sito web vive in /usr/share/nginx/www/bs (tengo anche una finestra separata aperta per modificare l'origine del client). Quello che succede è che dopo diverse ore di lasciare la finestra del server inattiva e intatta, sembra non essere sincronizzata. Posso eseguire ls e vedere i file, e posso aprirli per la modifica ( vim server.js ). Quando lo faccio, comunque, a prescindere dal fatto che apporti modifiche o salvi o esco immediatamente, quando eseguo di nuovo ls vedo un file .server.js.swp e nessuna delle mie modifiche (se ne ho fatte) persistere. Se esco da quella directory e poi di nuovo, si risolve da solo: posso aprire il file e modificarlo correttamente, senza lasciare indietro un file .swp quando lo chiudo. Ho menzionato la fonte del client per metà delle cose perché ho notato che questo non si verifica nella cartella / www (presumibilmente perché è al di fuori della home directory del mio account utente).

Dopo quel muro di testo, la mia domanda è questa: qualcuno sa perché sta succedendo e come prevenirlo? Posso solo immaginare che ci sia un modo, visto che questo non è l'unico server Linux a cui mi collego tramite Putty e uso tmux / vim on, eppure è l'unico in cui questo strano comportamento accade. Qualsiasi aiuto sarebbe apprezzato.

Nota: l'ho taggato con bash, tmux e stucco perché presumo che uno di questi sia la colpa, ma non ho idea di quale sia.

Aggiornamento: Questo è l'output di cat /proc/mount come richiesto da Gilles (anche se con il mio nome utente e i valori di ecryptfs_fnek_sig e ecryptfs_sig censurati, perché mentre io in realtà non lo so quali sono queste due cose, sembrano legate alla crittografia e meglio al sicuro che dispiaciute.

rootfs / rootfs rw 0 0
sysfs /sys sysfs rw,nosuid,nodev,noexec,relatime 0 0
proc /proc proc rw,nosuid,nodev,noexec,relatime 0 0
udev /dev devtmpfs rw,relatime,size=2008532k,nr_inodes=502133,mode=755 0 0
devpts /dev/pts devpts rw,nosuid,noexec,relatime,gid=5,mode=620,ptmxmode=000 0 0
tmpfs /run tmpfs rw,nosuid,relatime,size=807840k,mode=755 0 0
/dev/disk/by-uuid/2da27263-f079-47ba-90ad-66e4c3a53810 / ext4 rw,relatime,errors=remount-ro,data=ordered 0 0
none /sys/fs/fuse/connections fusectl rw,relatime 0 0
none /sys/kernel/debug debugfs rw,relatime 0 0
none /sys/kernel/security securityfs rw,relatime 0 0
none /run/lock tmpfs rw,nosuid,nodev,noexec,relatime,size=5120k 0 0
none /run/shm tmpfs rw,nosuid,nodev,relatime 0 0
/home/[username]/.Private /home/[username] ecryptfs rw,relatime,ecryptfs_fnek_sig=[censored],ecryptfs_sig=[censored],ecryptfs_cipher=aes,ecryptfs_key_bytes=16,ecryptfs_unlink_sigs 0 0

Aggiornamento 2: Ecco l'output di uname -a :

Linux [server-name] 3.5.0-39-generic #60~precise1-Ubuntu SMP Wed Aug 14 15:38:41 UTC 2013 x86_64 x86_64 x86_64 GNU/Linux

Aggiornamento 3: Ho completato un passaggio di memtest. Questo è il risultato di detto test . Sembra aver completato senza errori, quindi non sono sicuro se finirà per aiutare con qualsiasi cosa. Puoi anche vedere alcuni dettagli hardware nel caso in cui ciò sia di aiuto in ogni modo.

    
posta Alex 06.09.2013 - 22:13
fonte

3 risposte

1

L'unica esperienza che ho visto con qualcosa del genere era quando una directory veniva rimossa e ne veniva creata una nuova. AIX e Solaris hanno avuto questo problema anni fa. Se hai una sessione di shell aperta in una directory rimossa, puoi ottenere risultati imprevedibili che assomigliano a un sistema di file che va fuori sincrono.

bash1: mkdir test1
bash2: cd test1
bash1: touch test1/testfile
bash1: ls test1
testfile
bash2: ls
testfile
bash1: rm -rf test1
bash2: ls
???(unknown results)???

Il file system crittografato suona anche come qualcosa da recensire. Hai provato in un file system non criptato?

Mi dispiace, non posso ancora postare commenti. Non abbastanza punti.

    
risposta data Michael McGarrah 18.03.2014 - 17:37
fonte
0

Potresti provare a eseguire il comando di sincronizzazione tra i tuoi comandi bash.

sync - flush file system buffers

Non ne ho mai sentito il bisogno, ma ho conosciuto almeno una persona che lo ha digitato praticamente come ogni secondo comando! Deve essere stato bruciato male in passato con il disco lento.

Internet sembra essere leggero nella discussione sull'uso del comando sync . Ecco un link alla voce manuale molto breve per sync : link

sync garantisce che i dati vengano scritti dalla memoria al dispositivo del disco. I dati potrebbero ancora essere nella memoria cache del dispositivo del disco e non scritti sul disco se il dispositivo stesso è lento o presenta un problema.

Stai utilizzando un server Ubuntu. . . è una macchina sul tuo desktop? O è in una nuvola? O . . . qualcos'altro? Vedere qui: link sincronizzazione lenta da memoria a disco associata a problemi del disco rigido O forse con Amazon AWS istanze più piccole.

    
risposta data gaoithe 23.03.2014 - 22:52
fonte
0

FWIW il problema è visualizzato dal comando ls, non da bash.

Il fatto che tu veda il file significa che è ancora lì. Niente è fuori sincrono con qualcos'altro e nessuna quantità di sincronizzazione in esecuzione ti impedirà di utilizzare l'unica copia cache dei dati del file system rilevanti. la sincronizzazione causerà l'archiviazione permanente dei dati, non la modifica della visualizzazione.

Stai usando le sessioni VIM? Non conosco la sessione VIM, non l'ho mai usata da sola, ma immagino che tmux possa far sì che il VI session manager non si accorga che il file è chiuso e per tenere traccia delle modifiche.

    
risposta data Johan 15.04.2014 - 15:11
fonte

Leggi altre domande sui tag