Bash peut-il se désynchroniser avec le système de fichiers?

Je ne formule peut-être pas ma question correctement, mais je ferai de mon mieux pour expliquer les symptômes que je ressens. Tout d'abord, pour le contexte, j'utilise un serveur Ubuntu (sans interface graphique), version 12.04.3 LTS (selon l'utilitaire lsb_release). Je fais généralement tout mon travail dans tmux, je me connecte au serveur via Putty et j'utilise vim pour toutes mes modifications de texte.

Maintenant pour les symptômes. Depuis que j'utilise tmux, j'ai généralement quelques fenêtres ouvertes en tout temps. L'un d'eux héberge un serveur de nœuds avec lequel j'ai joué, et il vit dans un sous-répertoire de la maison de mon compte d'utilisateur (en particulier, ~/battleship). Le serveur interagit avec une page Web que j'héberge également hors du serveur en utilisant nginx, et tout le code du site Web vit /usr/share/nginx/www/bs(je garde également une fenêtre séparée ouverte pour modifier la source du client). Ce qui se passe, c'est qu'après plusieurs heures à laisser la fenêtre du serveur inactive et intacte, elle semble ne plus être synchronisée. Je peux exécuter lset voir les fichiers, et je peux les ouvrir pour les éditer ( vim server.js). Cependant, quand je le fais, que j'apporte des modifications et que j'enregistre ou que je quitte instantanément, lorsque je lancelsà nouveau, je vois un fichier .server.js.swp, et aucune de mes modifications (si j'en ai fait) ne persiste. Si je sors de ce répertoire et que je le rentre, il se corrige - je peux ouvrir le fichier et le modifier avec succès, sans laisser de fichier .swp lorsque je le ferme. J'ai mentionné la moitié de la source du client parce que j'ai remarqué que cela ne se produit pas dans le dossier / www (probablement parce qu'il est en dehors du répertoire personnel de mon compte d'utilisateur).

Après ce mur de texte, ma question est la suivante: quelqu'un sait-il pourquoi cela se produit et comment l'empêcher? Je peux seulement imaginer qu'il existe un moyen, étant donné que ce n'est pas le seul serveur Linux auquel je me connecte via Putty et que j'utilise tmux / vim, et pourtant c'est le seul où ce comportement étrange se produit. Toute aide serait appréciée.

Remarque: J'ai marqué cela avec bash, tmux et putty parce que je suppose que l'un d'eux est à blâmer mais je n'ai vraiment aucune idée de ce qui.

Mise à jour: c'est la sortie de cat /proc/mountcomme demandé par Gilles (bien qu'avec mon nom d'utilisateur et les valeurs de ecryptfs_fnek_siget ecryptfs_sigcensuré, parce que même si je ne sais pas vraiment ce que ces deux choses sont, elles semblent liées au chiffrement, et mieux vaut prévenir que guérir).

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

Mise à jour 2: voici la sortie de 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

Mise à jour 3: j'ai terminé une passe de memtest. C'est le résultat dudit test . Semble avoir terminé sans erreur, donc je ne sais pas si cela finira par aider avec quoi que ce soit. Vous pouvez également voir certains détails du matériel au cas où cela aiderait en aucune façon.

bash putty tmux

— Alex
source

Non, bash ne peut pas "se désynchroniser avec le système de fichiers", et ce n'est pas ce qui se passe de toute façon. C'est plus comme si le système de fichiers se désynchronisait avec le système de fichiers. C'est définitivement un problème, et bizarre à cela. Quel (s) système (s) de fichiers utilisez-vous (publier la sortie de cat /proc/mounts)? Il s'agit probablement d'un serveur virtualisé, quel type de virtualisation utilise-t-il?

— Gilles 'SO- arrête d'être méchant'

@ Gilles J'ai mis à jour la question pour inclure la sortie de cat /proc/mountspour vous. J'espère que cela signifiera quelque chose pour vous - je suis encore assez nouveau pour Linux, donc il y a eu beaucoup d'apprentissage par la pratique, et je n'ai pas encore fouillé avec le système de fichiers (au-delà de l'utiliser).

— Alex

Le problème se produit donc sur un système de fichiers ecryptfs. Cela ressemble à un bogue dans ecryptfs, ou dans d'autres parties du noyau, ou dans le logiciel de virtualisation le cas échéant, ou à une défaillance matérielle. Est-ce que cela fonctionne sur votre propre matériel dans une boîte ou sur un rack, ou s'agit-il d'un serveur virtualisé avec un hébergeur? Quelle est la sortie de uname -a? Si c'est votre matériel, branchez une console et faites un test de mémoire au prochain démarrage. S'il est hébergé, contactez votre hébergeur et décrivez ces symptômes.

— Gilles 'SO- arrête d'être méchant'

Si vous exécutez, sudo syncles fichiers sont-ils mis à jour?

— Braiam

Essayez la commande de synchronisation. De plus, le cmd df est pratique pour montrer où réside un dir. Comme / proc / mount mais une sortie plus lisible. Faites df -h /www ~/battleship /usr/share/nginx/www/bs. Le problème avec les montures encryptfs? Peut-être qu'un traitement sw supplémentaire est nécessaire pour les écritures sur ce disque afin qu'il y ait une mise en cache ou quelque chose qui se passe avec cela?

— Gaoithe

Réponses:

La seule expérience que j'ai vue avec quelque chose comme ça était quand un répertoire était supprimé et un nouveau créé. AIX et Solaris avaient ce problème il y a des années. Si vous avez une session shell ouverte dans un répertoire supprimé, vous pouvez obtenir des résultats imprévisibles qui ressemblent à un système de fichiers qui se désynchronise.

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

Le système de fichiers crypté ressemble également à quelque chose à revoir. Avez-vous essayé dans un système de fichiers non crypté?

Désolé, je ne peux pas encore poster de commentaires. Pas assez de points.

— Michael McGarrah
source

Ceci est pertinent pour la question, avec un shell bash laissé avec un répertoire par défaut qui n'existe pas et dans lequel il est impossible de créer des fichiers.

— ubfan1

Je peux essayer cette petite expérience, mais je suis assez confiant à ce stade que c'est un problème ecryptfs. Les répertoires en question existent certainement encore; Je peux travailler normalement après un simple cd .quand je reviens à une session après un certain temps. À ce stade, je pense honnêtement à tout sauvegarder, à essuyer le serveur et à réinstaller sans système de fichiers crypté. Je ne garde rien d'important à distance dessus, donc je ne suis pas trop préoccupé par le cryptage de mes fichiers.

— Alex

Le mainteneur / auteur d'eCryptfs dans Ubuntu est très réactif aux rapports de bogues. Si vous ne trouvez pas de solution, cela vaut probablement la peine de lui demander ou de déposer un rapport de bogue.

— blujay

Vous pouvez essayer d'exécuter la commande de synchronisation entre vos commandes bash.

sync - flush file system buffers

Je n'ai jamais trouvé le besoin de cela moi-même mais j'ai connu au moins une personne qui l'a tapé pratiquement à chaque seconde commande! Doit avoir été gravement brûlé dans le passé avec un disque lent.

Internet semble être léger sur la discussion de l'utilisation de la synccommande. Voici un lien vers une entrée manuelle très courte pour sync: http://www.gnu.org/software/coreutils/manual/html_node/sync-invocation.html

syncgarantit que les données sont écrites de la mémoire sur le périphérique de disque. Les données peuvent toujours être dans la mémoire cache du périphérique de disque et non écrites sur le disque si le périphérique de disque lui-même est lent ou a un problème.

Vous exécutez un serveur ubuntu. . . est-ce une machine sur votre bureau? Ou est-ce dans un nuage? Ou . . . autre chose? Voir ici: /server/534627/what-does-the-sync-command-do lente synchronisation de la mémoire au disque associé à des problèmes de disque dur OU peut-être avec des instances Amazon AWS plus petites.

— gaoithe
source

Je ne sais pas si synccela sera utile; J'ai trouvé que le simple fait d' cd .atténuer le problème de toute façon. J'ai fait un alias refpour cela (je sais, sauvegarder un caractère est un peu idiot) que j'ai l'habitude d'utiliser chaque fois que je reviens à une ancienne session maintenant. En ce qui concerne le serveur, c'est mon ancienne tour de bureau (j'en ai construit une nouvelle l'année dernière) qui vit maintenant dans le coin de mon salon exécutant la distribution Ubuntu, j'ai donc un accès complet au matériel et à la puissance sur ce qui fonctionne dessus.

— Alex

FWIW le problème est affiché par la commande ls, pas par bash.

Le fait que vous voyez le fichier signifie qu'il est toujours là. Rien n'est désynchronisé avec quoi que ce soit d'autre et aucune synchronisation en cours ne vous empêchera d'utiliser la seule copie mise en cache des données du système de fichiers pertinentes. la synchronisation entraînera simplement la validation des données dans un stockage permanent, et ne changera pas votre vue de celles-ci.

Utilisez-vous des sessions VIM? Je ne connais pas la session VIM, je ne l'ai jamais utilisée moi-même, mais j'imagine que tmux pourrait faire en sorte que le gestionnaire de session VI ne réalise pas que le fichier est fermé et que vos modifications soient suivies.

— Johan
source