Filesystem escreve aparentemente perdido

Question

Eu tenho experimentado com o tcpdump e descobri um comportamento muito estranho do sistema de arquivos. Não parece ser um problema tcpdump como explicarei em um segundo.

O seguinte comando não produz nenhum arquivo:

tcpdump -w test.pcap

No entanto, este comando produz o arquivo PCAP como esperado:

tcpdump -w - > test.pcap

No começo eu percebi que o tcpdump deve estar encontrando algum erro ao escrever o arquivo que o shell não estava, então eu me esforcei e descobri que as gravações estavam ocorrendo muito bem!

open("test.pcap", O_WRONLY|O_CREAT|O_TRUNC, 0666) = 4 
fstat(4, {st_mode=S_IFREG|0644, st_size=0, ...}) = 0 
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7ff9bf5cb000
rt_sigaction(SIGUSR1, {0x4557d0, [], SA_RESTORER, 0x7ff9bea2ab60}, {SIG_DFL, [], 0}, 8) = 0 
write(2, "tcpdump: ", 9tcpdump: )                = 9 
write(2, "listening on eth0, link-type EN1"..., 73listening on eth0, link-type EN10MB (Ethernet), capture size 65535 bytes) = 73
poll([{fd=3, events=POLLIN}], 1, 1000)  = 1 ([{fd=3, revents=POLLIN}])
poll([{fd=3, events=POLLIN}], 1, 1000)  = 1 ([{fd=3, revents=POLLIN}])
poll([{fd=3, events=POLLIN}], 1, 1000)  = 1 ([{fd=3, revents=POLLIN}])
write(4, "4321
tcpdump version 4.3.0
libpcap version 1.3.0
GNU bash, version 4.2.37(1)-release (x86_64-pc-linux-gnu)
Linux persephone 3.4.9-gentoo #1 SMP Wed Oct 3 10:02:39 EDT 2012 x86_64 Intel(R) Xeon(R) CPU E5645 @ 2.40GHz GenuineIntel GNU/Linux
tcpdump -w test.pcap
tcpdump -w - > test.pcap
open("test.pcap", O_WRONLY|O_CREAT|O_TRUNC, 0666) = 4 
fstat(4, {st_mode=S_IFREG|0644, st_size=0, ...}) = 0 
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7ff9bf5cb000
rt_sigaction(SIGUSR1, {0x4557d0, [], SA_RESTORER, 0x7ff9bea2ab60}, {SIG_DFL, [], 0}, 8) = 0 
write(2, "tcpdump: ", 9tcpdump: )                = 9 
write(2, "listening on eth0, link-type EN1"..., 73listening on eth0, link-type EN10MB (Ethernet), capture size 65535 bytes) = 73
poll([{fd=3, events=POLLIN}], 1, 1000)  = 1 ([{fd=3, revents=POLLIN}])
poll([{fd=3, events=POLLIN}], 1, 1000)  = 1 ([{fd=3, revents=POLLIN}])
poll([{fd=3, events=POLLIN}], 1, 1000)  = 1 ([{fd=3, revents=POLLIN}])
write(4, "4321
tcpdump version 4.3.0
libpcap version 1.3.0
GNU bash, version 4.2.37(1)-release (x86_64-pc-linux-gnu)
Linux persephone 3.4.9-gentoo #1 SMP Wed Oct 3 10:02:39 EDT 2012 x86_64 Intel(R) Xeon(R) CPU E5645 @ 2.40GHz GenuineIntel GNU/Linux
%pre%%pre%%pre%%pre%%pre%%pre%%pre%%pre%%pre%77%pre%%pre%%pre%%pre%%pre%010P%pre%"..., 4096) = 4096
poll([{fd=3, events=POLLIN}], 1, 1000)  = 1 ([{fd=3, revents=POLLIN}])
poll([{fd=3, events=POLLIN}], 1, 1000)  = 1 ([{fd=3, revents=POLLIN}])
write(4, "21X3\f9+5\t4QF327Y63l1vQ430i6."..., 4096) = 4096
poll([{fd=3, events=POLLIN}], 1, 1000)  = 1 ([{fd=3, revents=POLLIN}])
poll([{fd=3, events=POLLIN}], 1, 1000)  = 1 ([{fd=3, revents=POLLIN}])
write(4, "66%4021732d1%pre%7wXi'%pre%U00000%pre%51"..., 4096) = 4096
%pre%%pre%%pre%%pre%%pre%%pre%77%pre%%pre%%pre%%pre%%pre%010P%pre%"..., 4096) = 4096
poll([{fd=3, events=POLLIN}], 1, 1000)  = 1 ([{fd=3, revents=POLLIN}])
poll([{fd=3, events=POLLIN}], 1, 1000)  = 1 ([{fd=3, revents=POLLIN}])
write(4, "21X3\f9+5\t4QF327Y63l1vQ430i6."..., 4096) = 4096
poll([{fd=3, events=POLLIN}], 1, 1000)  = 1 ([{fd=3, revents=POLLIN}])
poll([{fd=3, events=POLLIN}], 1, 1000)  = 1 ([{fd=3, revents=POLLIN}])
write(4, "66%4021732d1%pre%7wXi'%pre%U00000%pre%51"..., 4096) = 4096

test.pcap é aberto como descritor de arquivo 4 e, em seguida, várias gravações ocorrem nesse descritor com o syscall relatando que o número de bytes solicitado foi de fato escrito.

Mesmo assim, nenhum arquivo é criado. Eu vasculhei o sistema de arquivos para test.pcap e não encontrei nada.

O que poderia produzir esse comportamento?

%pre%     

Answer 1

tcpdump está fazendo outra coisa no arquivo. Você não diz qual é a linha de comando completa; talvez você tenha um -G lá.

Possíveis maneiras de investigar mais: -

1. Continue procurando na saída strace: talvez você encontre uma renomeação ou desconexão.
2. Enquanto o tcpdump estiver em execução, execute ln test.pcap pin.test.pcap e você poderá dizer se o arquivo foi desvinculado posteriormente.
3. Enquanto o tcpdump está em execução, localize seu ID de processo e ls -l /proc/${pid}/fd para ver se é possível localizar o link para o nome completo do caminho do arquivo aberto. ( Esta é a abordagem que realmente funcionou, a partir do comentário da @Gilles. )