Як запобігти стільки випадків запуску влучної перевірки?

У мене є сервер Ubuntu 12.04, який просто вийшов з ладу через дуже очевидну причину: 30+ apt-checkпроцесів, що споживають усю пам'ять, вбивця OOM забиває, вбиваючи життєво важливі служби. Я не впевнений, звідки apt-checkберуться процеси, але я думаю, що мої плагіни Nagios / Icinga check_aptможуть використовувати його, а також byobuрядок стану може захотіти відобразити його вихід. Я здогадуюсь, що щось замкнулося, і всі процеси просто чекали, але зберігали пам’ять.

Як я можу запобігти появі в системі стільки екземплярів apt-check? Для мене це не має сенсу, і він повинен просто вийти, як тільки не зможе отримати блокування читання в базі даних dpkg.

Здається, я тут не єдиний, хто стикається з неприємностями. Усі пропозиції щодо apt-checkдосить негативні:

^{(чистий браузер, не авторизований, не персоналізований пошук)}

Деякі занурення в apt-checkмене дали ці підказки, оскільки це дуже тупий сценарій, який потребує виправлення. При всій належній повазі до його авторів він не вдається на моїх серверах. Ось мої думки:

• apt-check == /usr/lib/update-notifier/apt_check.py
• сили nicelevel 19 для себе
• не встановлено тайм-аутів для дій

Поєднання останніх двох дозволяє їй безкінечно накопичуватися по спіралі вниз. Якщо система використовується для якихось інших цілей з більш високим пріоритетом, кількість процесів просто збільшиться і цьому немає кінця, оскільки apt-checkніколи не отримає жодного пріоритету над нею. Неприємності посиляться лише після того, як вбивця OOM вирішить вбити процеси життєво важливої ​​системи.

Якби будь-який із цих двох аспектів поведінки був різним, це не дозволило б системі опинитися в такому зламаному стані - це моє припущення.

Хоча рядки є правильними щодо того, що батьківські процеси відповідають за це теж, я вважаю, що нижче є недоліки, apt-checkі їх потрібно повідомити як помилку, щоб правильно їх вирішити:

• це повинно натякнути на вбивцю ООМ, щоб першим вбив себе
• він не повинен встановлювати жорсткий рівень з твердим кодом
• він повинен вийти, якщо йому потрібно необгрунтовано багато часу, щоб отримати інформацію

Насправді, схоже, що вбивця Linux OOM робить певну евристику щодо цього. Номіровані процеси отримають збільшений бал, а тривалі процеси зменшаться. ( Джерело - дякую Ульріху Дангелу за те, що він це вказав )

Можливе рішення, яке я можу запропонувати:

• результати кешу після обробки
• вивести кеш, якщо менше N кількості секунд без завантаження всіх бібліотек Python-APT для кожного простого (парного --help) виклику.
• зробіть nicelevel налаштованим - Дозвольте мені змінити / відключити це, будь ласка! Я вважаю, що встановлення його на 0 насправді допоможе
• нехай це збільшить бал вбивць OOM

Вам потрібно з’ясувати, який процес нерестової перевірки. ви можете використовувати щось на зразок ps, щоб отримати дерево процесу.

ps -A --forest

Якщо у apt-check немає батьків, то це може бути проблема з apt-check його самою, а не з однією конкретною програмою. якщо це так, я б спробував налагодити apt-check.

Письмова база на Ubuntu 12.04

У мене є та сама проблема, і я з'ясував, що через те byobu, що якщо я просто apt-get updateне запускаю byobu, процес не буде check-apt. Крім того , воно відноситься до update-notifierпакету, коли я видалив ці пакети (оновлення-notifer-Коммон, оновлення-повідомник), використовуючи 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щоб виправити це.