Uruchamiając niektóre serwery Linux z pojedynczymi lub tylko kilkoma istotnymi demonami usług systemowych, chciałbym dostosować Killer OOM do tych demonizowanych procesów na wypadek, gdyby wydarzyło się coś dziwnego. Na przykład dzisiaj niektóre serwery Ubuntu z MySQL dostały zabitego demona MySQL, ponieważ tony apt-checkerprocesów zajmowały całą pamięć, a jądro uznało, że zabicie MySQL jest dobrym pomysłem.

Wiem, że mogę dostosować wynik za pomocą /proc/$(pidof mysqld)/oom_score_adjpliku, aby dać jądrze pewną wskazówkę, że nie wolę, aby MySQL został zabity, ale to nie przetrwa ponownego uruchomienia usługi. Czy powinienem edytować skrypty init / upstart z pakietu, aby uwzględnić te dostosowania? Nie sądzę, żeby to było bardzo eleganckie rozwiązanie, ponieważ wprowadzałbym poprawki do plików należących do pakietu. Czy można by ogólnie podłączyć się do skryptów upstart / init i warunkowo go dostosować? A może sugerowałbyś uruchomienie skryptu na czas nieokreślony while true{ adjust_oom(); sleep 60;}?

Istnieje kilka nowoczesnych systemów nadzoru dæmon. (Rzeczywiście, ponieważ istnieje narzędzie do ładowania łańcucha dla zadania, prawdopodobnie wszyscy mają na to sposób.)

• Upstart: Użyj oom scorew pliku zadania.

  wynik oom -500

• systemd: użyj OOMScoreAdjust=ustawienia w jednostce serwisowej. Możesz użyć plików łat jednostki serwisowej, aby wpłynąć na paczkowane jednostki usługowe.

  [Usługa] 
  OOMScoreAdjust = -500

• rodzina daemontools : Użyj usługioom-kill-protectz zestawu narzędzi nosh wrunprogramie dla usługi.

  Jeśli konwertujesz jednostkę usług systemowych, convert-systemd-unitsnarzędzie w rzeczywistości przekształci OOMScoreAdjust=ustawienie w takie wywołanie oom-kill-protect.

  #! / bin / nosh 
  … 
  oom-kill-protect - -500 
  … argumenty 
  programu 

  Jako bonus możesz sparametryzować:

  oom-kill-protect - fromenv

  i ustaw wartość parametru w środowisku usługi (przypuszczalnie czytana z envdir powiązanego z usługą, tutaj manipulowanego rcctlpodkładką nosh ):

  rcctl zestaw servicename oomprotect -500

Dalsza lektura

• Jonathan de Boyne Pollard (2016). oom-kill-protect. zestaw narzędzi nosh. Oprogramowania.
• James Hunt i Clint Byrum (2014). „ oom score”. Uaktualnij książkę kucharską .
• Lennart Poettering (2013-10-07). „ OOMScoreAdjust”. systemd.exec. systemowe strony podręcznika. freedesktop.org.
• Jonathan de Boyne Pollard. rcctl. zestaw narzędzi nosh. Oprogramowania.
• /unix//a/409454/5132

Jest to możliwe w Ubuntu przy użyciu Upstart i oom scoreopcji konfiguracji.

oom score

Linux ma funkcję zabijania „Brak pamięci”. [...]

Zwykle zabójca OOM traktuje wszystkie procesy jednakowo, ta sekcja radzi, aby jądro traktowało to zadanie inaczej.

Wartość „korekty” podana w tej zwrotce może być liczbą całkowitą od -999 (bardzo mało prawdopodobne, że zabije ją zabójca OOM) do 1000 (bardzo prawdopodobne, że zabije ją zabójca OOM). [...]

Przykład:

# this application is a "resource hog"
oom score 1000

expect daemon
respawn
exec /usr/bin/leaky-app

Możesz włamać się do samego MySQL (np. OpenSSH to sshdrobi), ale to jest trochę zbyt hardkorowe i bardzo brudne (problemy z aktualizacjami itp.)

Możesz to zrobić w opakowaniu lub w skrypcie inicjującym - partytura powinna zostać odziedziczona (i w opakowaniu, które prawdopodobnie i exec mysqld "$@"tak chciałbyś zrobić ).

Użyj cgroups- da ci to nieco większą elastyczność i może być na stałe w tym sensie, że odpowiednie ustawienia mogą być zastosowane automatycznie przy ponownym uruchomieniu usługi. Zobacz np. Kontrolowanie priorytetu aplikacji za pomocą cgroups, aby uzyskać więcej informacji. Aby osiągnąć automatyzm, którego szukasz, prawdopodobnie powinieneś rzucić okiem na libcgroup , która zawiera demona, który może obsłużyć zmienianie grup cG działających procesów w locie zgodnie z zestawem reguł lub po prostu użyć cgexecopakowania ( z tego samego pakietu).