O que é um descritor de arquivo e por que tudo no Linux é um arquivo

Publicado em 2026-09-12 por frfrand

Un número entero que representa cualquier cosa abierta: archivos, sockets, tuberías, el teclado. Por qué esa abstracción hizo tan potente a Unix, y qué significa "too many open files".

"Em Unix tudo é um arquivo" é uma frase que se repete muito e se explica pouco. O file descriptor é onde essa ideia se torna concreta.

Um número, nada mais

Quando um processo abre algo, o kernel devolve um número inteiro: o descritor. A partir daí, o processo usa esse número para ler, escrever e fechar.

O interessante é o que pode estar por trás desse número: um arquivo em disco, uma conexão de rede, um pipe para outro processo, um dispositivo, o teclado, um temporizador.

A interface é a mesma para todos. Ler de um arquivo e ler de um socket usam a mesma chamada de sistema.

Os três primeiros estão reservados por convenção:

0 entrada padrão 1 saída padrão 2 erro padrão

E os que você abrir depois recebem o número livre mais baixo: 3, 4, 5.

Por que essa abstração é tão poderosa

Porque permite que os programas se combinem sem saber nada uns dos outros.

Quando você escreve algo como isto:

$ cat registro.txt | grep error > saida.txt

o que ocorre é que o shell manipula descritores: conecta a saída de um à entrada do outro por meio de um pipe, e redireciona a saída final para um arquivo.

Nem cat nem grep sabem nada disso. Cada um lê do seu descritor 0 e escreve no seu descritor 1, sem saber o que há do outro lado. Essa é, em essência, a razão pela qual a linha de comando do Unix é componível.

E explica algo que confunde a muita gente: por que os erros não vão pelo pipe. Como vão para o descritor 2 e o pipe conecta o 1, as mensagens de erro continuam aparecendo na tela. Isso é deliberado: permite ver os erros mesmo que você esteja redirecionando a saída.

Muitos arquivos abertos

O erro que tornou o conceito famoso.

Cada processo tem um limite de descritores abertos. Por padrão costuma ser 1024, que para um servidor com muitas conexões fica curto rapidamente.

Ver o limite atual:

ulimit -n

Ver quantos um processo específico tem abertos:

ls /proc/<pid>/fd | wc -l

E ver o quê está aberto, que é o que realmente ajuda:

ls -l /proc/<pid>/fd

Isso mostra cada descritor e para o que aponta. É a forma mais rápida de detectar um vazamento: se você vir centenas de descritores apontando para o mesmo arquivo ou para sockets fechados, há código que abre e não fecha.

Aumentar o limite, e o detalhe que se esquece

Pode-se aumentar em /etc/security/limits.conf, mas há uma armadilha muito comum: isso não se aplica aos serviços do systemd.

Os serviços precisam de seu próprio ajuste:

[Service] LimitNOFILE=65535

É a causa número um de "aumentei o limite e continua falhando".

Um detalhe que surpreende

Se você excluir um arquivo que um processo tem aberto, o espaço não é liberado até que esse processo o feche. O nome desaparece do diretório, mas o conteúdo continua vivo porque há um descritor apontando para ele.

É a explicação do mistério clássico: você apagou um log gigante, o "df" continua mostrando o disco cheio, e o "du" não encontra nada grande. O arquivo existe sem nome, mantido por um descritor.

lsof +L1

lista exatamente esses casos. A solução é reiniciar o processo que o tem aberto, ou pedir que reabra seus logs.