O bash pode sair de sincronia com o sistema de arquivos?

12

Eu posso não estar formulando minha pergunta corretamente, mas farei o meu melhor para explicar os sintomas que estou tendo. Primeiro, para o contexto, estou executando um servidor Ubuntu (sem GUI), versão 12.04.3 LTS (de acordo com o utilitário lsb_release). Eu geralmente faço todo o meu trabalho no tmux, conecto-me ao servidor via Putty e uso o vim para toda a minha edição de texto.

Agora, para os sintomas. Como eu uso o tmux, geralmente tenho algumas janelas abertas o tempo todo. Um deles abriga um servidor de nós com o qual venho brincando, e ele 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 no servidor usando o nginx, e todo o código do site reside em /usr/share/nginx/www/bs (também mantenho uma janela separada aberta para editar a origem do cliente). O que acontece é que depois de várias horas deixando a janela do servidor inativa e intocada, ela parece estar fora de sincronia. Eu posso executar ls e ver os arquivos, e posso abri-los para edição ( vim server.js ). No entanto, quando faço isso, independentemente de fazer alterações e salvar ou simplesmente sair imediatamente, quando executo ls , vejo um arquivo .server.js.swp e nenhuma das minhas alterações (se eu tiver feito alguma) persistir. Se eu sair desse diretório e depois voltar, ele se corrigirá - eu posso abrir o arquivo e editá-lo com sucesso, sem deixar um .swp quando eu o fechar. Eu mencionei a fonte do cliente metade das coisas porque eu notei que isso não acontece na pasta / www (presumivelmente porque está fora do diretório pessoal da minha conta de usuário).

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

Nota: Eu marquei isto com bash, tmux e putty porque eu estou assumindo que um deles é o culpado, mas eu realmente não tenho ideia de qual.

Atualização: Esta é a saída de cat /proc/mount conforme solicitado por Gilles (embora com meu nome de usuário e os valores de ecryptfs_fnek_sig e ecryptfs_sig censurado, porque embora eu não saiba realmente o que essas duas coisas são, elas parecem relacionadas à criptografia, e é melhor prevenir 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: Veja 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: Eu 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 vai acabar ajudando com qualquer coisa. Você também pode ver alguns detalhes de hardware caso isso ajude de alguma forma.

    
por Alex 06.09.2013 / 22:13

3 respostas

1

A única experiência que eu vi com algo assim foi quando um diretório estava sendo removido e um novo criado. AIX e 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 parecem 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 criptografados?

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

    
por Michael McGarrah 18.03.2014 / 17:37
0

Você pode tentar executar o comando de sincronização entre seus comandos bash.

sync - flush file system buffers

Eu nunca encontrei a necessidade disso, mas conheço pelo menos uma pessoa que o digitou praticamente como todo segundo comando! Deve ter sido gravemente gravado no passado com disco lento.

A internet parece ser leve na discussão do uso do comando sync . Aqui está um link para a entrada manual muito curta para sync : link

sync garante que os dados sejam gravados da memória para o 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. . . é uma máquina na sua área de trabalho? Ou está em uma nuvem? Ou . . algo mais? Veja aqui: link sincronização lenta da memória para o disco associado a problemas no disco rígido OU talvez com o Amazon Instâncias menores da AWS.

    
por gaoithe 23.03.2014 / 22:52
0

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 qualquer outra coisa e nenhuma quantidade de sincronização em execução impedirá que você use a única cópia em cache dos dados relevantes do sistema de arquivos. A sincronização só fará com que os dados se comprometam com o armazenamento permanente e não altere sua exibição.

Você está usando sessões VIM? Eu não sei a sessão do VIM, nunca usei isso sozinho, mas imagino que o tmux pode fazer com que o gerenciador de sessão do VI não perceba que o arquivo está fechado e que suas alterações sejam rastreadas.

    
por Johan 15.04.2014 / 15:11

Tags