Saída diferente da variante lsof [closed]

0

Eu tenho uma aplicação Java utilizando o driver Java do MongoDB (2.11.3). Estou usando uma instância estática do MongoClient em todo o aplicativo e, conforme declarado nos documentos, ele deve manipular o pool de conexões. Depois de um longo tempo (é um BungeeCord, se você estiver familiarizado com Minecraft) ele lança muitas exceções de arquivos abertos. Dando uma olhada em

$ lsof -p 7616 -n | grep "123.456.7.8:27017" | wc -l
6

nos mostra que existem 16 conexões para a porta 27017. Mas quando olhamos para:

$ lsof -n | grep "123.456.7.8:27017" | awk '{print $2}' | grep 7616 | wc -l
438

nos mostra muito mais conexões do que o primeiro comando.

A primeira pergunta é por que os dois comandos têm saída diferente e o segundo é se alguém experimentou algo semelhante com o driver Java MongoDB.

    
por Christopher 17.01.2015 / 17:13

1 resposta

2

Não posso ter certeza sem ver sua saída real, mas a explicação mais provável é que 27017 aparece em locais diferentes. Seu primeiro comando listará os arquivos para o processo com PID 5253 e, em seguida, imprimirá todas as linhas que contiverem 27017 em qualquer lugar na linha .

Seu segundo comando irá imprimir todos os arquivos abertos e, novamente, você está selecionando todas as linhas que contêm 27017 em qualquer lugar na linha . Eu suponho que você está realmente ganhando 27017 no segundo comando também e não 16062 como você mostra na sua pergunta.

Em qualquer caso, nenhum dos seus comandos está procurando especificamente na porta 27017 . Na verdade, nem vejo por que você espera que uma porta seja listada. lsof procura arquivos, não portas. Nenhuma porta é mostrada quando eu procuro ssh na saída de lsof -n no meu sistema, por exemplo.

De qualquer forma, para dar um exemplo mais concreto:

 
$ sudo lsof -np 7033 | head
lsof: WARNING: can't stat() fuse.gvfsd-fuse file system /run/user/1000/gvfs
      Output information may be incomplete.
COMMAND  PID   USER   FD   TYPE             DEVICE SIZE/OFF      NODE NAME
firefox 7033 terdon  cwd    DIR                8,6   491520  16646145 /home/terdon
firefox 7033 terdon  rtd    DIR                8,7   548864         2 /
firefox 7033 terdon  txt    REG                8,7   143680   1841618 /opt/firefox/firefox
firefox 7033 terdon  DEL    REG               0,30           10335506 /tmp/.glT5RaDf
firefox 7033 terdon  mem    REG                8,7 12303504   1573445 /usr/share/fonts/truetype/unifont/unifont.ttf
firefox 7033 terdon  DEL    REG                0,4          970489906 /SYSV00000000
firefox 7033 terdon  mem    REG                8,7  7470672    540090 /usr/lib/x86_64-linux-gnu/gstreamer-0.10/libgstffmpeg.so
firefox 7033 terdon  mem    REG                8,7  5177387   1580807 /usr/share/fonts/truetype/wqy/wqy-microhei.ttc
firefox 7033 terdon  mem    REG                8,7   120688    532953 /usr/lib/x86_64-linux-gnu/gstreamer-0.10/libgstvideoscale.so

Sua pesquisa por 27017 pode corresponder em qualquer um dos campos. Pode ser o tamanho, ou o PID ou o nó ou qualquer outra coisa. Também poderia fazer parte de outro número. Por exemplo:

$ printf "12345\n12" | grep 12
12345
12

Como você pode ver acima, 12 é correspondido em ambas as linhas, não apenas no segundo em que forma uma palavra. Você pode usar a opção -w para tornar grep compatível apenas com palavras inteiras:

$ printf "12345\n12" | grep -w 12
12

Portanto, como você não está restringindo a saída por PID no segundo comando, seus dois grep s podem estar em qualquer lugar em todas as linhas, então, é claro, você tem saídas diferentes.

    
por 17.01.2015 / 18:19