Ошибки udisks2 (udisksd) в системном журнале: как исследовать?

мои системные журналы Ubuntu 18.04 Intel NUC рассылаются следующими сообщениями об ошибках:

udisksd[1369]: udisks_mount_get_mount_path: assertion 'mount->type == UDISKS_MOUNT_TYPE_FILESYSTEM' failed

Я выяснил, что рассылка спама происходит из-за того, что установлен Docker и запущены некоторые контейнеры. Но когда Docker и все контейнеры остановлены, ошибка также возникает в системном журнале, но не так часто. Поиск в Google этого сообщения об ошибке не помог мне. Это не связано с оборудованием, так как я изменил NUC, и у меня работает аналогичный настроенный NUC, который не имеет этих ошибок.

Кто-нибудь знает, как исследовать эту проблему?

0
задан 3 December 2019 в 20:09

2 ответа

Я наконец решил это: в моем случае это было фактически связано с Docker. В своем вопросе я заявил, что остановил Docker, и проблема не исчезла. Это все еще актуально. Проблема была связана с загрузкой с включенным автоматическим запуском Docker, когда он пытался запустить контейнер с томом на устройстве LUKS, которого не было при загрузке. После остановки Docker спам в журналах udisksd сохранялся. Я решил это, отключив автоматический запуск для контейнера, объем которого находится на диске, которого нет во время загрузки. После этого ошибок больше не было, и я смог вручную запустить контейнер. Спасибо за вклад.

1
ответ дан 31 January 2020 в 12:25

Это происходит, когда какое-то приложение не вставляет допустимый / правильный тип файловой системы в такие вещи, как statvfs.

В конце концов, эта информация переместится в udisksd, если рассматриваемое хранилище обрабатывается подсистемой udisk.

У меня это произошло при установке swapspace в Ubuntu 18.04 (из репозитория, подтвержденного текущей сборкой из исходного zip-архива).

Как найти детектив: вот что я сделал.

  1. На каких компьютерах это происходит? Это было только на тех, которые я недавно переместил в swapspace
  2. В каких файлах журнала это происходит? Обычные файлы журналов, но также в сообщениях кто пишет сообщения в системе Ubuntu ...поднимается флаг: плохо кодирование где-то, кто-то выпустил что-то неправильно закодированное запускать в Ubuntu / Debian
  3. Когда появляется сообщение? В моем случае их поток каждые 5 минут, только на хостах, которые сделали недавно получили пространство подкачки (чтобы предотвратить блокировку браузера и виртуальное изображение увеличение размера изображений в браузере, лучше управляйте пространством подкачки)
  4. После того, как вы определили, какое из ваших приложений вызывает появление недопустимые дескрипторы файловой системы в вызове, связанном с хранилищем:

     остановите приложение (я смонтировал раздел подкачки и очистил все файлы подкачки
    файлы в него)
    удалите файлы, создаваемые приложением, если это возможно, или переместите все,
    попасть в чистую среду, где приложение запускается "новое" (я удалил все
    файлы подкачки после того, как все было снова выгружено в традиционный своп
    раздел)
    
  5. Запустите проблемное приложение. В моем случае сначала ничего не произошло, сначала нужно сделать несколько файлов подкачки прежде, чем потерять свои шарики. В случае файла подкачки это использование внутренняя переменная glibc для выделенных типов файлов подкачки, ну, glibc может использовать свою переменную и изменять содержимое или даже использовать его .... использовать какое пространство подкачки вставлено там? также другие ошибки в области подкачки, которые выданный тип действительно может никогда не будет правильным ....

  6. Заставить приложение генерировать ошибку.Я действительно создал ситуацию, когда пространство подкачки действительно должно делать то, что он говорит, что делает после того, как файлы подкачки были там, сообщения действительно появлялись (не имеет значения, если сообщения в этом случае относятся к файлам, принадлежащим swapspace, это может быть следствие того, что пространство подкачки фактически меняет эту переменную, к счастью, здесь все было просто, все они относились к файлам подкачки)

  7. Узнать, при каких условиях появляются ошибки. В моем случае: каждые 5 минут при запуске cron подкачки и каждый раз, когда я манипулировал файлами подкачки (с помощью соответствующих команд подкачки).

Многое происходит до того, как вызов переходит в подсистему udisks. В сообщении говорится, что udisk получил неверный код во время звонка. Перед тем, как попасть в удиски, есть целое дерево вызовов.

Потребовалось много копания файла журнала, чистых запусков (после того, как я идентифицировал пространство подкачки, с и без, сравнивая недавно измененные системы с системами, «работавшими вечно»), затем я вошел в источник пространства подкачки и посмотрел, где там это взаимодействие с файловой системой, которое могло вызвать это, и обнаружил большую кучу помета, оставленную каким-то эгоистичным программистом, который никогда не проверялся и не тестировался должным образом ....

Тогда более важный вопрос: что теперь, собака поймала автобус а что дальше.

Я не борюсь с ними с открытым исходным кодом, тонкокожим чрезмерно амбициозным эго, не имеющим поддержки с открытым исходным кодом ID-10ts.

Настоящая причина, по которой я использую открытый исходный код: не качество, о нет, по большей части это машинистки-любители, пытающиеся сделать открытый код, чтобы произвести впечатление на девушек, так кажется.

В закрытой системе я вернулся бы к исходной точке (нужно исправить мою подкачку)

в открытом исходном коде: мне понадобится меньше часа, чтобы проверить текущий источник, заменить все устаревшие системные вызовы и (около 10 минут) найдите там все незаконные использования конкретной переменной glibc и работайте над этим.

Так что да, хотя открытый исходный код очень низкого качества, его делают эгоистичные маньяки, которые не имеют ни малейшего представления о дизайне, тестировании, проверке, пилотировании, и для кого контекст и масштаб - не слова: мне не нужно кого-то ждать чтобы исправить что-нибудь для меня.

Однако, настаивая на «надлежащей подаче» для такого большого лабиринта, произойдет то, что обычно: люди будут разочарованы тем, что «открытый исходный код не работает», и все мы проиграем. Поскольку именно эта вещь, с которой я столкнулся, на самом деле может вызвать серьезную потерю «несвязанных» данных, зависание системы, хаос и разрушение, наступает конец света. (помните, изменяет внутреннюю переменную glibc.).

мое желание:

изменить открытый исходный код:

запрещение принятия какого-либо кода, если не проверено и не подписано коллегой, между коллегами, по крайней мере, один квалифицированный партнер (степень информатики, математика, физика тоже). Никаких программистов-любителей по критически важным системам. Если долго делать что-то не так и не попасться, никто не станет экспертом.

.. и определите экспертную оценку .. убедитесь, что работа сделана, это означает:симптом, анализ воздействия ошибки, исправление, правильность, анализ воздействия, проверка, модульное тестирование, системное тестирование, тестирование релиза - все это необходимо полностью протоколировать, а протоколы тестирования должны быть должным образом задокументированы кодировщик никогда не может сертифицировать свою работу!

-1
ответ дан 17 January 2020 в 23:03

Другие вопросы по тегам:

Похожие вопросы: