kmsgd Служба журнала сообщений ядра Тип файла: служба Комментарии Это эквивалентно вызову syslog(2)с действием SYSLOG_ACTION_READ. Для чтения этого файла процесс должен иметь права суперпользователя, и только один процесс должен читать этот файл. Этот файл не следует читать, если запущен процесс системного журнала, который использует syslog(2) возможности системных вызовов для регистрации сообщений ядра. /dev/kmsg обеспечивает доступ к тому же буферу журнала ядра, но более простым в использовании способом. Чтения отслеживаются по каждому открытию, поэтому несколько процессов могут читать параллельно, а записи не удаляются из буфера по мере их чтения. /dev/kmsg также обеспечивает доступ на запись в буфер журнала, поэтому его можно использовать для добавления записей в буфер журнала. Что касается того, почему оба присутствуют, и почему один находится в /proc (хотя и не связанном с процессом), а другой в dev, /proc/kmsg — это старый удобный «экспорт» внутренних компонентов ядра, а /dev/kmsg — более поздний вариант. Кроме того, разработанный как удобный интерфейс к буферу журнала. https://www.kernel.org/doc/Documentation/ABI/testing/dev-kmsg Узел символьного устройства /dev/kmsg обеспечивает доступ к пользовательскому пространству в буфер printk ядра. Внедрение сообщений: Каждая запись() в открытый узел устройства помещает запись журнала в буфер printk ядра. Строка журнала может иметь префикс <N> системного журнала, который несет в себе приоритет и возможности системного журнала. Один десятичный префикс состоит из 3 младших битов, обозначающих приоритет системного журнала, и следующих 8 бит, номера функции системного журнала. Если префикс не указан, номер приоритета является приоритетом журнала ядра по умолчанию, а номер объекта установлен на LOG_USER (1). Невозможно внедрить сообщения из пользовательского пространства с номером средства LOG_KERN (0), чтобы гарантировать, что происхождение сообщений всегда можно надежно определить. Доступ к буферу: Каждый read() из открытого узла устройства получает одну запись из буфера printk ядра. Первая функция read(), следующая сразу за open(), всегда возвращает первое сообщение в буфере; нет внутреннего постоянного состояния ядра; многие ридеры могут одновременно открывать устройство и читать с него, не затрагивая других ридеров. Каждый read() получит следующую доступную запись. Если больше нет доступных записей, read() заблокируется, или если используется O_NONBLOCK, возвращается EAGAIN. Сообщения в кольцевом буфере записи перезаписываются целиком, частичные сообщения никогда не принимаются функцией read(). В случае, если сообщения перезаписываются в кольцевом буфере, пока устройство остается открытым, следующий read() вернет -EPIPE, а позиция поиска будет обновлена до следующей доступной записи. Последующие операции чтения() снова вернут доступные записи. В отличие от классического интерфейса syslog(), 64-битные порядковые номера записей позволяют подсчитать количество потерянных записей. сообщения на случай перезаписи буфера. И они позволяют при необходимости переподключиться к буферу и восстановить позицию чтения, не ограничивая интерфейс одним считывателем. Устройство поддерживает поиск по следующим параметрам: SEEK_SET, 0 искать первую запись в буфере SEEK_END, 0 искать последнюю запись в буфере ПОИСК_ДАННЫЕ, 0 искать последнюю запись, доступную на момент последнего выпуска SYSLOG_ACTION_CLEAR. Другие операции поиска или смещения не поддерживаются из-за особого поведения этого устройства. Устройство позволяет читать или записывать только целые сообщения (записи) переменной длины, хранящиеся в кольцевом буфере. Из-за нестандартного поведения также нестандартны значения ошибок. -ESPIPE возвращается для ненулевого смещения. -EINVAL возвращается для других операций, например. SEEK_CUR. Такое поведение и ценности являются историческими и не могут быть изменены без риск нарушения пользовательского пространства. Выходной формат состоит из префикса, содержащего префикс системного журнала, включая приоритет и возможность, 64-битный порядковый номер сообщения и монотонную временную метку в микросекундах, а также поле флага. Все поля разделяются знаком ','. В будущих расширениях перед завершающим знаком ';' могут быть добавлены дополнительные значения, разделенные запятыми. Неизвестные поля и значения следует игнорировать. Текстовая строка, читаемая человеком, начинается сразу после ';' и завершается символом '\n'. Ненадежные значения, полученные от оборудования или других средств, выводятся на печать, поэтому все непечатаемые символы и сам '\' в сообщении журнала экранируются шестнадцатеричным кодированием C-стиля "\x00". Строка, начинающаяся с ' ', является строкой продолжения, добавляющей пары ключ/значение к сообщению журнала, которые обеспечивают машиночитаемый контекст сообщения для надежной обработки в пользовательском пространстве. Пример:: 7,160,424069,-;pci_root PNP0A03:00: окно моста хоста [io 0x0000-0x0cf7] (игнорируется) ПОДСИСТЕМА=acpi УСТРОЙСТВО=+acpi:PNP0A03:00 6,339,5140900,-;NET: семейство зарегистрированных протоколов 10. 30,340,5690716,-;udevd[80]: начиная с версии 181. Ключ DEVICE= однозначно идентифицирует устройства следующим образом: b12:8 блокировать dev_t c127:3 символ dev_t n8 netdev ифиндекс +sound:card0 подсистема:devname Поле флагов по умолчанию содержит «-». Буква «c» обозначает фрагмент строки. Обратите внимание, что эти подсказки относительно строк продолжения не обязательно верны, и поток может быть чередуются с несвязанными сообщениями, но объединение строк вывода обычно дает более удобочитаемые результаты. Аналогичная логика используется внутри системы, когда сообщения выводятся на консоль, /proc/kmsg или системный вызов syslog(). По умолчанию ядро пытается избежать фрагментов путем объединения, когда это возможно, а фрагменты встречаются редко; однако, если включена расширенная поддержка консоли, конкатенация в ядре отключается, и вывод /dev/kmsg будет содержать больше фрагментов. Если потребитель журналов выполняет объединение, конечный результат должен быть таким же. В будущем объединение в ядре может быть полностью удалено, и пользователям /dev/kmsg рекомендуется реализовать обработку фрагментов. В системе запущены две службы: kmsgd и awlogd. Оба они пишут системные логи во внутренюю память, в папку /data/media/awlog/(kernel|logcat). Поскольку logcat довольно "многословный", такое поведение не очень разумно и вот пара способов их отключить: 1) Примитивный и грубоватый способ, но не требующий модификации системных разделов^ adb connect <ip>:5555 adb root adb shell eros-p1:/ # rm -rf /data/media/awlog eros-p1:/ # echo 0 > /data/media/awlog Т.е. удаляем папку, создаём на её месте одноимёный файл. 2) Более корректный но опасный способ, с модификацией системных файлов. В сервисном файле /etc/init/awlogd.rc указан prop параметр (persist.debug.logpersistd), разрешающий запуск указанных процессов. Этот параметр находится в файле /etc/prop.default, который необходимо отредактировать. adb connect <ip>:5555 adb root adb remount adb shell # делаем бэкап eros-p1:/ # cp /etc/prop.default /data/local/tmp # меняем значение параметра eros-p1:/ # sed -i "s/persist.debug.logpersistd=true/persist.debug.logpersistd=false/g" /etc/prop.default |
 |