Comandos Linux essenciais para administrar servidores

Você abre o terminal, conecta num servidor em produção e recebe aquela mensagem: Active: failed (Result: exit-code). O serviço caiu, mas ninguém sabe desde quando nem por quê. Ou então um colega passa o problema pra você com um "tá lento" que não explica nada — e você precisa descobrir o que está consumindo CPU, memória ou disco sem ter um painel instalado.

É nessa hora que os comandos de administração fazem diferença. Não os básicos de navegação — esses o post sobre Linux para iniciantes já cobre — mas os comandos que você usa quando precisa entender o que está acontecendo num servidor real, em produção, agora.

systemctl — controle de serviços no systemd

O systemctl é a interface de linha de comando para o systemd, o init system padrão em Debian, Ubuntu, RHEL, Fedora e derivados. Com ele você inicia, para, reinicia e inspeciona o estado de qualquer serviço.

# Verificar estado de um serviço
systemctl status nginx

# Iniciar, parar, reiniciar
systemctl start nginx
systemctl stop nginx
systemctl restart nginx

# Reload sem downtime (quando o serviço suporta)
systemctl reload nginx

# Habilitar na inicialização / desabilitar
systemctl enable nginx
systemctl disable nginx

# Listar todos os serviços e seus estados
systemctl list-units --type=service

# Listar apenas os que falharam
systemctl --failed

O systemctl status merece atenção especial — ele mostra as últimas linhas de log do serviço direto no terminal, o que muitas vezes já responde o problema sem precisar ir ao journalctl:

● nginx.service - A high performance web server
   Loaded: loaded (/lib/systemd/system/nginx.service; enabled)
   Active: active (running) since Fri 2026-06-13 10:42:15 UTC; 2h 3min ago
 Main PID: 1234 (nginx)

Se Active mostra failed, o próximo passo é journalctl.

journalctl — logs do systemd sem mistério

O journalctl lê os logs do systemd journal — binário, indexado, com filtros poderosos. Não é substituto de /var/log, mas para serviços gerenciados pelo systemd é muito mais prático.

# Logs de um serviço específico
journalctl -u nginx

# Follow (equivalente ao tail -f)
journalctl -u nginx -f

# Últimas 100 linhas
journalctl -u nginx -n 100

# Desde o último boot
journalctl -u nginx -b

# Intervalo de tempo
journalctl -u nginx --since "2026-06-13 10:00" --until "2026-06-13 11:00"

# Só erros e críticos
journalctl -u nginx -p err

# Sem paginação (útil em scripts)
journalctl -u nginx --no-pager

Quando um serviço falha e você quer ver exatamente o que aconteceu no momento do crash:

journalctl -u nginx -b -1
# -b -1 = boot anterior (útil quando o servidor reiniciou por causa da falha)

O journalctl também funciona sem -u para ver o log do sistema inteiro — mas é verboso demais para uso rotineiro. Use filtros.

ps — processos em execução

O ps lista processos. Sem argumentos é inútil — mostra só os processos da sessão atual. Com os flags certos, se torna o primeiro comando que você roda quando algo consome recurso de forma inesperada.

# Lista completa de todos os processos
ps aux

# Ordenar por uso de CPU (maior no topo)
ps aux --sort=-%cpu | head -20

# Ordenar por memória
ps aux --sort=-%mem | head -20

# Ver árvore de processos (quem gerou quem)
ps auxf

# Filtrar por nome de processo
ps aux | grep nginx

# Só o PID de um processo
pgrep nginx

O formato aux detalha: USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND. O campo STAT vale atenção:

• R — rodando ou na fila de CPU
• S — dormindo (aguardando evento, normal)
• D — dormindo ininterrupto (geralmente aguardando I/O de disco — preocupante se há muitos)
• Z — zombie (processo filho que terminou mas o pai não coletou o exit code)

Muitos processos D é sinal de I/O saturado. Muitos Z é sinal de bug na aplicação que não faz wait() nos filhos.

df e du — disco

df mostra o espaço disponível por partição. du mostra quanto cada diretório está usando. Os dois juntos resolvem o "disco cheio" sem precisar de ferramenta externa.

# Espaço em disco por partição (human-readable)
df -h

# Incluindo tipo de sistema de arquivos
df -hT

# Verificar inodes (outra forma de "disco cheio")
df -i

Exemplo de saída:

Filesystem      Size  Used Avail Use% Mounted on
/dev/sda1        50G   47G  3.1G  94% /
/dev/sda2       200G   80G  120G  40% /data
tmpfs           1.9G     0  1.9G   0% /dev/shm

Quando df -h mostra 94% e você precisa saber o que está ocupando:

# Top 20 diretórios por tamanho a partir de /var
du -h /var --max-depth=2 | sort -rh | head -20

# Arquivos maiores que 100MB em /var/log
find /var/log -size +100M -type f

Disco cheio por inodes (Use% no df -i chegando a 100%) é uma armadilha menos óbvia — você tem espaço em bytes mas não consegue criar novos arquivos porque acabaram os inodes disponíveis. Acontece com frequência em servidores com muitos arquivos pequenos (filas de e-mail, sessões PHP, caches de objetos).

ss — conexões de rede

O ss é o substituto moderno do netstat. Mais rápido, mais informação, mesma lógica de flags.

# Todas as conexões TCP e UDP em listening ou estabelecidas
ss -tuln

# Incluindo o processo que está escutando
ss -tulnp

# Conexões estabelecidas (o que está conectado agora)
ss -tn state established

# Ver quem está na porta 80
ss -tlnp sport = :80

# Contar conexões por estado
ss -tan | awk '{print $1}' | sort | uniq -c | sort -rn

O último comando é útil para diagnosticar sobrecarga: se você vê milhares de conexões em TIME_WAIT ou CLOSE_WAIT, o problema costuma estar no gerenciamento de conexões da aplicação ou nas configurações do kernel TCP.

Para investigar um processo específico:

# Ver todas as conexões abertas pelo nginx (PID 1234)
ss -tp | grep pid=1234

grep — filtrar sem perder a cabeça

O grep não precisa de apresentação, mas em administração de servidores o que importa é saber combinar flags para extrair sinal do ruído dos logs.

# Linhas com ERROR nos últimos logs do nginx
grep "ERROR" /var/log/nginx/error.log

# Case-insensitive
grep -i "error" /var/log/app/app.log

# Com 3 linhas de contexto (antes e depois)
grep -C 3 "Connection refused" /var/log/app/app.log

# Contar ocorrências
grep -c "404" /var/log/nginx/access.log

# Inverter (linhas que NÃO contêm)
grep -v "GET /health" /var/log/nginx/access.log

# Recursivo em diretório
grep -r "database connection" /var/log/

# Mostrar só o nome do arquivo (útil com -r)
grep -rl "CRITICAL" /var/log/

# IPs que mais aparecem no access log
grep -oP '^\d+\.\d+\.\d+\.\d+' /var/log/nginx/access.log | sort | uniq -c | sort -rn | head -10

Combinar grep com journalctl é o fluxo mais comum na prática:

journalctl -u postgresql --no-pager | grep -i "fatal\|error\|could not"

Combinando os comandos: troubleshooting real

Um cenário típico: deploy novo foi pra produção e o serviço está respondendo lento. Em sequência:

# 1. O serviço está de pé?
systemctl status myapp

# 2. Tem erros recentes no log?
journalctl -u myapp -n 50 --no-pager | grep -i "error\|warn\|fatal"

# 3. Qual é o processo mais pesado?
ps aux --sort=-%cpu | head -5

# 4. Tem disco sobrando?
df -h

# 5. Conexões acumulando?
ss -tan | awk '{print $1}' | sort | uniq -c | sort -rn

Cinco comandos, dois minutos. Na maioria dos casos, um deles já aponta a causa.

Perguntas frequentes

Qual a diferença entre systemctl restart e systemctl reload?

restart para o serviço e inicia novamente — há um breve momento de downtime. reload pede ao processo que recarregue sua configuração sem encerrar — sem downtime, mas nem todo serviço suporta. O nginx suporta; o PostgreSQL também (com pg_reload_conf()). Se não tiver certeza, use restart.

Como ver os logs de um serviço que travou no boot?

journalctl -u nome-do-servico -b

O -b limita ao boot atual. Se o serviço falhou no boot anterior e o servidor foi reiniciado:

journalctl -u nome-do-servico -b -1

-b -1 é o boot imediatamente anterior ao atual.

O ss substitui completamente o netstat?

Para a maioria dos casos, sim. O netstat já não vem instalado por padrão em muitas distros — faz parte do pacote net-tools, que está em modo de manutenção. O ss lê diretamente do kernel via netlink socket, é mais rápido e tem flags equivalentes (ss -tuln ≈ netstat -tuln). A principal diferença prática é na sintaxe para filtros avançados, onde o ss é mais expressivo.

Como saber quais permissões um arquivo precisa ter em um servidor web?

Essa é uma das dúvidas mais comuns ao configurar nginx ou Apache. Para calcular a notação octal sem fazer conta de cabeça, uso o chmod-calculator — você marca os bits visualmente, vê o resultado em octal e simbólico, e há avisos quando a combinação é insegura (como 777).

O diagnóstico é metade da operação

Servidor quebrado não é exceção — é parte do trabalho. A diferença entre resolver em dois minutos e ficar uma hora tentando está em saber qual comando roda primeiro.

systemctl status pra saber se o serviço está de pé. journalctl -u nome -n 100 pra ver o que aconteceu. ps aux --sort=-%cpu pra saber se tem processo descontrolado. df -h pra checar disco. ss -tuln pra ver o que está escutando.

Esses seis comandos respondem a maioria dos problemas que aparecem num servidor Linux em produção. O resto é variação — flags diferentes, combinações com grep, filtros de tempo no journalctl. A base é essa.

Nota: o conteúdo editorial acabou aqui. O que vem abaixo é uma indicação de ferramenta relacionada ao tema do post.

Ferramenta relacionada

A Calculadora CHMOD do Quick Tools permite configurar permissões de owner, group e others visualmente, mostra o resultado em octal e notação simbólica simultaneamente, inclui suporte a SUID/SGID/sticky bit e exibe avisos quando a combinação escolhida tem implicações de segurança — tudo no browser, sem instalar nada.