Linux muito lento. [RESOLVIDO]

albfneto
(usa openSUSE)

Enviado em 26/05/2014 - 14:58h

Meus outros testes. a mesma distro, tá aberta em fluxbox, nenhum problema, um giga só usado, no máximo.
agora buck, vou fechar, abrir em kde e fazer os testes que sugeriu;

sysctl vm.swappiness

está com swapppiness 60.

fiz o que vc falou, coloquei a linha lá no sysctl.conf. Ficou sem swap. Resetei e abrí em KDE...

não deu outra, igual, em 15-20 segundos, encheu toda a RAM, lotou, mas lógico, não usou a swap. Agora lota a RAM, mais rápido ainda!
começou a travar,

rápido, num terminal, fiz um comando de reboot, e
aqui estou, novamente, sessão aberta em fluxbox, sem o problema.

pelo menos sabemos agora que o problema é no ambiente gráfico, alguma coisa do KDE, que em fluxbox, não carrega.

agora vou procurar pelos rootkits. depois posto....

o RKhunter achou algo sim, algo chamado Knark Rootkit.

System checks summary

=====================



File properties checks...

    Required commands check failed

    Files checked: 152

    Suspect files: 1



Rootkit checks...

    Rootkits checked : 309

    Possible rootkits: 1

    Rootkit names    : Knark Rootkit



Applications checks...

    Applications checked: 4

    Suspect applications: 0



The system checks took: 3 minutes and 59 seconds



All results have been written to the log file (/var/log/rkhunter.log)



One or more warnings have been found while checking the system.

Please check the log file (/var/log/rkhunter.log)

 

aqui o log completo:

http://pastebin.sabayon.org/pastie/16845

mas no log, parece apenas um falso positivo,uma string:

Warning: Found string 'hidef' in file '/etc/init.d/._entropy_backup.0_net.lo'. Possible rootkit: Knark Rootkit

 

Buckminster
(usa Debian)

Enviado em 26/05/2014 - 20:24h

Alberto, veja a saída desse comando

grep -b5 hidef /etc/init.d/._entropy_backup.0_net.lo

albfneto
(usa openSUSE)

Enviado em 26/05/2014 - 20:42h

postanto o arquivo:

grep -b5 hidef /etc/init.d/._entropy_backup.0_net.lo



13784-                  eoutdent

13796-          fi

13801-          return 1

13812-  fi

13816-

13817:  local hidefirstroute=false first=true routes=

13864-  if ${fallback}; then

13886-          routes="$(_get_array "fallback_routes_${IFVAR}")"

13938-  fi

13942-  if [ -z "${routes}" ]; then

13971-          routes="$(_get_array "routes_${IFVAR}")"

14014-  fi

14018-  if [ "${IFACE}" = "lo" -o "${IFACE}" = "lo0" ]; then

14072-          if [ "${config_0}" != "null" ]; then

14111-                  routes="127.0.0.0/8 via 127.0.0.1

14148-${routes}"

14159:                  hidefirstroute=true

14182-          fi

14187-  fi

14191-

14192-  local OIFS="${IFS}" SIFS="${IFS-y}"

14229-  local IFS="$__IFS"

--

14528-                  *.*.*.*/32*)                       cmd="-host ${cmd}";;

14587-                  *.*.*.*/*|0.0.0.0|0.0.0.0" "*)     cmd="-net ${cmd}";;

14645-                  default|default" "*)               cmd="-net ${cmd}";;

14703-                  *)                                 cmd="-host ${cmd}";;

14762-          esac

14769:          if ${hidefirstroute}; then

14798-                  _add_route ${cmd} >/dev/null 2>&1

14835:                  hidefirstroute=false

14859-          else

14866-                  _add_route ${cmd} >/dev/null

14898-          fi

14903-          eend $?

14913-          eoutdent

 

Não sou profissional de TI, mas acho que tem a ver com as rotas dos servidores do entropy.

Eu estava pensando nesse problema.
é engraçado, pq é quase só no KDE, e é como se estivesse rodando algo que aumenta sempre de tamanho e em loop, enchendo a RAM toda.
coisas que fazem isso, normalmente são arquivos maliciosos, não?

agora pouco,para testar, voltei a entrar no KDE. è assim mesmo, em 2, 3 minutos, gasta toda a RAM e trava:

Buckminster
(usa Debian)

Enviado em 26/05/2014 - 21:10h

Sim, geralmente são arquivos maliciosos.
Mas talvez seja um falso positivo, não entendo muito do Sabayon.
Alberto, se você tiver outra instalação do Sabayon aí que esteja funcionando bem, verifique se tem esse arquivo no /etc/init.d.
O que estou achando estranho é esse arquivo estar dentro do /etc/init.d, mas talvez seja normal.

Pode colocar a Swap de volta para 60.

albfneto
(usa openSUSE)

Enviado em 26/05/2014 - 21:15h

RESOLVIDO!!! Descobri...
por incrível que possa parecer, era o Daemon e os processos do DROPBOX!

ao rodar o HTOP mais uma vez, minha idéia era capturar a tela, mostrando a RAM indo embora toda.... o HTOP mostrou, o dropbox, recarregando contínuamente, cada "carga", 12K, 12000, e sem parar, como se tivesse em loop, dezenas e dezenas de instâncias de DropBox....!

Fui Assassino...! rsrsrsrsr! matei todas elas:

# /etc/init.d/dropbox stop
# killall dropbox

Pronto, problema terminado..., veja o HTOP agora:


http://uploaddeimagens.com.br/imagens/travim2-png


mais de um giga, mas normal num sistema grande como o meu.

Buckminster
(usa Debian)

Enviado em 26/05/2014 - 21:16h

Beleza, pensamos igual então. Minha próxima sugestão seria monitorar o htop.

Mas não sabia que o dropbox poderia fazer isso... e só no KDE.

albfneto
(usa openSUSE)

Enviado em 26/05/2014 - 21:21h

Agradecendo a ajuda, porque levamos a tarde toda e parte da noite.
Obrigado, Buck!
agora me resta saber pq o DroBox pirou! rsrsrsr.

o que vou fazer, por enquanto, é só iniciar o dropbox,se precisar dele,ex. adicionar novos arquivos, mesmo porque, tudo que tenho no momento,nele, já tá sincronizado.

complementando, o problema dessetipo em dropbox, já havia sido observado, tem precedentes:

http://www.organicweb.com.au/10100/general-technology/dropbox-high-cpu/

Buckminster
(usa Debian)

Enviado em 26/05/2014 - 21:24h

O Dropbox sempre consumiu muita RAM porque ele tem que manter o controle de uma grande quantidade de informações sobre os arquivos a fim de se certificar de que pode sincronizar os arquivos de forma rápida e eficiente. Quanto mais arquivos que você tem em sua pasta do Dropbox, mais memória o Dropbox irá utilizar.

Mas que eu saiba ele abre um daemon só.

Mas vivendo e aprendendo...