Jak zapobiec tak wielu uruchomieniom apt-check?

Mam serwer Ubuntu 12.04, który właśnie się zawiesił z bardzo oczywistej przyczyny: ponad 30 apt-checkprocesów zużywa całą pamięć, uruchamia się zabójca OOM, zabija ważne usługi. Nie jestem pewien, skąd apt-checkpochodzą procesy, ale chyba wtyczki Nagios / Icinga check_aptmogłyby z niego skorzystać, a byobulinia statusu może chcieć wyświetlić jego wynik. Wydaje mi się, że coś jest zamknięte, a wszystkie procesy tylko czekały, ale utrzymywały pamięć.

Jak mogę zapobiec tak dużej liczbie wystąpień apt-checkw systemie? Nie ma to dla mnie sensu i powinno po prostu wyjść, gdy tylko nie będzie można uzyskać blokady odczytu w bazie danych dpkg.

Wygląda na to, że nie tylko ja mam tutaj kłopoty. Wszystkie sugestie dotyczące apt-checksą dość negatywne:

^{(czysta przeglądarka, niezalogowany, brak spersonalizowanego wyszukiwania)}

Niektórzy zagłębili się w apt-checkte wskazówki, że jest to bardzo tępy skrypt, który wymaga naprawy. Z całym szacunkiem dla jego autorów, zawodzi na moich serwerach. Oto moje przemyślenia:

• apt-check == /usr/lib/update-notifier/apt_check.py
• wymusza dla siebie poziom 19
• nie określono limitów czasu dla akcji

Kombinacja dwóch ostatnich pozwala układać się bez końca w spiralę w dół. Jeśli system jest używany do innych celów o wyższym priorytecie, liczba procesów po prostu wzrośnie i nie będzie końca, ponieważ apt-checknigdy nie uzyska nad nim żadnego priorytetu. Kłopoty nasilą się, gdy zabójca z OOM zdecyduje się zabić wasze ważne procesy systemowe.

Jeśli którykolwiek z tych dwóch aspektów zachowania byłby inny, to nie pozwoliłoby, aby system znalazł się w tak złym stanie, to moje założenie.

Chociaż ciągi mają rację co do tego, że procesy nadrzędne są w tym również odpowiedzialne, uważam, że poniższe punkty są wadliwe apt-checki należy je zgłosić jako błąd, aby poprawnie rozwiązać:

• powinno to zasugerować zabójcy OOM, aby sam zabił jako pierwszy
• nie powinien ustawiać nicelevel na stałe
• powinien wyjść, jeśli zdobycie informacji zajmuje nieuzasadniony czas

W rzeczywistości wygląda na to, że zabójca Linux OOM robi na tym trochę heurystyki. Procesy wygładzone uzyskają wyższy wynik, a procesy długotrwałe zostaną zmniejszone. ( źródło - dzięki Ulrichowi Dangelowi za wskazanie tego )

Możliwe rozwiązanie, które mogę zaproponować:

• wyniki pamięci podręcznej po przetworzeniu
• wyjściową pamięć podręczną, jeśli jest mniejsza niż N ilość sekund bez ładowania wszystkich bibliotek Python-APT dla każdego prostego (parzystego --help) wywołania.
• skonfiguruj nicelevel do konfiguracji - Pozwól mi to zmienić / wyłączyć, proszę! Uważam, że ustawienie wartości 0 naprawdę pomoże
• niech zwiększy wynik zabójcy OOM

Musisz dowiedzieć się, jaki proces uruchamia apt-check. możesz użyć czegoś takiego jak ps, aby uzyskać drzewo procesów.

ps -A --forest

Jeśli apt-check nie ma rodziców, może to oznaczać problem z apt-check sam, a nie z konkretnym programem. w takim przypadku spróbowałbym debugować apt-check.

Baza pisemna na Ubuntu 12.04

Mam ten sam problem i dowiedziałem się, że ponieważ byobupo prostu apt-get updatenie używam byobu, nie będzie check-aptprocesu. Również dotyczy to update-notifierpakować, kiedy usunąłem te pakiety (update-notifer-common, update-powiadamiający), stosując byobui run apt-get update, zabrakło innego polecenia, ale to samo pamięci przy użyciu: apt-get -s -o Debug::NoLocking=true upgrade.

Niektóre inne rzeczy mogą działać apt-get update(ale prawdopodobnie nie działają check-apt)

• przekazanie argumentu do check_aptaktualizacji / aktualizacji pkg.
• jeśli skonfigurowany, /etc/cron.daily/aptmoże również aktualizować listę pakietów (patrz https://help.ubuntu.com/lts/serverguide/automatic-updates.html ), ale działa tylko raz dziennie i nie powinien stanowić problemu.

Na pulpicie może być więcej rzeczy.

Wniosek: byobuwychwytuje zdarzenie po uruchomieniu apt-get updatei uruchomieniu tych check-aptprocesów, ponownie skonfiguruj pasek stanu, byobuaby to naprawić.