Как предотвратить так много случаев запуска apt-check?
У меня есть сервер Ubuntu 12.04, который только что вышел из строя по очень очевидной причине: 30+ apt-check процессы, занимающие всю память, запускается OOM Killer, убивая жизненно важные службы. Я не уверен, где apt-check процессы происходят, но я думаю, что мои плагины Nagios / Icinga check_apt может использовать его, а также byobu Строка состояния может захотеть отобразить свой вывод. Я предполагаю, что что-то заблокировано, и все процессы просто ждали, но держали память.
Как я могу предотвратить так много случаев apt-check в системе? Это не имеет смысла для меня, и он должен просто выйти, как только он не может получить блокировку чтения в базе данных dpkg.
Кажется, я не единственный, у кого здесь проблемы. Все предложения для apt-check довольно негативно

(чистый браузер, не авторизован, нет персонального поиска)
3 ответа
Некоторые погружаются в apt-check дал мне эти подсказки за то, что это очень тупой сценарий, который нужно исправить. При всем моем уважении к авторам, он не работает на моих серверах. Вот мои мысли:
apt-check==/usr/lib/update-notifier/apt_check.py- заставляет nicelevel 19 для себя
- таймауты для действий не установлены
Сочетание последних двух позволяет ему бесконечно накапливаться по спирали вниз. Если система используется для каких-то других целей с более высоким приоритетом, количество процессов просто возрастет, и этому нет конца, так как apt-check никогда не получит никакого приоритета над этим. Проблемы только усугубятся, когда убийца OOM решит убить ваши жизненно важные системные процессы.
Если бы любой из этих двух аспектов в поведении отличался, это не позволило бы системе оказаться в таком нарушенном состоянии, как я полагаю.
Хотя строки верны в том, что родительские процессы также несут за это ответственность, я считаю, что нижеприведенные пункты являются недостатками apt-check и должен быть зарегистрирован как ошибка, чтобы быть обращенным должным образом:
- это должно быть намек на убийцу ООМ, чтобы убить себя первым
- он не должен устанавливать красивый уровень
- он должен выйти, если для получения фрагментов информации требуется неоправданно много времени
На самом деле, похоже, что Linux OOM Killer делает некоторую эвристику по этому поводу. Замкнутые процессы получат повышенную оценку, а длительные процессы уменьшатся. ( источник - спасибо Ульриху Дангелю за указание на это)
Возможное решение, которое я могу предложить:
- кешировать результаты после обработки
- выходной кэш, если количество секунд меньше N без загрузки всех библиотек Python-APT для каждого простого (даже
--help) вызов. - сделать настраиваемый красивый уровень - позвольте мне изменить / отключить это, пожалуйста! Я считаю, что установка его на 0 на самом деле поможет
- это увеличить счет убийцы ООМ
Вам необходимо выяснить, какой процесс порождает apt-check. Вы можете использовать что-то вроде ps, чтобы получить дерево процессов.
ps -A --forest
Если у apt-check нет родителей, то это может быть проблема с apt-check как таковой, а не одной конкретной программой. если это так, я бы попытался отладить apt-check.
Письменная база по Ubuntu 12.04
У меня та же проблема и выяснил, что это из-за byobuесли я просто бегу apt-get update не используется byobu, Здесь не будет check-apt процесс. Также это относится к update-notifier пакет, когда я удалил эти пакеты (update-notifer-common, update-notifier), используя byobu и беги apt-get update, он запустил другую команду, но с той же памятью, используя: apt-get -s -o Debug::NoLocking=true upgrade,
Некоторые другие вещи могут работать apt-get update (но, вероятно, не работает check-apt)
- передавая аргумент
check_aptобновить / обновить pkg. - если настроено,
/etc/cron.daily/aptможет также обновить список пакетов (см. https://help.ubuntu.com/lts/serverguide/automatic-updates.html), но он запускается один раз в день и не должен вызывать проблем.
На рабочем столе может быть больше вещей.
Заключаем:byobu ловит событие при запуске apt-get update и вызвать эти check-apt процессы, перенастроить строку состояния byobu чтобы исправить это.