Administração do Sistema

Guia de solução de problemas gerais GNU/Linux para iniciantes

Guia de solução de problemas gerais GNU/Linux para iniciantes

Neste guia, nosso objetivo é aprender sobre as ferramentas e o ambiente fornecido por um sistema GNU/Linux típico para poder começar a solução de problemas, mesmo em uma máquina desconhecida.
Neste tutorial, você aprenderá:

  • Como verificar o espaço do disco
  • Como verificar o tamanho da memória
  • Como verificar o carregamento do sistema
  • Como encontrar e matar processos do sistema
  • Como fazer logs de usuários para encontrar informações relevantes para solucionar o sistema
Guia de solução de problemas gerais GNU/Linux para iniciantes

Requisitos de software e convenções usadas

Requisitos de software e convenções de linha de comando Linux
Categoria Requisitos, convenções ou versão de software usada
Sistema Ubuntu 20.04, Fedora 31
Programas N / D
Outro Acesso privilegiado ao seu sistema Linux como raiz ou através do sudo comando.
Convenções # - requer que os comandos Linux sejam executados com privilégios root diretamente como usuário root ou por uso de sudo comando
$ - Requer que os comandos do Linux sejam executados como um usuário não privilegiado regular

Introdução

Embora GNU/Linux seja bem conhecido por sua estabilidade e robustez, há casos em que algo pode dar errado. A fonte do problema pode ser interna e externa. Por exemplo, pode haver um processo de mau funcionamento em execução no sistema que consome recursos ou um disco rígido antigo pode estar com defeito, resultando em erros de E/S relatados.

De qualquer forma, precisamos saber onde procurar e o que fazer para obter informações sobre a situação, e este guia está tentando fornecer exatamente isso - uma maneira geral de entender isso. A resolução de qualquer problema começa com o conhecimento do problema, encontrando os detalhes, encontrando a causa raiz e resolvendo -a. Como em qualquer tarefa, o GNU/Linux fornece inúmeras ferramentas para ajudar o progresso, esse é o caso da solução de problemas também. As poucas dicas e métodos seguintes são apenas alguns comuns que podem ser usados ​​em muitas distribuições e versões.

Sintomas

Suponha que tenhamos um bom laptop em que trabalhamos. Ele está executando os mais recentes Ubuntu, Centos ou Red Hat Linux, com atualizações sempre no lugar para manter tudo novo. O laptop é para uso geral cotidiano: processamos e -mails, conversamos, navegamos na Internet, talvez produzimos algumas planilhas nele, etc. Nada especial é instalado, uma suíte de escritório, um navegador, um cliente de e -mail e assim por diante. De um dia para outro, de repente a máquina se torna extremamente lenta. Já trabalhamos nisso por cerca de uma hora, então não é um problema depois de inicializar. O que está acontecendo… ?

Verificação de recursos do sistema

GNU/Linux não fica lento sem motivo. E provavelmente nos dirá onde dói, desde que seja capaz de responder. Como em qualquer programa em execução em um computador, o sistema operacional usa recursos do sistema e, com aqueles que funcionam grossos, as operações terão que esperar até que haja o suficiente para prosseguir. Isso realmente fará com que as respostas fiquem mais lentas e lentas; portanto, se houver um problema, é sempre útil verificar o estado dos recursos do sistema. Em geral, nossos recursos do sistema (local) consistem em disco, memória e CPU. Vamos verificar todos eles.

Espaço em disco

Se o sistema operacional em execução estiver sem espaço em disco, isso é uma má notícia. Como os serviços em execução não podem escrever seus arquivos de log, eles travarão principalmente se funcionarão ou não começarão se os discos já estiverem cheios. Além dos arquivos de log, soquetes e arquivos PID (identificador de processo) precisam ser escritos no disco e, embora sejam pequenos em tamanho, se não houver absolutamente mais espaço, eles não podem ser criados.

Para verificar o espaço do disco disponível, podemos usar df no terminal e adicione -h Argumento, para ver os resultados reunidos até megabytes e gigabytes. Para nós, as entradas de interesse seriam volumes que usaram% de 100%. Isso significaria que o volume em questão está cheio. O exemplo a seguir mostra que estamos bem em relação ao espaço do disco:

$ df -h Tamanho do sistema de arquivos usado Use% montado no devtmpfs 1.8g 0 1.8g 0% /dev tmpfs 1.8g 0 1.8g 0% /dev /shm tmpfs 1.8g 1.3m 1.8g 1% /run /dev /mapper /lv-root 49g 11g 36g 24% /tmpfs 1.8g 0 1.8g 0% /tmp /dev /sda2 976m 261m 649m 29% /bota /dev /mapper /lv-casa 173g 18g 147g 11% /home tmpfs 361m 4.0k 361m 1%/execução/usuário/1000
cópia de

Então, temos espaço no (s) disco (s). Observe que, no nosso caso de laptop lento, a exaustão do espaço em disco provavelmente não será a causa raiz. Quando os discos estiverem cheios, os programas travarão ou não começarão. Em caso extremo, mesmo o login falhará após a inicialização.

Memória

A memória também é um recurso vital e, se estivermos sem ela, o sistema operacional pode precisar escrever peças atualmente não utilizadas para o disco temporário (também chamado de "troca") para dar a memória libertada ao próximo processo e depois ler de volta quando o processo que possui o conteúdo trocado precisa dele novamente. Todo esse método chamado troca, e de fato desacelerará o sistema, pois escrever e ler de e para os discos são muito mais lentos do que trabalhar dentro da RAM.

Para verificar o uso da memória, temos o prático livre comando que podemos anexar com argumentos para ver os resultados em megabytes (-m) ou gigabytes (-g):

$ grátis -m total usado grátis buff/cache disponível Mem: 7886 3509 1547 1231 2829 2852 Swap: 8015 0 8015
cópia de

No exemplo acima, temos 8 GB de memória, 1,5 GB livre e cerca de 3 GB em caches. O livre Comando também fornece o estado do trocar: Nesse caso, está perfeitamente vazio, o que significa que o sistema operacional não precisou escrever nenhum conteúdo de memória no disco desde a inicialização, nem mesmo em cargas de pico. Isso geralmente significa que temos mais memória que realmente usamos. Então, em relação à memória, somos mais do que bons, temos bastante.

Carga do sistema

À medida que os processadores fazem os cálculos reais, ficar sem tempo do processador para calcular pode resultar novamente na desaceleração do sistema. Os cálculos necessários precisam esperar até que qualquer processador tenha tempo livre para calculá -los. A maneira mais fácil de ver a carga em nossos processadores é o tempo de atividade comando:

$ uptime 12:18:24 UP 4:19, 8 Usuários, Carregar Média: 4,33, 2,28, 1,37
cópia de

Os três números após a média de carga significam média nos últimos 1, 5 e 15 minutos. Neste exemplo, a máquina tem 4 núcleos de CPU, por isso estamos tentando usar mais do que nossa capacidade real. Observe também que os valores históricos mostram que a carga está aumentando significativamente nos últimos minutos. Talvez tenhamos encontrado o culpado?

Principais processos do consumidor

Vamos ver toda a imagem da CPU e consumo de memória, com os principais processos usando esses recursos. Podemos executar o principal comando para ver o sistema de carga (próximo) em tempo real:

Verificando os principais processos do consumidor.

A primeira linha de topo é idêntica à saída de tempo de atividade, Em seguida, podemos ver o número se as tarefas em execução, dormindo, etc. Observe a contagem de processos de zumbi (desnutivação); Nesse caso, é 0, mas se houvesse alguns processos no estado de zumbi, eles deveriam ser investigados. A próxima linha mostra a carga nas CPUs em porcentagem e as porcentagens acumuladas exatamente o que Os processadores estão ocupados com. Aqui podemos ver que os processadores estão ocupados servindo programas de espaço de usuários.

Em seguida são duas linhas que podem ser familiares do livre saída, o uso da memória se o sistema. Abaixo desses estão os principais processos, classificados pelo uso da CPU. Agora podemos ver o que está comendo nossos processadores, é Firefox no nosso caso.

Processos de verificação

Como sei disso, já que o processo de consumo superior é mostrado como "conteúdo da web" no meu principal saída? Usando ps Para consultar a tabela de processos, usando o PID mostrado ao lado do processo superior, que é neste caso 5785:

$ ps -ef | Grep 5785 | grep -v guia Firefox/navegador 2528

Com esta etapa, encontramos a causa raiz de nossa situação. Firefox está comendo nosso tempo de CPU a ponto de começar nosso sistema a responder a nossas ações mais lentamente. Isso não é necessariamente culpa do navegador,
Como o Firefox foi projetado para exibir páginas da World Wide Web: para criar uma questão da CPU para fins de demonstração, tudo o que fiz foi abrir algumas dezenas de instâncias de uma página de teste de estresse em guias distintas do navegador ao ponto em que a escassez de CPU superfícies. Então, não preciso culpar meu navegador, mas eu mesmo por abrir páginas famintas de recursos e deixá-los correr em paralelo. Ao fechar alguns, minha CPU
Uso retorna ao normal.

Destruindo processos

O problema e a solução são descobertos acima, mas e se eu não conseguir acessar o navegador para fechar algumas guias? Digamos que minha sessão gráfica esteja bloqueada e eu não posso fazer o login, ou um general
Processo que enlouqueceu nem sequer tem interface onde podemos mudar seu comportamento? Nesse caso, podemos emitir o desligamento do processo pelo sistema operacional. Já sabemos o pid do
processo desonesto que recebemos ps, e podemos usar o matar comando para desligá -lo:

$ Kill 5785

Processos de bem-estar vão sair, alguns podem não. Se sim, adicionando o -9 A bandeira forçará o término do processo:

$ kill -9 5785

Observe, no entanto, que isso pode causar perda de dados, porque o processo não tem tempo para fechar arquivos abertos ou terminar de escrever seus resultados para disco. Mas, em caso de alguma tarefa repetível, a estabilidade do sistema pode ter prioridade sobre a perda de alguns de nossos resultados.

Encontrando informações relacionadas

Interagir com processos com algum tipo de interface nem sempre é o caso, e muitos aplicativos possuem apenas comandos básicos que controlam seu comportamento - a saber, iniciar, parar, recarregar e tal, porque seus trabalhos internos são fornecidos por sua configuração. O exemplo acima foi mais um desktop, vamos ver um exemplo do lado do servidor, onde temos um problema com um servidor da web.

Suponha que tenhamos um servidor da web que sirva algum conteúdo para o mundo. É popular, por isso não é uma boa notícia quando recebemos uma ligação de que nosso serviço não está disponível. Podemos verificar a página da web em um navegador apenas para receber uma mensagem de erro dizendo "incapaz de conectar". Vamos ver a máquina que executa o servidor da web!

Verificando arquivos de log

Nossa máquina que hospeda o servidor da web é uma caixa de Fedora. Isso é importante devido aos caminhos do sistema de arquivos que precisamos seguir. Fedora e todas as outras variantes do Red Hat armazenam os arquivos de log do Apache Webs no caminho /var/log/httpd. Aqui podemos verificar o error_log usando visualizar, mas não encontre nenhuma informação relacionada sobre qual pode ser o problema. Verificar os registros de acesso também não mostra nenhum problema à primeira vista, mas pensar duas vezes nos dará uma dica: em um servidor da web com tráfego bom o suficiente, as últimas entradas do log de acesso devem ser muito recentes, mas a última entrada já tem uma hora de idade. Sabemos por experiência que o site recebe visitantes a cada minuto.

Systemd

Nossa instalação do Fedora usa Systemd como sistema init. Vamos consultar algumas informações sobre o servidor da web:

# status Systemctl httpd ● httpd.Serviço - o servidor Apache HTTP carregado: carregado (/usr/lib/systemd/system/httpd.serviço; desabilitado; predefinição do fornecedor: desativado):/usr/lib/systemd/system/httpd.serviço.d └─php-fpm.conft ativo: falhou (resultado: sinal) desde o sol 2020-08-02 19:03:21 cest; 3min 5s atrás Docs: Man: Httpd.Serviço (8) Processo: 29457 ExecStart =/usr/sbin/httpd $ options -dforeground (código = matado, sinal = matar) PID principal: 29457 (código = morto, sinal = matar) Status: "Total de solicitações: 0; Idle /Trabalhadores ocupados 100/0; solicitações/s: 0; bytes servidos/s: 0 b/s "CPU: 74ms 02 de agosto 19:03:21 MyWebServer1.Foobar Systemd [1]: httpd.Serviço: Processo de Killing 29665 (N/A) com Signal Sigkill. 02 de agosto 19:03:21 MyWebServer1.Foobar Systemd [1]: httpd.Serviço: Processo de Killing 29666 (N/A) com Signal Sigkill. 02 de agosto 19:03:21 MyWebServer1.Foobar Systemd [1]: httpd.Serviço: Processo de Killing 29667 (N/A) com Signal Sigkill. 02 de agosto 19:03:21 MyWebServer1.Foobar Systemd [1]: httpd.Serviço: Processo de Killing 29668 (N/A) com Signal Sigkill. 02 de agosto 19:03:21 MyWebServer1.Foobar Systemd [1]: httpd.Serviço: Processo de Killing 29669 (N/A) com Signal Sigkill. 02 de agosto 19:03:21 MyWebServer1.Foobar Systemd [1]: httpd.Serviço: Processo de Killing 29670 (N/A) com Signal Sigkill. 02 de agosto 19:03:21 MyWebServer1.Foobar Systemd [1]: httpd.Serviço: Processo de Killing 29671 (N/A) com Signal Sigkill. 02 de agosto 19:03:21 MyWebServer1.Foobar Systemd [1]: httpd.Serviço: Processo de Killing 29672 (N/A) com Signal Sigkill. 02 de agosto 19:03:21 MyWebServer1.Foobar Systemd [1]: httpd.Serviço: Processo de Killing 29673 (N/A) com Signal Sigkill. 02 de agosto 19:03:21 MyWebServer1.Foobar Systemd [1]: httpd.Serviço: falhou com o resultado 'sinal'.
cópia de

O exemplo acima é novamente simples, o httpd processo principal para baixo porque recebeu um sinal de morte. Pode haver outro sysadmin que tenha o privilégio de fazê -lo, para que possamos verificar quem é
conectado (ou estava no momento do desligamento vigoroso do servidor da web) e pergunte a ela sobre o problema (uma parada sofisticada de serviço teria sido menos brutal, então deve haver uma razão por trás disso
evento). Se somos os únicos administradores do servidor, podemos verificar de onde vem esse sinal - podemos ter um problema de violação, ou o sistema operacional enviou o sinal de morte. Nos dois casos, podemos usar o
Os arquivos de log do servidor, porque ssh Os logins são registrados nos logs de segurança (/var/log/seguro no caso do Fedora), e também há entradas de auditoria encontradas no log principal (que é
/var/log/mensagens nesse caso). Há uma entrada que nos diz o que aconteceu neste último:

2 de agosto 19:03:21 MyWebServer1.Foobar Audit [1]: service_stop pid = 1 uid = 0 AUID = 4294967295 SES = 4294967295 msg = "unidade = httpd Comm =" Systemd "exe ="/usr/lib/Systemd/Systemd "HostName =? addr =? terminal =? res = falhou "

Conclusão

Para fins de demonstração, matei meu próprio processo de servidor da web de laboratório neste exemplo. Em um problema relacionado ao servidor, a melhor ajuda que podemos obter rapidamente é verificando os arquivos de log e consultando o sistema para processos de execução (ou sua ausência) e verificando o estado relatado, para se aproximar do problema. Para fazer isso de maneira eficaz, precisamos conhecer os serviços que estamos executando: onde eles escrevem seus arquivos de log, como
Podemos obter informações sobre o estado deles e saber o que está registrado nos tempos de operação normal também ajuda muito a identificar um problema - talvez mesmo antes de o próprio serviço ter problemas.

Existem muitas ferramentas que nos ajudam a automatizar a maioria dessas coisas, como um subsistema de monitoramento e soluções de agregação de log, mas tudo isso começa conosco, os administradores que sabem como os serviços que executamos
trabalho, onde e o que verificar se eles são saudáveis. As ferramentas simples acima demonstradas são acessíveis em qualquer distribuição e, com a ajuda deles, podemos ajudar a resolver problemas com sistemas, não somos
mesmo familiarizado com. Esse é um nível avançado de solução de problemas, mas as ferramentas e seu uso mostrado aqui são alguns dos tijolos que qualquer um pode usar para começar a criar suas habilidades de solução de problemas no GNU/Linux.

Tutoriais do Linux relacionados:

  • Coisas para instalar no Ubuntu 20.04
  • Coisas para fazer depois de instalar o Ubuntu 20.04 fossa focal linux
  • Uma introdução à automação, ferramentas e técnicas do Linux
  • Download do Linux
  • Coisas para fazer depois de instalar o Ubuntu 22.04 Jellyfish…
  • Lista das melhores ferramentas Kali Linux para testes de penetração e…
  • Instale Arch Linux na estação de trabalho VMware
  • Melhor distro Linux para desenvolvedores
  • Arquivos de configuração do Linux: os 30 primeiros mais importantes
  • Comandos Linux: os 20 comandos mais importantes que você precisa para…