Introdução

Frequentando listas de discussão ou mesmo ajudando colegas notei que muitas vezes as pessoas ficam perdidas na tarefa de resolver problemas em Linux. Certamente perguntar e conseguir alguém para resolver seu problema é muito mais fácil, porém nem sempre mais rápido ou prático. Pode ser que ninguém se interesse pelo seu problema. Pode ser que se passe semanas até que alguém se disponha. E antes disso, frequentemente muito antes disso, o problema precisa ser resolvido.

É um pouco de trabalho de detetive, um pouco ciência, um pouco arte. Mas a habilidade de resolver problemas de informática, nesse caso em Linux, pode ser aprendida, e principalmente, aperfeiçoada.

Basta praticar!

Leia os logs, leia os erros

Na maioria dos casos o computador te diz qual é o problema. Então, leia os logs e leia as mensagens de erro, tente interpretá-los. Eles ajudam muito a ter uma noção do que esta ocorrendo. Leia a saída do comando no shell, entre no /var/log e leia os logs que estão lá. Mesmo que as saidas de erro não seja clara a princípio, achá-las e tentar interpretá-las são os primeiros passos para entender o que está acontecendo, e entender o que houve é a base para se resolver o erro.

Exemplo

Situação: eu tenho um servidor Conectiva Linux e resolvi atualizar meu bind! A atualização ocorreu, mas notei que meu bind não mais respondia.

Resolvi executar o script de incialização na mão e ver o que acontecia:

  [root@ace init.d]# ./named start
  Iniciando named: -u not supported on Linux kernels
  older than 2.3.99-pre3
  [FALHOU]
  [root@ace init.d]#

O erro me diz claramente o que aconteceu. A opção de incializacao -u do named não é suportada com meu kernel. Abri o script e editei a opção de inicialização, que estava assim:

  daemon named -u named $CHROOT

para:

  daemon named $CHROOT

Eu sei que isso inicia o named como root e não é o certo, é apenas um exemplo.

E reiniciei o rapaz:

  [root@ace init.d]# ./named start
  Iniciando named: [ OK ]
  [root@ace init.d]#

Mas ele ainda não resolvia os nomes... Opa! Algo errado! Vamos verificar:

  [root@ace init.d]# ./named status
  named inativo mas seus subsistemas trancados
  [root@ace init.d]#

Mais um erro! E agora??? Vamos ler os logs:

  [root@ace init.d]# tail /var/log/messages
  Nov 24 16:43:23 ace named[3829]: couldn't open pid file 
  '/var/run/named/named.pid': Permission denied
  Nov 24 16:43:23 ace named[3829]: exiting (due to early fatal error)

Ahhhhh... Erro de permissão não deixa o named iniciar corretamente! Ele tentou criar o arquivo named.pid no diretório '/var/run/named/ e não conseguiu.

Mudamos o dono do diretorio para root e pronto:

  chown root: /var/run/named/

O named levanta direitinho:

  [root@ace init.d]# ./named start
  Iniciando named: [ OK ]
  [root@ace init.d]# ./named status
  named (pid 4215 4220 4219 4214 4210) está rodando...
  [root@ace init.d]#

Leia a documentação. Leia. De novo.

Todos sabem que existem FAQs, READMEs e manuais. Quando nos viravámos no DOS e no Windows, ler manual era desnecessário. Clique em next e pronto, o programa está instalado, e ninguém lia os READMEs.

Mas agora somos profissionais da área, usamos Linux e UNICES, os programas são complexos e já não é tão fácil assim.

Você teve problemas com um programa? Vá até o site do programa e leia os docs dele. Sim, parece óbvio, mas nem todo mundo faz. Dúvida de sendmail? www.sendmail.org Apache? www.apache.org ! Lá tem toneladas de documentação, exemplos, FAQs e o escambau. Nada melhor do que ir direto à fonte. E como resolver o problema frequentemente está explicado lá. As FAQs dizem o que significa aquele erro que você não entendeu. Não tenha preguiça, a informação está lá, só depende de você.

Exemplo:

Eu recentemente instalei um postfix. Meu chefe quer que os mails sejam fulano@dominio como 99% dos mails, e não fulano@maquina.dominio. Não sei fazer isso! E agora? Vamos ver o que o site da postfix me diz: http://www.postfix.org/. Chego lá e tem um link chamado: Documentation, Howtos and FAQs.

É esse mesmo! Clico lá. Encontro o link:

  * Configuration. Postfix configuration, basic and advanced.

Esse mesmo. Click. Lendo a página, encontro logo no comeco um link:

   What domain to use in outbound mail -

Cliquemos:

  "The myorigin parameter specifies the domain that 
  appears in mail that is 
  posted on this machine.The default is to use the
  local machine name, $myhostname,
  which defaults to the name of the machine. Unless
  you are runninga really small site, you probably
  want to change that into $mydomain,
  which defaults to the parent domain of the machine
  name.

  Examples:
  myorigin = $myhostname (default)
  myorigin = $mydomain (probably desirable)"

Problema resolvido!!

Ah, e use o search engine do site!!!! Muitas vezes o programa contém READMEs, leia-os! Eles não têm esse nome por acaso ;)

Use o Google. Google is your friend.

E se a mensagem de erro não faz nenhum sentido pra você? E se eu não sei o site do desenvolvedor do programa? E se a FAQ não resolve meu problema?? Google is the answer. Google é o melhor search engine que já encontrei! Ele tem um sistema de ranqueamento muito bom, e em geral o que você quer está no começo. Não deixe a aparência simples dele enganar você.

Exemplo 1:

Quero ir ao site do bind... E *não* é www.bind.org. Bem, nesse tem um link pro site de verdade, mas suponhamos que não tenha. Jogue simplesmente "bind" no google e o site correto virá (http://www.isc.org/products/BIND/)

Exemplo 2:

Jogue o erro no google! Sim, copie e cole o erro e faça uma busca! Isso muitas vezes retorna a solução, em listas de discussão, de pessoas que já tiveram o mesmo problema que você! Elimine da mensagem as partes específicas, como o número do pid, ou o nome da máquina, pois isso a torna mais geral e retorna mais resultados. Já vi o Google achar respostas no site do fabricante que nem o próprio search engine do fabricante acha!

Documente os problemas

Resolveu um problema? Documente! Anote de alguma forma, guarde o mail com a solução, escreva no vi, no word, no ed, no emacs, como for. Anote em um caderno. Imprima. Não tem importância o formato, desde que você consiga acessar depois. Mas confie em mim: o problema vai voltar. Pode ser em outra máquina, pode ser em outro emprego. E você não vai lembrar como resolveu! Anote e depois consulte o que anotou. Já vi pessoas quebrarem a cabeça resolvendo um problema e depois descobrir que ja tinham resolvido e anotado, era só ter lido a própria documentação. Crie um diretório (pasta, se você usa windows) de documentação. Sim, dá preguiça, e a tentação é deixar pra lá, uma vez que o problema não existe mais. Mas isso pode salvar sua vida (profissional :) Ah, e se quiser, depois, divulgue e compartilhe as suas dicas ;)

Aprenda Inglês

Hoje em dia existe, felizmente, muita documentação em Português. Mas é impossível ignorar o fato de que mundo se comunica em inglês. É a língua comum. Muita documentação está em Inglês, muita ajuda acessível do mundo inteiro através do inglês, então, não adianta adiar. Se você quer se aperfeiçoar profissionalmente em qualquer área, terá de dominar o Inglês, ou pelo menos a leitura técnica.

Um bom começo pode ser Read in English - Uma Maneira Divertida de Aprender Inglês, de Rubens Queiroz.

Listas

Claro, ler as listas ajuda. Perguntar nas listas tambem. Pesquisar o histórico da lista também. Mas outra coisa que ajuda é tentar realmente resolver os problemas dos outros, mesmo que você não saiba a resposta. Leia o mail do outro e entre no site do fabricante, procure a FAQ que responde aquela dúvida, enfim, gaste um tempo. O quanto você puder, claro. Eu dedico muito de fim de semana pra fazer isso, por exemplo. Em um problema cuja resposta você não sabe e não é seu. Isso é útil de várias maneiras. Você pratica resolver problemas, e, como tudo na vida, a capacidade de resolução de problemas melhora com a prática. E você se beneficia. Outra coisa: você aprende coisas novas de que você pode vir a precisar! Além de ajudar os outros, o que é sempre bom.

Eliminado o impossível, o que resta deve ser verdade

Se o log do Apache não mostra conexão nenhuma, não retorna nenhum erro, é muito provável que seu problema não seja o Apache. Pode ser DNS. Pode ser firewall. Mas mantenha a mente aberta para outras possibilidades, evitando ficar fixo em um único ponto que não avança.

Pensamento científico

Em geral temos cadeias complexas de coisas para produzir um resultado, e quando o resultado não acontece o problema pode estar em qualquer parte dessa cadeia.

Planeje testes para cada passo da cadeia, do mais abrangente pro mais específico, tentando isolar pelo menos em que ponto o problema ocorre.

Se o problema for num script, vá desabilitando partes dele ou inserindo marcadores, como echo "loop 1", echo "loop 2" etc, para saber em que parte do script se manifesta o problema.

Ao elaborar hipóteses para a causa do problema, teste-as. Você acha que o problema é o firewall? Que tal inserir uma regra permitindo tudo vindo da máquina em questão passar para ver se o problema continua? Se você acha que o problema é permissão, execute como root para ver se o problema persiste.

Nunca se esqueça de voltar as coisas para seu estado original após realizar o teste.

Conclusão

Não adianta esperar pelos outros: muitas vezes você é a pessoa que tem de resolver o problema naquele momento. Mas, ao praticar cada vez mais nossa capacidade de resolução, aumentará a frequência com que sentimos aquela gloriosa sensação ao identificar a causa do erro que nos atormentava e exclamar "ACHEI, MALDITO! RESOLVI!" :-)

Gostou deste artigo? Que tal colaborar com o Cybershark? Qualquer dólar ajuda :) MUITO OBRIGADO!