O bash pode ficar fora de sincronia com o sistema de arquivos?

Talvez eu não esteja formulando minha pergunta corretamente, mas farei o possível para explicar os sintomas que estou apresentando. Primeiro, por contexto, estou executando um servidor Ubuntu (sem GUI), versão 12.04.3 LTS (de acordo com o utilitário lsb_release). Geralmente faço todo o meu trabalho no tmux, conecto ao servidor via Putty e uso o vim para toda a minha edição de texto.

Agora para os sintomas. Desde que eu uso o tmux, geralmente tenho algumas janelas abertas o tempo todo. Um deles abriga um servidor de nó com o qual eu ando brincando e mora em um subdiretório da casa da minha conta de usuário (especificamente ~/battleship). O servidor interage com uma página da Web que também estou hospedando fora do servidor usando o nginx e todo o código do site reside /usr/share/nginx/www/bs(eu também mantenho uma janela separada para editar a fonte do cliente). O que acontece é que, após várias horas deixando a janela do servidor ociosa e intocada, ela parece ficar fora de sincronia. Eu posso correr lse ver os arquivos, e posso abri-los para edição ( vim server.js). Quando faço isso, no entanto, independentemente de fazer alterações e salvar ou simplesmente sair instantaneamente, quando corrolsnovamente, vejo um arquivo .server.js.swp e nenhuma das minhas alterações (se eu fiz alguma) persiste. Se eu sair desse diretório e depois voltar, ele se consertará - eu posso abrir o arquivo e editá-lo com sucesso, sem deixar para trás um .swp quando o fechar. Mencionei a origem do cliente metade das coisas, porque percebi que isso não acontece na pasta / www (provavelmente porque está fora do diretório inicial da minha conta de usuário).

Depois dessa parede de texto, minha pergunta é a seguinte: alguém sabe por que isso está acontecendo e como evitá-lo? Eu posso apenas imaginar que há alguma maneira, considerando que este não é o único servidor Linux ao qual me conecto via Putty e uso o tmux / vim, e ainda é o único onde esse comportamento estranho acontece. Qualquer ajuda seria apreciada.

Nota: marquei isso com bash, tmux e putty, porque estou assumindo que um deles é o culpado, mas realmente não tenho idéia de qual.

Atualização: Esta é a saída cat /proc/mountsolicitada por Gilles (embora com meu nome de usuário e os valores de ecryptfs_fnek_sige ecryptfs_sigcensurado, porque, embora eu realmente não saiba o que são essas duas coisas, elas parecem relacionadas à criptografia e são mais seguras do que remediar).

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

Atualização 2: Aqui está a saída 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

Atualização 3: completei um passe de memtest. Este é o resultado do referido teste . Parece ter sido concluído sem erros, por isso não tenho certeza se isso vai ajudar com alguma coisa. Você também pode ver alguns detalhes de hardware, caso isso ajude de alguma forma.

bash putty tmux

— Alex
fonte

Não, o bash não pode “ficar fora de sincronia com o sistema de arquivos”, e não é isso que está acontecendo de qualquer maneira. É mais como se o sistema de arquivos estivesse ficando fora de sincronia com o sistema de arquivos. Definitivamente é um problema, e um estranho nisso. Quais sistemas de arquivos você está usando (publique a saída de cat /proc/mounts)? Provavelmente, este é um servidor virtualizado, que tipo de virtualização ele está usando?

— Gilles 'SO- stop be evil'

@ Gilles Atualizei a pergunta para incluir a saída de cat /proc/mountspara você. Espero que isso signifique algo para você - eu ainda sou muito novo no Linux, então aprendi muito aprendendo e ainda não brinquei com o sistema de arquivos (além de usá-lo).

— 6283 Alex

Portanto, o problema ocorre em um sistema de arquivos ecryptfs. Parece um bug no ecryptfs ou em outras partes do kernel, ou no software de virtualização, se aplicável, ou uma falha de hardware. Isso está sendo executado em seu próprio hardware em uma caixa ou em um rack ou é um servidor virtualizado com algum provedor de hospedagem? Qual é o resultado de uname -a? Se for o seu hardware, conecte um console e faça um teste de memória na próxima inicialização. Se estiver hospedado, entre em contato com seu provedor de hospedagem e descreva esses sintomas.

— Gilles 'SO- stop be evil'

Se você executar sudo sync, os arquivos serão atualizados?

— Braiam 15/09/13

Tente o comando sync. Além disso, o df cmd é útil para mostrar onde um dir vive. Como / proc / mount, mas saída mais legível. Faça df -h /www ~/battleship /usr/share/nginx/www/bs. O problema com as montagens encryptfs? Talvez seja necessário um processamento sw extra para gravar nesse disco, para que haja armazenamento em cache ou algo acontecendo com isso?

— gaoithe

Respostas:

A única experiência que vi com algo assim foi quando um diretório estava sendo removido e um novo criado. O AIX e o Solaris tiveram esse problema anos atrás. Se você tiver uma sessão de shell aberta em um diretório removido, poderá obter resultados imprevisíveis, que se assemelham a um sistema de arquivos ficando fora de sincronia.

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

O sistema de arquivos criptografados também parece algo para revisar. Você já tentou em um sistema de arquivos não criptografado?

Desculpe, ainda não posso postar comentários. Não há pontos suficientes.

— Michael McGarrah
fonte

Isso é relevante para a pergunta, com um shell bash deixado com um diretório padrão que não existe e no qual é impossível criar arquivos.

— ubfan1

Eu posso tentar esse pequeno experimento, mas estou bastante confiante neste momento que é um problema do ecryptfs. Os diretórios em questão definitivamente ainda existem; Posso trabalhar normalmente depois de um simples cd .quando volto a uma sessão depois de um tempo. Neste ponto, sinceramente, estou apenas pensando em fazer backup de tudo, limpar o servidor e reinstalar sem um sistema de arquivos criptografado. Não guardo nada de importante remotamente, por isso não estou muito preocupado em criptografar meus arquivos.

— 25414 Alex

O mantenedor / autor do eCryptfs no Ubuntu é muito responsivo aos relatórios de erros. Se você não conseguir encontrar uma solução, provavelmente vale a pena perguntar ou arquivar um relatório de erro.

— Blujay

Você pode tentar executar o comando sync entre seus comandos bash.

sync - flush file system buffers

Eu nunca encontrei a necessidade disso, mas conheci pelo menos uma pessoa que a digitou praticamente como cada segundo comando! Deve ter sido gravado mal no passado com disco lento.

A internet parece ter pouca discussão sobre o uso do synccomando. Aqui está um link para uma entrada manual muito curta para sync: http://www.gnu.org/software/coreutils/manual/html_node/sync-invocation.html

syncgarante que os dados sejam gravados da memória no dispositivo de disco. Os dados ainda podem estar na memória cache do dispositivo de disco e não gravados no disco se o próprio dispositivo de disco estiver lento ou tiver um problema.

Você está executando um servidor ubuntu. . . isso é uma máquina na sua área de trabalho? Ou é em uma nuvem? Or. . . algo mais? Consulte aqui: /server/534627/what-does-the-sync-command-do slow sync from memory to disk associado a problemas no disco rígido OU talvez com instâncias menores do Amazon AWS.

— gaoithe
fonte

Não tenho certeza se syncserá de alguma utilidade; Descobri que apenas fazer cd .atenua o problema de qualquer maneira. Fiz um pseudônimo refpara ele (eu sei, salvar um personagem é um pouco bobo) que eu tenho o hábito de usar toda vez que volto para uma sessão antiga agora. Quanto ao servidor, é a minha antiga torre de desktop (que construí uma nova no ano passado) que agora mora no canto da minha sala de estar executando a distribuição Ubuntu, por isso tenho acesso total ao hardware e poder sobre o que está sendo executado nele.

— 28414 Alex

FWIW, o problema é exibido pelo comando ls, não pelo bash.

O fato de você ver o arquivo significa que ele ainda está lá. Nada está fora de sincronia com nada mais e nenhuma quantidade de sincronização em execução impedirá o uso da única cópia em cache dos dados relevantes do sistema de arquivos. A sincronização apenas fará com que os dados sejam comprometidos com o armazenamento permanente, e não mudará sua visão.

Você está usando sessões do VIM? Não conheço a sessão do VIM, nunca a usei, mas imagino que o tmux possa fazer com que o gerenciador de sessões do VI não perceba que o arquivo está fechado e mantenha suas alterações sendo rastreadas.

— Johan
fonte