Munin "Entropia disponível" ao usar randomização de layout de espaço de endereço

3

Tendo acabado de configurar o Munin para registrar as estatísticas no meu servidor gentoo (perfil reforçado), estou percebendo que a minha "Entropia disponível" é consitentemente na faixa de 200-300. Isso parece baixo, então eu verifiquei manualmente usando o comando

$ cat /proc/sys/kernel/random/entropy_avail
3544

Estranho. Consistentemente valores muito baixos em Munin e praticamente preenchidos ao verificar manualmente. Depois de pensar sobre o problema por um tempo cheguei à conclusão de que o problema é provavelmente que eu estou usando Adress Space Layout Randomization, que está usando a entropia ao executar comandos / programas. Como Munin executa toda uma série de programas, toda a entropia é usada e Munin mede a quantidade de entropia que existe, resultando em valores baixos.

Alguém tem alguma experiência com isso? Como isso pode ser evitado?

    
por Simon Lindgren 14.03.2010 / 22:40

3 respostas

1

Outra solução semelhante seria um novo plugin de entropia que

  1. imprime o resultado anteriormente em cache.
  2. garfos
  3. .
  4. dorme por, digamos, 3 minutos.
  5. extrai a entropia usando o plug-in Munin de entropia original e a salva em cache.

O bom desta solução é que ela não exige que você envolva o cron.

Como os plug-ins do Munin geralmente são executados a cada cinco minutos, isso significaria que sua entropia seria de 2 minutos atrasada, mas certamente soa muito melhor do que dados incorretos.

    
por 31.03.2010 / 17:01
0

Parece ser resolvido na versão 1.4.3

    
por 07.04.2010 / 14:06
0

Eu vejo que você não recebeu uma resposta. Caso você esteja certo de que a entropia é mostrada errada por causa de todos os outros processos, você poderia chamar seu plug-in munin entropy através de um script de cronjob e armazenar em cache seu resultado em um arquivo. Em seguida, você modifica o plug-in de entropia Munin original para retornar apenas o resultado armazenado em cache anteriormente. Vale a pena tentar.

    
por 31.03.2010 / 16:56