Вопрос или проблема
Я просто пытался выполнить grep в syslog, когда наткнулся на следующее:
$ grep -E 'Sep.*EXT4' /var/log/syslog
[... некоторые данные ...]
grep: /var/log/syslog: бинарный файл соответствует
ИЗМЕНЕНИЕ: первая попытка использовала cmp и strings, но это дало неверные результаты для UTF-8.
$ \zgrep -C 2 -Pan '\x00' /var/log/syslog* | cat -vET
/var/log/syslog.1-8236-Sep 23 11:59:12 jakub-Latitude-5431 rtkit-daemon[1824]: Успешно создал поток 11652 процесса 6125, принадлежащий '1000' RT с приоритетом 10.$
/var/log/syslog.1-8237-Sep 23 11:59:12 jakub-Latitude-5431 rtkit-daemon[1824]: Наблюдает за 10 потоками 7 процессов 1 пользователя.$
/var/log/syslog.1:8238:^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@Sep 23 12:03:51 jakub-Latitude-5431 systemd-modules-load[915]: Вставлен модуль 'lp'$
/var/log/syslog.1-8239-Sep 23 12:03:51 jakub-Latitude-5431 systemd-modules-load[915]: Вставлен модуль 'ppdev'$
/var/log/syslog.1-8240-Sep 23 12:03:51 jakub-Latitude-5431 lvm[907]: Объём "vgubuntu" проверяет 2 логических тома$
/var/log/syslog.2.gz-19151-Sep 13 17:13:03 jakub-Latitude-5431 kernel: [371517.143856] audit: type=1400 audit(1726240383.797:15759): apparmor="DENIED" operation="open" class="file" profile="snap.firefox.firefox" name="/etc/fstab" pid=389526 comm="firefox" requested_mask="r" denied_mask="r" fsuid=1000 ouid=0$
/var/log/syslog.2.gz-19152-Sep 13 17:13:03 jakub-Latitude-5431 kernel: [371517.149625] audit: type=1400 audit(1726240383.802:15760): apparmor="DENIED" operation="open" class="file" profile="snap.firefox.firefox" name="/etc/fstab" pid=389526 comm="firefox" requested_mask="r" denied_mask="r" fsuid=1000 ouid=0$
/var/log/syslog.2.gz:19153:^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@Sep 13 17:31:40 jakub-Latitude-5431 systemd-modules-load[981]: Вставлен модуль 'lp'$
/var/log/syslog.2.gz-19154-Sep 13 17:31:40 jakub-Latitude-5431 systemd-modules-load[981]: Вставлен модуль 'ppdev'$
/var/log/syslog.2.gz-19155-Sep 13 17:31:40 jakub-Latitude-5431 systemd-modules-load[981]: Вставлен модуль 'parport_pc'$
Я не уверен, что здесь произошло? Я не думаю, что это нормально, когда syslog содержит бинарные символы.
Неверный символ здесь – это нулевой байт
... QVariant(QByteArray, "/home/jakub/Downloads\x00")) ...
Моя ошибка, нулевой байт на самом деле находится в другом месте. "/home/jakub/Downloads\x00" все еще является ошибкой в программе, которая печатала журнал, но это не относится к нулевому байту в вашем файле syslog
Здесь вы использовали strings, что является неправильным инструментом для обнаружения нулевых байтов, потому что GNU strings по умолчанию работает только с символами ASCII. Вы можете легко это проверить
$ printf "Panzerjäger\nHello\nW\0rld\nSchön\nНеверная UTF-8 строка \342\313\n" | strings
Panzerj
Hello
Неверная UTF-8
строка
$ printf "Panzerjäger\nHello\nW\0rld\nSchön\nНеверная UTF-8 строка \342\313\n" | strings -e S
Panzerjäger
Hello
Schön
Неверная UTF-8 �� строка
xxd -p -l3 -s 249932 /var/log/syslog возвращает c3a467, что является кодировкой äg в Panzerjäger, что является первым непечатаемым символом согласно strings, когда он использует 7-битную кодировку ASCII. -e S указывает на 8-битную кодировку и может напечатать символы с установленным высоким битом. BSD strings по умолчанию использует 8-битную кодировку, поэтому вы получите Panzerjäger вместо Panzerj
grep сообщит binary file matches, если обнаружит файл с (1) нулевыми байтами или (2) недопустимыми байтовыми последовательностями в кодировке текущей локали. Поскольку большинство локалей в настоящее время используют UTF-8, вы можете легко проверить случай (2) с любыми инструментами обработки текста в Linux1. Самый простой способ – использовать grep -axv '.*' your/log/file
$ printf "Panzerjäger\nHello\nW\0rld\nSchön\nНеверная UTF-8 строка \342\313\n" | grep -axv '.*'
Неверная UTF-8 �� строка
Однако эти методы не сообщат о нулевых байтах, потому что они являются допустимыми в UTF-8 и практически в любой другой кодировке. Чтобы искать (1) строки, содержащие нулевые байты, вам понадобятся некоторые другие решения:
$ printf "Panzerjäger\nHello\nW\0rld\nSchön\nНеверная UTF-8 строка \342\313\n" | \grep -Pan '\x00' | cat -vET
3:W^@rld$
grep -n выведет номер строки, содержащей нулевой байт (3), а cat -vET выведет его в эскейпированной форме для удобства чтения, поэтому вы можете просто использовать \grep -Pan '\x00' your/log/file | cat -vET
Существует 2 возможные причины появления нулевых байтов
- Система была резко отключена, поэтому не было возможности сбросить буфер. Я регулярно вижу это на своих встроенных SBC. Между последней сброшенной строкой журнала и следующим загрузочным журналом появится много нулевых байтов. Но, похоже, это не так в вашем выводе
- Строка фактически содержит встроенные нули.
QStringможет это сделать так же как иstd::string, поэтому, если строка была прочитана неправильно с финальным нулевым байтом или нулевой байт был вставлен каким-то образом, тогда он будет выведен в журнале. Это ошибка, но пока это не вредно
В любом случае это еще не является проблемой. Обычно вы хотите использовать grep -a для поиска в журналах, чтобы избежать подобных сообщений
1 Смотрите также
Ответ или решение
Когда вы видите сообщение grep: /var/log/syslog: binary file matches, это обычно указывает на то, что файл, который вы пытаетесь просмотреть, содержит байты, которые grep рассматривает как бинарные данные. В данном случае это может быть связано с наличием нулевых байтов в логе или некорректными последовательностями байтов в кодировке, используемой в вашей системе.
Возможные причины
-
Наличие нулевых байтов: Как вы заметили, наличие нулевых байтов в текстовом файле действительно может вызывать такие предупреждения. Нулевые байты могут появляться по разным причинам, например, если система была неожиданно выключена или если какое-то приложение неправильно записало данные в журнал.
-
Некорректная кодировка: Если в файле имеются последовательности байтов, которые не соответствуют ожидаемой кодировке (например, UTF-8),
grepможет распознавать это как бинарный файл. Это часто происходит, когда программа, записывающая данные в лог, ошибается и помещает в ногу некорректные данные.
Рекомендации по диагностике
-
Проверка наличия нулевых байтов: Используйте команду
grep -a -P '\x00' /var/log/syslog, чтобы проверить наличие нулевых байтов в логах, и в случае их нахождения можно более детально изучить строки, в которых они находятся. -
Проверка кодировки: Используйте инструменты, такие как
iconv, чтобы проверить и преобразовать остатки вашего файла в другую кодировку, что может помочь выявить проблемы с кодировкой. -
Регулярный обход логов: Если вы часто работаете с логами, используйте опцию
-aв командеgrep, чтобы избежать сообщений о бинарных данных. Это превращает бинарные файлы в текстовые и помогает фильтровать вывод.
Выводы
С одной стороны, наличие таких сообщений может вызывать беспокойство, но это не обязательно указывает на критическую проблему. В большинстве случаев это можно рассматривать как незначительное предупреждение, которое не повлияет на работу вашей системы. Однако стоит рассмотреть возможность недочетов в программном обеспечении, если затрагиваются такие ошибки. Если же эта проблема повторяется и у вас есть подозрения на более серьезные неисправности, рекомендуется провести дополнительный аудит системных логов и может быть даже провести диагностику работы самого приложения, создавшего эти логи.
Подводя итог, на данный момент вам не стоит сильно беспокоиться, но, безусловно, будет полезно провести дальнейшую проверку, чтобы убедиться, что все в порядке.