Файловая система пишет, казалось бы, потерянную

Я экспериментировал с tcpdump, и я нашел очень странное поведение файловой системы. Это не выглядит проблемой tcpdump, как я объясню через секунду.

Следующая команда не создает файл:

tcpdump -w test.pcap 

Однако эта команда создает файл PCAP, как ожидалось:

 tcpdump -w - > test.pcap 

Сначала я понял, что tcpdump должен сталкиваться с некоторой ошибкой при записи файла, который не был оболочкой, поэтому я стеснялся и обнаружил, что записи происходят очень хорошо!

 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, "\324\303\262\241\2\0\4\0\0\0\0\0\0\0\0\0\377\377\0\0\1\0\0\0001\2\210P\34\3\3\0"..., 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, "\232\241\4\17X\213\f9+\225\35\t\364QF\223\242\7\217Y\226\373l\231vQ\354\223\250i\336."..., 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, "\34\226\346%\354\210\342\331\377\373\222d\261\0\5\207wX\6i`\0U\260\350\260\300\250\0\16\335\241"..., 4096) = 4096 

test.pcap открывается как файловый дескриптор 4, а затем к этому дескриптору приходит несколько записей, в которых syscall сообщает, что запрошенное количество байтов было записано.

Тем не менее, файл не создается. Я просмотрел файловую систему для test.pcap и ничего не нашел.

Что может вызвать такое поведение?

 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 

  • Как исследовать случайный сброс на порт TCP-клиента, подключенный через интерфейс loopback к серверу
  • tcpdump: потерянные пакеты
  • Использование tcpdump для извлечения содержимого NFS RPC
  • Как регистрировать доступ всех доменов?
  • Пакеты исходящих соединений tcp dump
  • Почему ядро ​​отбрасывает пакеты?
  • латентность маршрутизатора, измеренная tcpdump, увеличивается
  • iptrace для linux: как я могу отслеживать полное содержимое пакета?
  • One Solution collect form web for “Файловая система пишет, казалось бы, потерянную”

    tcpdump делает что-то еще в файле. Вы не говорите, какая полная командная строка; возможно, у вас есть -G .

    Возможные пути дальнейшего изучения:

    1. Продолжайте смотреть через вывод strace: возможно, вы найдете переименование или отсоединение.
    2. Пока запущен tcpdump, запустите ln test.pcap pin.test.pcap и вы сможете узнать, не был ли файл позже отсоединен.
    3. Пока выполняется tcpdump, найдите его идентификатор процесса и ls -l /proc/${pid}/fd чтобы увидеть, можно ли указать ссылку на полный путь к открытому файлу. ( Это подход, который действительно работал, из комментария @Gilles. )
    Linux и Unix - лучшая ОС в мире.