Kann bash nicht mehr mit dem Dateisystem synchronisiert werden?

Möglicherweise formuliere ich meine Frage nicht richtig, aber ich werde mein Bestes tun, um die Symptome zu erklären, die bei mir auftreten. Als erstes führe ich einen Ubuntu-Server (keine GUI) aus, Version 12.04.3 LTS (gemäß dem Dienstprogramm lsb_release). Im Allgemeinen arbeite ich in tmux, verbinde mich über Putty mit dem Server und verwende vim für die gesamte Textbearbeitung.

Nun zu den Symptomen. Da ich tmux benutze, sind normalerweise immer ein paar Fenster geöffnet. Einer von ihnen beherbergt einen Knotenserver, mit dem ich herumgespielt habe, und er befindet sich in einem Unterverzeichnis des Hauses meines Benutzerkontos (genauer gesagt ~/battleship). Der Server interagiert mit einer Webseite, die ich auch mit nginx vom Server aus hoste, und der gesamte Website-Code lebt darin /usr/share/nginx/www/bs(ich lasse auch ein separates Fenster zum Bearbeiten der Client-Quelle offen). Was passiert, ist, dass es nach mehreren Stunden, in denen das Serverfenster im Leerlauf und unberührt gelassen wurde, nicht mehr synchron zu sein scheint. Ich kann lsdie Dateien ausführen und anzeigen und sie zur Bearbeitung öffnen ( vim server.js). Dabei ist es jedoch unerheblich, ob ich Änderungen vornehme und speichere oder beim Ausführen sofort beendelsErneut wird eine .server.js.swp-Datei angezeigt, und keine meiner Änderungen (sofern ich sie vorgenommen habe) wird beibehalten. Wenn ich aus diesem Verzeichnis heraus und dann wieder hinein gehe, repariert es sich von selbst. Ich kann die Datei öffnen und erfolgreich bearbeiten, ohne eine .swp-Datei zu hinterlassen, wenn ich sie schließe. Ich habe die Client-Quelle zur Hälfte erwähnt, weil mir aufgefallen ist, dass dies nicht im Ordner / www geschieht (vermutlich, weil es sich außerhalb des Ausgangsverzeichnisses meines Benutzerkontos befindet).

Nach dieser Textwand lautet meine Frage: Weiß jemand, warum dies geschieht und wie dies verhindert werden kann? Ich kann mir nur vorstellen, dass es eine Möglichkeit gibt, wenn man bedenkt, dass dies nicht der einzige Linux-Server ist, zu dem ich über Putty eine Verbindung herstelle und auf dem tmux / vim verwendet wird. Jede Hilfe wäre dankbar.

Hinweis: Ich habe dies mit bash, tmux und putty getaggt, weil ich davon ausgehe, dass einer von ihnen schuld ist, aber ich habe wirklich keine Ahnung, welcher.

Update: Dies ist die Ausgabe von, cat /proc/mountwie von Gilles angefordert (obwohl mit meinem Benutzernamen und den Werten von ecryptfs_fnek_sigund ecryptfs_sigzensiert, weil ich eigentlich nicht weiß, was diese beiden Dinge sind, sie aber verschlüsselungsbedingt und besser sicher als leid sind).

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

Update 2: Hier ist die Ausgabe von 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

Update 3: Ich habe ein Memtest bestanden. Dies ist das Ergebnis dieses Tests . Scheint fehlerfrei abgeschlossen zu sein, daher bin ich mir nicht sicher, ob es irgendetwas helfen wird. Sie können auch einige Hardwaredetails anzeigen, falls dies in irgendeiner Weise hilfreich ist.

bash putty tmux

— Alex
quelle

Nein, bash kann nicht „nicht mit dem Dateisystem synchronisiert werden“, und das ist sowieso nicht der Fall. Es ist eher so, als würde das Dateisystem nicht mehr mit dem Dateisystem synchronisiert. Es ist definitiv ein Problem, und das ist ein komisches. Welches Dateisystem (welche Dateisysteme) verwendest du (poste die Ausgabe von cat /proc/mounts)? Dies ist wahrscheinlich ein virtualisierter Server. Welche Art von Virtualisierung wird verwendet?

— Gilles 'SO- hör auf böse zu sein'

@ Gilles Ich habe die Frage aktualisiert, um die Ausgabe von cat /proc/mountsfür Sie einzuschließen . Hoffentlich bedeutet das etwas für Sie - Linux ist noch ziemlich neu für mich, daher wurde viel gelernt, und ich habe mich noch nicht mit dem Dateisystem beschäftigt (abgesehen von seiner Verwendung).

— Alex

Das Problem tritt also auf einem ecryptfs-Dateisystem auf. Dies sieht nach einem Fehler in ecryptfs oder in anderen Teilen des Kernels oder gegebenenfalls in der Virtualisierungssoftware oder nach einem Hardwarefehler aus. Läuft dies auf Ihrer eigenen Hardware in einer Box oder in einem Rack oder handelt es sich um einen virtualisierten Server mit einem Hosting-Anbieter? Was ist die Ausgabe von uname -a? Wenn es Ihre Hardware ist, schließen Sie eine Konsole an und führen Sie beim nächsten Start einen Speichertest durch. Wenn es gehostet wird, wenden Sie sich an Ihren Hosting-Anbieter und beschreiben Sie diese Symptome.

— Gilles 'SO- hör auf böse zu sein'

Wenn Sie ausführen sudo sync, werden die Dateien aktualisiert?

— Braiam

Versuchen Sie es mit dem Befehl sync. Auch der df cmd ist praktisch, um zu zeigen, wo ein dir wohnt. Wie / proc / mount, aber besser lesbare Ausgabe. Tun df -h /www ~/battleship /usr/share/nginx/www/bs. Liegt das Problem bei den Mounts von encryptfs? Vielleicht ist eine zusätzliche SW-Verarbeitung erforderlich, um auf diese Disc zu schreiben, damit Zwischenspeicherung stattfindet oder etwas damit zu tun hat?

— Gaoithe

Antworten:

Die einzige Erfahrung, die ich mit so etwas gesehen habe, war, als ein Verzeichnis entfernt und ein neues erstellt wurde. AIX und Solaris hatten dieses Problem bereits vor Jahren. Wenn Sie eine offene Shell-Sitzung in einem entfernten Verzeichnis haben, erhalten Sie möglicherweise unvorhersehbare Ergebnisse, die aussehen, als würde ein Dateisystem nicht mehr synchronisiert.

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)???

Das verschlüsselte Dateisystem klingt auch nach einer Überprüfung. Haben Sie es in einem unverschlüsselten Dateisystem versucht?

Entschuldigung, ich kann noch keine Kommentare schreiben. Nicht genügend Punkte.

— Michael McGarrah
quelle

Dies ist relevant für die Frage, bei der eine Bash-Shell mit einem Standardverzeichnis verbleibt, das nicht vorhanden ist und in dem keine Dateien erstellt werden können.

— Ubfan1

Ich kann dieses kleine Experiment ausprobieren, bin jedoch zuversichtlich, dass es sich um ein Ecryptfs-Problem handelt. Die fraglichen Verzeichnisse existieren definitiv noch; Ich kann cd .nach einer Weile normal arbeiten, wenn ich nach einer Weile zu einer Sitzung zurückkomme. An dieser Stelle denke ich ehrlich gesagt nur darüber nach, alles zu sichern, den Server zu löschen und ohne ein verschlüsseltes Dateisystem neu zu installieren. Ich behalte nichts entfernt Wichtiges dabei, daher mache ich mir keine allzu großen Sorgen um das Verschlüsseln meiner Dateien.

— Alex

Der eCryptfs-Betreuer / Autor in Ubuntu reagiert sehr schnell auf Fehlerberichte. Wenn Sie keine Lösung finden, lohnt es sich wahrscheinlich, ihn zu fragen oder einen Fehlerbericht einzureichen.

— blujay

Sie können versuchen, den Befehl sync zwischen Ihren bash-Befehlen auszuführen.

sync - flush file system buffers

Ich habe selbst nie die Notwendigkeit dafür gefunden, aber ich habe mindestens eine Person gekannt, die es praktisch wie jeden zweiten Befehl getippt hat! Muss in der Vergangenheit mit langsamer Scheibe stark gebrannt worden sein.

Im Internet scheint die Diskussion über die Verwendung des syncBefehls nicht allzu weit fortgeschritten zu sein . Hier ist ein Link zu einem sehr kurzen manuellen Eintrag für sync: http://www.gnu.org/software/coreutils/manual/html_node/sync-invocation.html

syncgarantiert, dass Daten vom Speicher auf das Festplattengerät geschrieben werden. Die Daten befinden sich möglicherweise immer noch im Cache-Speicher des Festplattengeräts und werden nicht auf die Festplatte geschrieben, wenn das Festplattengerät selbst langsam ist oder ein Problem aufweist.

Sie betreiben einen Ubuntu-Server. . . Ist das eine Maschine auf Ihrem Desktop? Oder liegt es in einer Wolke? Oder . . . etwas anderes? Siehe hier: /server/534627/what-does-the-sync-command-do langsame Synchronisierung von Speicher auf Datenträger im Zusammenhang mit Festplattenproblemen oder möglicherweise mit kleineren Amazon AWS-Instanzen.

— Gaoithe
quelle

Ich bin mir nicht sicher, ob synces von Nutzen sein wird. Ich habe festgestellt, dass cd .das Problem sowieso nur dadurch gemildert wird. Ich habe einen Alias refdafür erstellt (ich weiß, das Speichern eines Charakters ist ein bisschen albern), den ich immer wieder benutze, wenn ich zu einer alten Sitzung zurückkomme. Was den Server angeht, so ist es mein alter Desktop-Tower (ich habe im letzten Jahr einen neuen gebaut), der jetzt in der Ecke meines Wohnzimmers mit der Ubuntu-Distribution installiert ist. Ich habe also vollen Zugriff auf die Hardware und die Stromversorgung über den laufenden Betrieb darauf.

— Alex

FWIW das Problem wird durch den Befehl ls angezeigt, nicht durch die Bash.

Die Tatsache, dass Sie die Datei sehen, bedeutet, dass sie noch vorhanden ist. Nichts ist mit irgendetwas anderem nicht synchronisiert und keine laufende Synchronisierung hindert Sie daran, die einzige zwischengespeicherte Kopie der relevanten Dateisystemdaten zu verwenden. Durch die Synchronisierung werden die Daten nur in den permanenten Speicher übernommen und nicht in Ihrer Ansicht geändert.

Verwenden Sie VIM-Sitzungen? Ich kenne die VIM-Sitzung nicht und habe sie selbst nie verwendet, aber ich stelle mir vor, dass tmux dazu führen könnte, dass der VI-Sitzungsmanager nicht erkennt, dass die Datei geschlossen ist, und dass Ihre Änderungen nachverfolgt werden.

— Johan
quelle