Linux e linha de comando
Processos, permissões, sinais e as ferramentas para investigar um servidor em produção.
Por que Linux importa para quem escreve backend
Os servidores, as máquinas virtuais da nuvem e os containers rodam, quase todos, Linux. Mesmo quem desenvolve em macOS ou Windows coloca o código para rodar num Linux. Quando um serviço para de responder em produção, a investigação acontece numa linha de comando Linux, e muitas causas não estão no código: estão no sistema operacional.
Este tópico cobre os conceitos que mais aparecem nessas investigações.
Processos
Um processo é um programa em execução. Cada um tem um número (o PID), um processo pai, um usuário dono, variáveis de ambiente, arquivos abertos e um estado.
| Estado | Significado |
|---|---|
R (running) | Executando ou pronto para executar |
S (sleeping) | Esperando algo: uma resposta da rede, um arquivo, um temporizador |
D | Esperando entrada e saída que não pode ser interrompida, em geral de disco |
Z (zombie) | Já terminou, mas o pai ainda não leu o código de saída |
T | Parado, por exemplo por um depurador |
Um serviço "travado" quase sempre está em S, esperando alguma coisa. A pergunta passa a ser esperando o quê, e as ferramentas do nível Implementação respondem.
Tudo é arquivo
No Linux, muita coisa é tratada como arquivo: arquivos de verdade, mas também conexões de rede, a saída do terminal, dispositivos e até informações sobre os processos. Cada arquivo aberto por um processo recebe um número, o descritor de arquivo:
| Descritor | O que é |
|---|---|
| 0 | Entrada padrão (stdin) |
| 1 | Saída padrão (stdout) |
| 2 | Saída de erros (stderr) |
| 3 em diante | Arquivos, conexões de rede e outros recursos abertos pelo programa |
A pasta /proc é um sistema de arquivos virtual que expõe o estado de cada processo. /proc/<pid>/fd lista os descritores abertos, /proc/<pid>/status mostra memória e estado, /proc/<pid>/environ as variáveis de ambiente.
O limite de arquivos abertos
Cada processo tem um limite de descritores que pode abrir ao mesmo tempo. Como conexões de rede contam nesse limite, um servidor com muitas conexões, ou um código que esquece de fechar arquivos, chega nele.
Reproduzimos num container com o limite em 100:
| Código | Resultado |
|---|---|
Abre e fecha o arquivo a cada vez (with open(...)) | 500 aberturas sem erro |
| Abre e nunca fecha | Falhou na abertura 98 com Too many open files |
Foi na 98ª, e não na 100ª, porque os descritores 0, 1 e 2 já estavam ocupados. Em produção, o mesmo erro aparece quando um serviço vaza conexões com o banco ou arquivos, e passa a recusar conexões novas.
Sinais
Um sinal é uma notificação enviada a um processo pelo sistema ou por outro processo. Os mais importantes para backend:
| Sinal | Número | Quem envia | Significado |
|---|---|---|---|
SIGTERM | 15 | kill, docker stop, Kubernetes | Peça educada para terminar; o processo pode tratar e encerrar com calma |
SIGINT | 2 | Ctrl+C no terminal | Interromper |
SIGKILL | 9 | kill -9, o sistema por falta de memória, o orquestrador depois do prazo | Termina na hora; não pode ser tratado nem ignorado |
SIGHUP | 1 | Fechamento do terminal; muitos servidores usam para recarregar a configuração | Depende do programa |
Testamos a diferença: um processo comum terminou com SIGTERM. Um processo programado para ignorar o SIGTERM continuou vivo depois dele, e só terminou com SIGKILL.
Por isso o encerramento gracioso, visto no tópico de escalabilidade, trata o SIGTERM: é a única chance de terminar os pedidos em andamento. Depois do prazo, vem o SIGKILL, e nada mais é executado.
Usuários e permissões
Todo arquivo tem um dono, um grupo e permissões para três públicos: o dono, o grupo e os outros.
drwxr-xr-x 2 root root 4096 /dados
│└┬┘└┬┘└┬┘ │ │
│ │ │ │ │ └── grupo dono
│ │ │ │ └─────── usuário dono
│ │ │ └── outros: r-x (ler e entrar, sem gravar)
│ │ └───── grupo: r-x
│ └──────── dono: rwx (ler, gravar, executar)
└────────── d = diretórioProcessos rodam como um usuário, e só podem fazer o que as permissões desse usuário permitem. O usuário root (UID 0) pode tudo.
A combinação mais comum de problema em containers: a imagem roda a aplicação como um usuário sem privilégios, como recomenda o tópico de containers, e um volume montado pertence ao root. Reproduzimos: com o diretório /dados pertencente ao root e com permissão 755, um processo com UID 1000 recebeu Permission denied ao tentar criar um arquivo.
Disco e sistemas de arquivos
| Problema | Como aparece |
|---|---|
| Disco cheio | No space left on device em qualquer gravação: logs, banco, uploads, arquivos temporários |
| Inodes esgotados | O mesmo erro com espaço sobrando, por excesso de arquivos pequenos |
| Arquivo apagado ainda aberto | O espaço não volta: o arquivo só é liberado quando o último processo o fecha |
Reproduzimos o primeiro num sistema de arquivos de 1 MB: a gravação de logs falhou com No space left on device quando o uso chegou a 100%. Em servidores, a causa mais comum é log sem rotação.
Código de saída
Todo processo termina com um número de 0 a 255. Zero é sucesso; qualquer outro valor é falha. Alguns valores têm significado fixo:
| Código | Significado |
|---|---|
| 0 | Sucesso |
| 1 | Erro genérico da aplicação |
| 126 | O comando existe, mas não pode ser executado (permissão) |
| 127 | Comando não encontrado |
| 128 + N | Terminado pelo sinal N: 130 é Ctrl+C (SIGINT), 137 é SIGKILL, 143 é SIGTERM |
Um container que saiu com 137 foi morto à força: por falta de memória, como no tópico de gerenciamento de memória, ou por não ter encerrado dentro do prazo depois do SIGTERM.
Por que isso importa quando a IA escreve o código
Assistentes escrevem código que funciona na máquina do desenvolvedor, onde os limites são folgados e o usuário é administrador. Em produção:
- Arquivos e conexões abertos sem fechamento garantido esgotam os descritores sob carga.
- O código grava em pastas que o usuário do container não pode escrever.
- Logs gravados em arquivo, sem rotação, enchem o disco em semanas.
- A sugestão para um erro de permissão é rodar como root ou
chmod 777. - O código de saída do processo não reflete o erro, e o orquestrador não sabe que algo falhou.
O próximo nível organiza as ferramentas de investigação e as configurações que evitam esses problemas.
Prompts para aprofundar
Ao abrir no ChatGPT ou no Claude, o prompt é enviado ao serviço escolhido pela URL e também fica copiado na sua área de transferência.
Linux para backend em cinco minutos
Explique em no máximo cinco minutos de leitura os conceitos de Linux que mais importam para quem escreve backend, para alguém que só usa o terminal para rodar comandos prontos. Cubra só o essencial: processos e seus estados, descritores de arquivo e o limite de arquivos abertos, sinais (SIGTERM e SIGKILL), permissões e códigos de saída. No final, me faça três perguntas curtas para eu verificar se entendi, e corrija as minhas respostas.
Processos, sinais e códigos de saída
Quero entender o ciclo de vida de um processo no Linux. Aja como um mentor. Pergunte primeiro qual é a minha experiência com Linux. Conduza assim, uma etapa por vez: 1. O que é um processo, PID, processo pai e os estados (R, S, D, Z, T). 2. O que são sinais, os principais (SIGTERM, SIGINT, SIGKILL, SIGHUP) e por que o SIGKILL não pode ser tratado. 3. Códigos de saída: 0, 1, 126, 127 e a regra de 128 mais o número do sinal. 4. Como tudo isso funciona dentro de um container, com o PID 1. Em cada etapa, me proponha um comando para rodar num container e peça que eu preveja o resultado antes.
Tudo é arquivo
Quero entender a ideia de que no Linux tudo é arquivo, e o que isso significa para um servidor. Explique: 1. O que é um descritor de arquivo e o que são os descritores 0, 1 e 2. 2. Por que conexões de rede também são descritores. 3. O limite de arquivos abertos por processo e o que acontece quando ele é atingido. 4. A pasta /proc e o que ela mostra sobre cada processo. 5. Por que apagar um arquivo aberto não libera o espaço em disco. Depois me descreva três situações de produção e pergunte qual é a causa provável e como confirmar. Corrija as minhas respostas.
Permissões sem chmod 777
Quero entender permissões no Linux para resolver erros de "Permission denied" do jeito certo. Explique: 1. Dono, grupo, outros, e as permissões de leitura, gravação e execução, com a notação simbólica e a numérica. 2. O que a permissão de execução significa num diretório. 3. O usuário root e o UID. 4. Por que containers que rodam sem root encontram erros de permissão em volumes. 5. Por que chmod 777 e rodar como root são más correções. Depois me mostre quatro cenários de erro de permissão e pergunte qual seria a correção adequada em cada um. Corrija as minhas respostas.