Configuração

Sou programador há algum tempo, mas ainda estou um pouco confuso com coisas internas profundas.

Agora. Estou ciente de que também não é uma boa ideia:

1. matar -9 um processo (ruim)
2. puxe espontaneamente o plugue de energia em um computador ou servidor em execução (pior)

No entanto, às vezes você simplesmente precisa. Às vezes, um processo simplesmente não responde, não importa o que você faz, e às vezes um computador simplesmente não responde, não importa o que você faz.

Vamos supor que um sistema esteja executando o Apache 2, MySQL 5, PHP 5 e Python 2.6.5 através do mod_wsgi.

Nota: Estou mais interessado no Mac OS X aqui, mas uma resposta referente a qualquer sistema UNIX me ajudaria.

A minha preocupação

Cada vez que tenho que fazer uma delas, especialmente a segunda, fico muito preocupado por um período de tempo que algo tenha sido quebrado. Algum arquivo em algum lugar pode estar corrompido - quem sabe qual arquivo? Existem mais de 1.000.000 de arquivos no computador.

Normalmente, estou usando o OS X, por isso executarei uma operação "Verificar disco" por meio do Utilitário de Disco. Ele não apresentará problemas, mas ainda estou preocupado com isso.

E se algum arquivo de configuração em algum lugar fosse ferrado? Ou ainda pior, e se um arquivo binário em algum lugar estiver corrompido. Ou um arquivo de script em algum lugar está corrompido agora. E se algum hardware estiver danificado?

E se eu não descobrir sobre isso até o próximo mês, em um cenário crítico, quando a corrupção ou o dano causar uma catástrofe?

Ou, se dados valiosos já estiverem perdidos?

Minha esperança

Minha esperança é que essas preocupações e preocupações sejam infundadas. Afinal, depois de fazer isso muitas vezes antes, nada realmente ruim aconteceu ainda. O pior é que tive que reparar algumas tabelas do MySQL, mas parece que não perdi nenhum dado.

Mas, se minhas preocupações não são infundadas e danos reais podem ocorrer nas situações 1 ou 2, minha esperança é que haja uma maneira de detectá-lo e prevenir contra ele.

Minhas perguntas)

Isso pode ocorrer porque os sistemas operacionais modernos são projetados para garantir que nada se perca nesses cenários? Poderia ser porque o software moderno foi projetado para garantir que nada se perca? E o design de hardware moderno? Que medidas estão em vigor quando você puxa o plugue de energia?

Minha pergunta é, para ambos os cenários, o que exatamente pode dar errado e que medidas devem ser tomadas para corrigi-lo?

Tenho a impressão de que uma coisa que pode dar errado é que alguns programas podem não ter liberado seus dados para o disco, portanto, qualquer dado altamente recente que deveria ser gravado no disco (digamos, alguns segundos antes da tomada de força ) pode estar perdido. Mas e além disso? E esse problema de perda de dados de 5 segundos pode estragar um sistema?

E a corrupção de arquivos aleatórios escondidos em algum lugar na enorme floresta de arquivos nos meus discos rígidos?

E quanto a danos no hardware?

O que mais me ajudaria

1. Descrições detalhadas sobre o que ocorre internamente quando você mata -9 um processo ou puxa a energia de todo o sistema. (parece instantâneo, mas alguém pode diminuir a velocidade para mim?)

2. Explicações de todas as coisas que podem dar errado nesses cenários, juntamente com probabilidades (aproximadas) é claro (isto é, é muito improvável, mas é provável) ...

3. Descrições de medidas em vigor em hardware, sistemas operacionais e software modernos, para evitar danos ou corrupção quando esses cenários ocorrerem. (para me confortar)

4. Instruções sobre o que fazer após um kill -9 ou um power pull, além de "verificar o disco", para realmente garantir que nada esteja corrompido ou danificado em algum lugar da unidade.

5. Medidas que podem ser tomadas para fortalecer a configuração do computador, de modo que, se algo tiver que ser morto ou a energia tiver que ser retirada, qualquer dano potencial será atenuado.

6. Algumas informações sobre arquivos binários - não é verdade que o arquivo binário apache ou alguma biblioteca poderia ter um byte aleatório ou dois corrompidos no meio, que não sairiam e causariam um problema até mais tarde? Como posso me assegurar de que isso não aconteceu como resultado do poder puxado ou da morte?

Muito obrigado!

Puxar a energia faz com que tudo pare em voo, sem aviso prévio. kill -9 tem o mesmo efeito em um único processo, terminando com força com um SIGKILL .

Se um processo é morto por kernel ou falta de energia, ele não faz nenhuma limpeza. Isso significa que você pode ter arquivos meio gravados, estados inconsistentes ou caches perdidos. Você geralmente não precisa se preocupar com nada disso por causa do registro no diário, status de saída e backup de bateria.

Os arquivos temporários em / tmp desaparecerão automaticamente se estiverem em tmpfs, mas você ainda pode ter arquivos de bloqueio específicos do aplicativo para serem removidos, como o lock e .parentlock do firefox.

A maioria dos softwares é inteligente o suficiente para tentar novamente uma transação se não registrar um status de saída bem-sucedido. Um bom exemplo disso é um sistema de correio típico. Se uma mensagem estiver sendo entregue, mas for interrompida no meio, o remetente tentará mais tarde até obter êxito.

Seu sistema de arquivos provavelmente está registrado em diário. Se você estiver movendo ou gravando um arquivo e ele morrer no meio do caminho, o sistema de arquivos com diário ainda fará referência ao original. O sistema de arquivos com registro em diário fará alterações de maneira não destrutiva, deixando a cópia antiga e, em seguida, faça referência apenas à nova cópia como uma última etapa antes de recuperar o espaço que as cópias antigas ocupavam no disco.

Agora, se você possui uma matriz RAID, ela possui todos os tipos de buffers de memória para aumentar o desempenho e fornecer confiabilidade em uma falha de energia. Provavelmente, o seu sistema de arquivos não saberá sobre os caches no dispositivo e seu estado; portanto, ele acredita que uma alteração foi confirmada no disco, mas ainda está no cache RAID em algum lugar. Então, o que acontece quando o poder morre? Espero que você tenha uma bateria funcional em seu gabinete RAID e você a monitore. Caso contrário, você tem um sistema de arquivos corrompido para fsck.

Sim, alguns bits podem ser corrompidos em um binário, mas eu não me preocuparia com isso no hardware moderno. Se você é realmente paranóico, pode monitorar a integridade de seus discos e RAID com as ferramentas apropriadas, mas deve fazê-lo de qualquer maneira. Faça backups regulares e obtenha uma fonte de alimentação ininterrupta.

Em um desligamento inesperado, os únicos arquivos que devem ser corrompidos são os que estão abertos para gravação. Na maioria dos sistemas, a qualquer momento, você provavelmente não está gravando em um arquivo. Provavelmente.

1 morte -9

é POSIX SIGKILL e depende da implementação. O processo que recebe esse sinal não terá a oportunidade de lidar com isso.

1 Desligar

depende do hardware. As cabeças estacionam automaticamente sob o impulso da unidade e tudo no seu cache de gravação perde a atualização da DRAM e deteriora-se com uma corrupção irrecuperável em segundos. O mesmo acontece com a memória do sistema, cache da CPU, registros, etc.

De wdc.com (google: site: wdc.com Estacionamento da cabeça protetora)

A energia está perdida: o disco rígido é redefinido. A cabeça está estacionada na zona de pouso usando energia do eixo. Motor do eixo parado.

2 - o que pode dar errado

os arquivos deixados em aberto são gravados incompletamente. Se um arquivo for aberto para gravação, haverá corrupção de dados. A gravação de arquivos no hardware moderno é rápida e os PCs modernos normalmente não são estressados ​​com o IO. É como andar de olhos vendados por uma estrada tranquila. Na maioria das vezes, você ficará bem.

3 - contramedidas

veja acima o que os discos fazem.

Procure sistemas de arquivos com registro em diário, agora são normais: http://en.wikipedia.org/wiki/Journaling_file_system

Software como o MS Word ou vi gravará em um arquivo temporário em vez do original. O objetivo é nunca deixar o sistema em um estado em que não haja cópia consistente no disco.

O Windows mantém cópias do registro (é muito importante) Wikipedia: "O Windows 2000 mantém uma cópia alternativa das seções do registro (.ALT) e tenta alternar para ele quando a corrupção é detectada" (não presto suporte técnico pesado desde então Win2k, então não tenho certeza de quais são os novos mecanismos da MS)

4 - o que fazer

Em ordem de dificuldade (fácil-difícil)

• Manter backups
• Verifique no que você estava trabalhando pela última vez
• Inicialize a partir de um disco separado e procure as datas / horas da última modificação para descobrir o que o sistema pode estar fazendo no momento da falha
• Inicialize a partir de um disco separado e compare o md5sums de todos os seus arquivos com uma cópia offline.

Manter backups é a resposta mais apropriada; bons backups devem permitir que você volte para a versão modificada anteriormente.

5

Poder redundante? Educação do usuário final? colocar fita e papelão sobre o botão liga / desliga?

6

Com falta de mau funcionamento do hardware, drivers de disco corrompidos, um kernel do SO quebrado, ausência de somas de verificação ou falhas durante atualizações, binários e bibliotecas não são abertos para leitura e gravação, para que não sejam corrompidos. Isso acontece, mas é raro.

Quanto a um kill -9, isso envia um sinal ao processo para "morrer" bem no local. O processo morre (a menos que esteja em sono ininterrupto, caso em que se torna um zumbi). Nenhum arquivo é fechado, nenhum dado é gravado e o programa não pode capturar esse sinal e fazer outra coisa. Sem limpeza, sem nada: simplesmente morre.

Os sistemas de arquivos hoje são muito robustos; coisas como XFS, JFS, ext3 e ext4 têm diários e outras coisas para manter intactos os metadados do sistema de arquivos.

Binários como o próprio Apache e outros provavelmente não serão corrompidos por uma súbita perda de energia ou por uma interrupção do sistema, pois estão na memória ou sendo lidos; se eles estão sendo lidos (por exemplo, o Apache HTTP está iniciando, por exemplo), é possível que uma oscilação de energia possa corromper o binário, mas parece improvável.

Eu tenho um pessoal do Mac Mini que parece gostar de desligar o computador (não importa quantas vezes eu diga a eles ...) e ele continua.

Na maior parte, desde que você não confie no kill -9 ou desligue-o regularmente, eu não me preocuparia muito. As coisas estavam muito piores no passado; Eu me preocuparia mais com (por exemplo) o Solaris 2.6 do que com o Solaris 10 (e assim por diante).

Um "kill -9" não sincroniza uma operação de E / S pendente. Isso geralmente não é um problema, mas se o sistema estiver sob carga pesada de E / S, você poderá perder dados.

É mais um problema com servidores, onde o controlador RAID (sem cache com bateria) pode armazenar em cache gravações e perder seus dados.

Editar : Mais uma coisa ... se você depende de unidades montadas em rede e tem identificadores de arquivos abertos, é muito provável que deixe o arquivo inconsistente ou corrompido. No Windows, o exemplo clássico disso é quando os usuários montam arquivos PST do Outlook em um compartilhamento e perdem energia ou conectividade de rede.