Estou confuso. Um de nossos DBAs está relatando um problema com erros de conexão LDAP. Eu imaginei que começaria a traçar isso da treliça para ver exatamente o que está se conectando, mas o que estou vendo não faz sentido para mim.
Este é o extrato completo da saída de treliça referente ao descritor de arquivo 35:
# grep 35 /tmp/11834.2.truss | grep -v write.33
/3: read(35, " 0", 1) = 1
/3: read(35, "\f", 1) = 1
/3: read(35, "020101 '07020103040# grep 35 /tmp/11834.2.truss | grep -v write.33
/3: read(35, " 0", 1) = 1
/3: read(35, "\f", 1) = 1
/3: read(35, "020101 '07020103040%pre%", 12) = 12
/9: write(35, " 084%pre%%pre%0020101 a84%pre%".., 22) = 22
/3: read(35, " 0", 1) = 1
/3: read(35, "81", 1) = 1
/3: read(35, "9E", 1) = 1
/3: read(35, "020102 c819804 : c n = a".., 158) = 158
/9: write(35, " 084%pre%%pre%1 8020102 d84%pre%".., 340) = 340
/3: read(35, " 0", 1) = 1
/3: read(35, "05", 1) = 1
/3: read(35, "020103 B%pre%", 5) = 5
/3: close(35) = 0
/6: read(35, " 0", 1) = 1
/6: read(35, "\f", 1) = 1
/6: read(35, "020101 '07020103040%pre%", 12) = 12
/8: write(35, " 084%pre%%pre%0020101 a84%pre%".., 22) = 22
/6: read(35, " 0", 1) = 1
/6: read(35, "81", 1) = 1
/6: read(35, "98", 1) = 1
/6: read(35, "020102 c819204 4 c n = M".., 152) = 152
/9: write(35, " 084%pre%%pre%1 @020102 d84%pre%".., 348) = 348
/6: read(35, " 0", 1) = 1
/6: read(35, "05", 1) = 1
/6: read(35, "020103 B%pre%", 5) = 5
/6: close(35) = 0
/6: read(35, 0x7FFFEFB4FFB4B, 1) Err#131 ECONNRESET
/6: close(35) = 0
/6: read(35, " 0", 1) = 1
/6: read(35, "\f", 1) = 1
/6: read(35, "020101 '07020103040%pre%", 12) = 12
/8: write(35, " 084%pre%%pre%0020101 a84%pre%".., 22) = 22
/6: read(35, " 0", 1) = 1
/6: read(35, "81", 1) = 1
/6: read(35, "A3", 1) = 1
/6: read(35, "020102 c819D04 ? c n = a".., 163) = 163
/8: write(35, " 084%pre%%pre%1 B020102 d84%pre%".., 350) = 350
/6: read(35, " 0", 1) = 1
/6: read(35, "05", 1) = 1
/6: read(35, "020103 B%pre%", 5) = 5
/6: close(35) = 0
", 12) = 12
/9: write(35, " 084%pre%%pre%0020101 a84%pre%".., 22) = 22
/3: read(35, " 0", 1) = 1
/3: read(35, "81", 1) = 1
/3: read(35, "9E", 1) = 1
/3: read(35, "020102 c819804 : c n = a".., 158) = 158
/9: write(35, " 084%pre%%pre%1 8020102 d84%pre%".., 340) = 340
/3: read(35, " 0", 1) = 1
/3: read(35, "05", 1) = 1
/3: read(35, "020103 B%pre%", 5) = 5
/3: close(35) = 0
/6: read(35, " 0", 1) = 1
/6: read(35, "\f", 1) = 1
/6: read(35, "020101 '07020103040%pre%", 12) = 12
/8: write(35, " 084%pre%%pre%0020101 a84%pre%".., 22) = 22
/6: read(35, " 0", 1) = 1
/6: read(35, "81", 1) = 1
/6: read(35, "98", 1) = 1
/6: read(35, "020102 c819204 4 c n = M".., 152) = 152
/9: write(35, " 084%pre%%pre%1 @020102 d84%pre%".., 348) = 348
/6: read(35, " 0", 1) = 1
/6: read(35, "05", 1) = 1
/6: read(35, "020103 B%pre%", 5) = 5
/6: close(35) = 0
/6: read(35, 0x7FFFEFB4FFB4B, 1) Err#131 ECONNRESET
/6: close(35) = 0
/6: read(35, " 0", 1) = 1
/6: read(35, "\f", 1) = 1
/6: read(35, "020101 '07020103040%pre%", 12) = 12
/8: write(35, " 084%pre%%pre%0020101 a84%pre%".., 22) = 22
/6: read(35, " 0", 1) = 1
/6: read(35, "81", 1) = 1
/6: read(35, "A3", 1) = 1
/6: read(35, "020102 c819D04 ? c n = a".., 163) = 163
/8: write(35, " 084%pre%%pre%1 B020102 d84%pre%".., 350) = 350
/6: read(35, " 0", 1) = 1
/6: read(35, "05", 1) = 1
/6: read(35, "020103 B%pre%", 5) = 5
/6: close(35) = 0
Se eu executar pfiles no processo durante esse tempo, o FD35 nunca será visto. E pelo que eu posso dizer na saída da treliça, ela nunca é aberta, mas é lida, gravada e fechada duas vezes durante esse rastreio, e continua sendo usada posteriormente. Gostaria de saber com o que está falando para executar um rastreamento de rede ...
Alguém já viu algo assim antes e poderia ajudar a explicar isso? Deve admitir, a política da empresa de "se não está quebrado, não consertá-lo" pode estar entrando em jogo aqui ...
Qualquer informação muito apreciada.
Um processo não precisa abrir um fd para poder usá-lo.
Funciona se o processo pai permitir que o filho herde o descritor de arquivo aberto.
BTW: Eu confiaria em truss e verificaria /proc/<pid>/fd/ para uma lista de descritores de arquivos abertos.
Os comentários de Schily estão certos para o que estava acontecendo. Eu vou expandir um pouco embora.
O descritor de arquivos estava sendo herdado do zsched. A execução de "data; pfiles" dentro de um loop while real mostrou o descritor de arquivo, embora não permita que uma treliça rastreie o mesmo processo ao mesmo tempo. No entanto, ele me mostrou qual cliente estava se conectando no momento em que o erro ocorreu.
Não é possível espionar o adaptador de rede dentro da zona local. Indo para a região global, fui capaz de espionar o tráfego indo para a porta específica naquele adaptador de rede. Isso me permitiu rastrear o problema e identificar o problema usando o Wireshark.