Co jsou zombie procesy?
Zombie procesy jsou ty procesy, které dokončily svůj úkol, ale nadřazený proces (s největší pravděpodobností) neočekávaně zemřel nebo se zhroutil. Mohou také naznačovat chybný kód. Většina uživatelů dobře nerozumí tomu, co jsou zombie procesy a jak ovlivňují hostitele Linuxu. Za prvé a především, nízký počet (řekněme například deset) zombie procesů nepřispívá k zatížení systému. Ve skutečnosti by tisíce zombie nepřispívaly k zatížení systému.
Podle definice zombie procesy z větší části nespotřebovávají zdroje. Každému zombie procesu je stále přiděleno identifikační číslo procesu neboli PID. Na 32bitových systémech je maximální počet dostupných PID 32767. U 64bitových systémů se toto číslo exponenciálně zvyšuje na více než 4 miliony.
Pro každý proces zombie se také používá malé množství paměti. Technicky by to vyžadovalo desítky tisíc, možná stovky tisíc procesů zombie, aby způsobily značné vyčerpání systémových zdrojů.
Existují 2 scénáře, které zde proberu. Prvním z nich je proces, který vytváří mnoho podřízených PID, a poté nadřazený PID zkolabuje nebo zemře, aniž by sklidil podřízené PID. Normálně by tento problém naznačoval možnou chybu v programu nebo kódu. Když k tomu dojde, PID 1 (nebo proces init) převezme jejich vlastnictví. Pro účely tohoto návodu je nejrychlejší cestou, jak se těchto zombie zbavit, restartovat počítač. Je také možné vytvořit fiktivní proces a předat vlastnictví těchto zombie procesů zpět do fiktivního PID k vyčištění. To je zde mimo rozsah. Restartujte a hotovo!
Druhým scénářem je situace, kdy je proces zavěšen do bodu, kdy jej OS vidí jako spuštěný, ale proces ve skutečnosti nic nedělá. Příklad, který v této diskusi používám, je démon nástroje pro automatické hlášení chyb (abrtd ), který se dodává s Red Hat Enterprise Linux a některými dalšími distribucemi. Je to skvělý nástroj a líbí se mi, že jej mám v systému spuštěný, protože mi jako systémovému správci poskytuje lepší přehled o tom, co se hučí – nebo padá – ale ne vyvolání havarovaného jádra.
V mém prostředí je tento démon také trochu Achillovou patou. Ve výchozím nastavení abrtd vytváří informace pouze pro podepsané aplikace. Jakákoli aplikace může být podepsána za účelem vygenerování chyby, ale pokud nepodepsaná aplikace spustí abrtd , démon prochází pohyby vytvořením zprávy o chybě a poté odstraní vše, co vytvořil. Toto chování může způsobit problémy se zablokováním akce pro nepodepsanou aplikaci.
Podívejme se na příklad. Uživatel odešle hlášení o incidentu, že systém byl pomalý kvůli šesti zombie procesům. V systému, který abrtd existuje, jsou některé mrtvé dárky má problémy. Když su - pro rootování uvidíte následující:
'abrt-cli status' timed out
Pokud zkontrolujeme abrtd proces můžeme vidět, že stále běží, ale existuje podřízený proces, který běží od 30. května.
[root@$HOSTNAME ~]# systemctl status abrtd
● abrtd.service - ABRT Automated Bug Reporting Tool
Loaded: loaded (/usr/lib/systemd/system/abrtd.service; enabled; vendor preset: enabled)
Active: active (running) since Sat 2019-04-27 08:36:47 EDT; 2 months 13 days ago
Main PID: 1161 (abrtd)
Tasks: 12
Memory: 34.0M
CGroup: /system.slice/abrtd.service
├─ 1161 /usr/sbin/abrtd -d -s
├─60777 abrt-server -s
├─60867 /usr/libexec/abrt-handle-event -i -e post-create -- /var/spool/abrt/unsigned-app-2019-05-30-01:48:24-57451
├─64714 abrt-server -s
├─68157 abrt-server -s
├─70725 abrt-server -s
├─74101 abrt-server -s
├─77136 abrt-server -s
├─81417 abrt-server -s
├─84637 abrt-server -s
├─88183 abrt-server -s
└─90022 abrt-server -s
Takže abrtd technicky stále běží, ale tento proces po vytvoření vytvořil stav, kdy se některé nové zprávy o selhání ABRT pokusily spustit, ale staly se zombie. V tomto okamžiku můžete restartovat abrtd a tato akce vymaže všechny zombie procesy.
Ale pokud jste nevěděli, že tomu tak bylo, zde je návod, jak pomocí ps -xal zjistit, jaké PID je rodičem zombie příkaz. Tento příkaz vypíše hodně informací, takže ukážu jen sloupce, které potřebujeme:
[root@$HOSTNAME ~]# ps -xal | awk '{ print $4 " " $10 " " $13 }' | sort -n
1739 Ssl+ java
1903 S bin/rscd
1903 S bin/rscd
2391 Ssl+ node
2816 Ssl+ java
2889 Ssl+ java
3785 Ss appcollect
3785 Ss appconfigcollect
3926 Ssl+ java
4696 Ss /bin/sh
4731 S bin/bash
4827 Sl /myappbinaries/jre/bin/java
7074 Ss+ httpd
7095 S+ httpd
Čtvrtý sloupec je PID rodiče, desátý sloupec je stav podřízeného procesu (samozřejmě byste hledali PID ve stavu Z) a třináctý sloupec je podřízený proces. Pomocí rodičovského PID ve čtvrtém sloupci nyní můžete tento rodičovský proces zabít a jeho zombie děti také zmizí. Pokud toto rodičovské PID není 1, v takovém případě bude nutný restart.
Vzhledem k tomu, že jsme v provozu, nemáme vždy ten luxus kdykoli restartovat. Osobně mám pocit, že restart by měl být až poslední možností. Rebooty skrývají množství hříchů a nechají tyto hříchy, aby se projevily v tu nejnevhodnější dobu, obvykle pozdě v noci nebo o prázdninových víkendech!
Jo a zatížení tohoto systému po restartu abrtd nekleslo ani o bit a vymazání těch 6 zombie.