- O que isto significa?
- Como
lsof
encontrar tais FDs? Ou seja, em comparação com FDs normais, que podem ser encontrados facilmente como arquivosls -l /proc/$PID/fd/$FD
.
$ lsof -p $(pgrep pulseaudio) | head -n1
COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME
$ lsof -p $(pgrep pulseaudio) | grep DEL
pulseaudi 25911 alan-sysop DEL REG 0,5 2334404 /memfd:pulseaudio
pulseaudi 25911 alan-sysop DEL REG 0,5 2340448 /memfd:pulseaudio
pulseaudi 25911 alan-sysop DEL REG 0,5 2335426 /memfd:pulseaudio
pulseaudi 25911 alan-sysop DEL REG 0,5 2340018 /memfd:pulseaudio
pulseaudi 25911 alan-sysop DEL REG 0,5 2340021 /memfd:pulseaudio
pulseaudi 25911 alan-sysop DEL REG 0,5 2334322 /memfd:pulseaudio
pulseaudi 25911 alan-sysop DEL REG 0,5 2336421 /memfd:pulseaudio
man lsof
documenta apenas um DEL
valor para a TYPE
coluna, não a FD
coluna.
https://stackoverflow.com/a/37160579/1601027 , conforme apontado por @don_crissti.
lsof
não pode mostrar o tamanho desses arquivos, mesmo quando executado como root. (A minhalsof
é a versão 4.89).No entanto, se você tiver um kernel novo e
root
acesso suficiente, poderá ver os mapas emls -l /proc/$PID/map_files/
, e poderá executarstat --dereference
arquivos individuais para mostrar seu tamanho. Isso pode ser usado para inspecionar os recursos usados pelos arquivos mapeados "excluídos". Em particularmemfd
s, que nunca aparecem no sistema de arquivos e são sempre considerados como(deleted)
arquivos.Por exemplo, pelo menos foi possível ver que nenhum memfd individual, pelo menos mantido diretamente por um FD ou por um mapeamento de memória, estava consumindo gigabytes por conta própria. Ainda seria bom ter algumas ferramentas ou scripts melhores em torno disso.