desligar o servidor; sem resposta, mas sem desconexões

2

Saudações,

Sistema: instalação padrão do gentoo com pouco mais que postfix.

Eu estava no meio de uma grande migração de email conduzida por IMAP na noite passada (um monte de scripts Perl) quando o novo servidor de email parou de responder. No entanto, minhas conexões SSH ainda estão ativas e não serão descartadas. Novas conexões são interrompidas (antes da autenticação), mas não excedem o tempo limite.

Isso significa que acabará se recuperando? Ou preciso reiniciar o servidor?

    
por hawkexp 29.07.2010 / 20:06

2 respostas

0

A reinicialização foi necessária. Esperar por isso resultou em nada acontecendo.

Após investigação adicional, foi descoberto que havia um vazamento de memória na biblioteca Perl IMAP sendo usada. Originalmente, eu tinha configurado o script Perl para carregar todas as contas de e-mail em uma matriz (de um arquivo de texto mencionado na arg 1 na linha de comando), e percorrê-las executando o código de migração para cada conta. Para cada iteração do loop, o script fazia o login no servidor de email de origem e nos servidores de email de destino, executava o código de migração e, em seguida, desconectava-se dos dois servidores de email. Isso eventualmente engoliu toda a RAM disponível, depois toda a SWAP disponível, até que finalmente init matou o processo.

Eu achei que ia acelerar: usei screen para executar 9 desses processos, cada um em um conjunto diferente de contas. Após o lançamento de nove desses processos, o sistema rapidamente diminuiu para um rastreamento e parou de responder todos juntos. Eu estou supondo que init teria eventualmente matado todos os processos Perl, mas quanto tempo levaria esse refúgio? Assim, uma reinicialização foi necessária.

Eu modifiquei meu script de migração do Perl para fazer uma conta e, em seguida, sair. Então eu configurei um loop bash como este para percorrer todas as contas originadas do mesmo arquivo de texto:

# cat run_migration4.sh
#!/bin/bash

FILE=$1

# read $FILE using the file descriptors
exec 3<&0
exec 0<$FILE

while read line
do
        # use $line variable to process line
        echo line: $line
        ./migration4.pl $line
done
exec 0<&3

Isso funcionou muito bem. Consegui executar nove dessas sessões em uma sessão de tela e todas elas ocuparam uma quantidade insignificante de RAM, não perto do limite de 4G do servidor. A média de carga do servidor nunca ficou acima de 2 ou 3. Tudo foi concluído sem problemas.

    
por 30.07.2010 / 01:59
0

Talvez o kernel tenha ficado sem entropia. Isso pode acontecer pelo menos com o servidor Cyrus IMAP se ele não estiver configurado para usar / dev / urandom como sua fonte de aleatoriedade e se o servidor for incapaz de gerar aleatoriedade "real" suficiente para / dev / random . Seus sintomas correspondem aos que encontrei anos atrás.

Para verificar se esse é o seu caso,

watch -n1 'cat /proc/sys/kernel/random/entropy_avail' 

ou

while true; do cat /proc/sys/kernel/random/entropy_avail >>/somepath/available_entropy.txt; sleep 1; done

execute e veja se a entropia disponível cai constantemente para ou perto de 0 durante o desligamento do IMAP. Caso isso aconteça, o software do servidor IMAP está aguardando nova aleatoriedade.

Uma maneira de obter mais entropia é instalar rngd , no caso do Gentoo, isso significa emergir as ferramentas-rng e então iniciar o rngd (Daemon de coleta de números aleatórios). Ele carrega a semi-aleatoriedade de / dev / urandom para / dev / random se a aleatoriedade real estiver baixa demais.

Aviso obrigatório: em ambientes com segurança absoluta, não é isso que você quer.

    
por 30.07.2010 / 10:44

Tags