Как я могу отследить, почему база данных rpm на моих серверах продолжает повреждаться?
Запуск Centos 7 (различные версии)
База данных rpm на моих серверах продолжает повреждаться. Кажется, что каждые несколько недель мне нужно делать пересборку rpm на одном или двух серверах.
Куда мне обратиться, чтобы увидеть, что может быть виновным? Я знаю, как это исправить, но как я могу определить, является ли это конкретный пакет, который я устанавливаю, или что-то вызывает это?
бесконечный ряд ошибок, из-за которых среда BDB повреждается, некоторые из которых были ошибками BDB (несколько обнаруженных только за последние пару лет), которые были исправлены в Fedora/RHEL libdb, но в основной версии BDB 5.x их нет, не знаю 6.x, но здесь вы сталкиваетесь с лицензией. Это хорошо известная проблема, которая не имеет постоянного решения.
Основная причина:
Если rpm или yum завершаются некорректно, файлы блокировки остаются. Файлы (__db001 - __db005) остались в /var/lib/rpm. Мы можем увидеть pid, с которым остались файлы. Проблема, как правило, в том, что у нас нет журналов или настроек аудита для того, что на самом деле убило процесс. Наиболее распространенная причина заключается в том, что время ожидания инструмента автоматизации истекло, и он внезапно завершает процесс, не позволяя rpm очистить файлы блокировки.
Одним из возможных обходных путей является принудительное использование частной среды. Это также означает практически отсутствие блокировки, но, по крайней мере, это означает, что запросы ничего не испортят (однако сами запросы могут возвращать мусор, если они выполняются в середине операции записи). Вот что происходит, если вы запускаете запросы как непривилегированный пользователь, но, поскольку вы можете контролировать разрешения с помощью песочницы, вы можете добиться того же, запретив открытие /var/lib/rpm/.dbenv.lock, что приведет к тому, что rpm вернется к частная среда - это означает, что она не будет открываться, а тем более писать в эти файлы __db. *.
Заявление разработчиков заключается в том, что это не будет исправлено полностью:
«Чтобы сделать BDB более надежным, потребуется использовать там транзакции, но это было бы несовместимым изменением, а это последнее, чего мы хотим делать в этот момент, когда мы в основном собираемся объявить устаревшим BDB. Это означает, что мы ничего не можем с этим поделать, на бэкенде Berkeley DB, к сожалению.»
Они предлагают использовать утилиту dcrpm.
общие проблемы с повреждением базы данных RPM. Он пытается выполнить запрос против вашей базы данных RPM и запускает db_recover db4, если она зависла или иначе кажется сломанным. Затем он убивает все задания, у которых была база данных RPM. открыть ранее, так как они будут застревать в бесконечных циклах внутри libdb и не может восстановиться чисто.
Вы можете скачать его из Git-репозитория. Официальное руководство доступно по адресу там же.
Вот что вам нужно сделать для установки:
# git clone https://github.com/facebookincubator/dcrpm.git
# cd dcrpm
# python setup.py install
После установки вы можете запустить инструмент и добавить его в cron:
# dcrpm
К сожалению, установка всегда завершалась неудачно для меня на CentOS 7 из-за зависимостей Python, которые никогда не устанавливались должным образом. .
error: Setup script exited with error in psutil setup command: 'extras_require' must be a dictionary whose values are strings or lists of strings containing valid project/version requirement specifiers.
Это несмотря на то, что psutil успешно установлен. Но некоторые другие люди сообщали, что dcrpm работал у них хорошо, так что попробуйте.
Я использовал другое официальное решение от Red Hat (RHEL 7).
# curl https://people.redhat.com/kwalker/repos/rpm-deathwatch/rhel7/rpm-deathwatch-rhel-7.repo -o /etc/yum.repos.d/rpm-deathwatch.repo
# yum install -y kernel-{devel,headers}-$(uname -r) systemtap && debuginfo-install -y kernel
# yum install rpm-deathwatch
# systemctl start rpm-deathwatch
# systemctl status rpm-deathwatch