Dotaz: Vixie-Cron se zblázní a spustí fork bomb

[SAM:]

Mám takový nemilý problém, který se mi nedaří podchytit. Tu a tam čas od času se zblázní Cron a forkne spoustu procesů. Většinou 1024 nebo 4096. Pokud se mi nějaký podaří zabít, tak ho okamžitě zastoupí další. Část výstupu ps ax vypadá takto:

14999 ?        S      0:00 /usr/sbin/cron
15002 ?        Ss     0:00 /bin/bash -c /usr/local/sbin/arpwatch_parser.sh > /dev/null 2>&1
15003 ?        S      0:00 /bin/bash /usr/local/sbin/arpwatch_parser.sh
15007 ?        D      0:00 /bin/bash /usr/local/sbin/arpwatch_parser.sh
15063 ?        S      0:00 /usr/sbin/cron
15065 ?        Ss     0:00 /bin/bash -c /usr/local/sbin/arpwatch_parser.sh > /dev/null 2>&1
15067 ?        S      0:00 /bin/bash /usr/local/sbin/arpwatch_parser.sh
15071 ?        D      0:00 /bin/bash /usr/local/sbin/arpwatch_parser.sh

A to se opakuje pořád. Ještě se tam někdy objevuje pooler od cacti. Crontab vypadá takto:

# check scripts in cron.hourly, cron.daily, cron.weekly and cron.monthly
# 59  *  * * *  root    rm -f /var/spool/cron/lastrun/cron.hourly
# 9  3  * * *   root    rm -f /var/spool/cron/lastrun/cron.daily
# 19 4  * * 6   root    rm -f /var/spool/cron/lastrun/cron.weekly
# 29 5  1 * *   root    rm -f /var/spool/cron/lastrun/cron.monthly
# */10  *  * * *        root    test -x /usr/sbin/run-crons && /usr/sbin/run-crons 

# 0  0 * * *    root    /usr/sbin/logrotate /etc/logrotate.conf
*/5   * * * *   apache  /usr/bin/php /var/www/localhost/htdocs/cacti/poller.php > /dev/null 2>&1
*/10   * * * *   root   /usr/local/sbin/arpwatch_parser.sh > /dev/null 2>&1
# 0 */8   * * *   root  /usr/bin/emerge --sync > /dev/null 2>&1

Nakonec mi vždy nezbývá nic jiného než stroj resetovat natvrdo a vůbec se mi nepodařilo posunout někam v pátrání, jak k tomu dojde.

Díky.

Odpovědi

[Jooky (inactive)]

Ja by som vinu na cron nehadzal. Podla crontabu ma pustat ten arpwatch kazdych 10 minut a on to bude robit aj ked predchadzajuci beh nekoncil (kontrolu, ci uz dobehol robi len zlozitejsi cron ako napr. fcron). V tom vypisu je vidiet, ze ten script ostane "vysiet" na nejakom volani jadra (disk, siet, ...), co v pripade scriptu spustaneho pravidelne je dost zle. Doporucujem vam prezriet ten script a pohladat co by mohlo sposobit to neprerusitelne spanie. Tak isto moze ist o hardwarovy problem, ale bez obsahu toho aprwatch scriptu sa to len tazko odhaduje. Co sa tyka zabijania toho, tak tie co maju "D" sa malo kedy podari zabit (ak to bude nutne, tak to mozem neskorsie rozpisat).

[SAM:]

Ten skript arpwatch_parser.sh je čtyřřádkový skript, který bere soubory arpwatche a sežvýká je do tabulky v textovém souboru.

#!/bin/bash

cd /tmp;

cat /var/lib/arpwatch/eth0.dat | awk '{print $2 "\t" $1 "\t\t" $4}' | sort -t . -k 1,1n -k 2,2n -k 3,3n -k 4,4n > /var/www/localhost/htdocs/arpwatch.txt

exit 1

Teď koukám, že je tam exit 1, což je nesmysl. Jinak se mi nedaří spustit ani busybox, abych mohl zkusit ty množící se procesy zastavit.

[Filip Jirsák]

Podívejte se na ten rozdíl:

15065 ?        Ss     0:00 /bin/bash -c /usr/local/sbin/arpwatch_parser.sh > /dev/null 2>&1
15067 ?        S      0:00 /bin/bash /usr/local/sbin/arpwatch_parser.sh

To první spustí cron, to druhé pak spouští bash nebo váš skript. Nejsem si jist, co dělají > nebo 2>&1, když je předáte jako parametry shellu – ale nespoléhal bych na to, že se to chová stejně, jako když je to součást příkazu shellu.

[Michal Kubeček]

IMHO to nejsou jednotlivé parametry, ale jeden dlouhý parametr, tj. jako když v shellu napíšete

  /bin/bash -c '/usr/local/sbin/arpwatch_parser.sh > /dev/null 2>&1'

[SAM:]

Jediné místo odkud je spouštěn skript arpwatch_parser.sh je právě cron.

[Filip Jirsák]

Buď Vixie Cron z jakéhosi záhadného důvodu zrovna ten váš skript spouští dvěma různými způsoby, čemuž nevěřím, nebo se ten skript spouští ještě jednou, buď z vašeho skriptu, nebo z bashe – jak jsem psal v předchozím komentáři. Nedokážu říct, co dělají ty roztodivné znaky, které tam máte různě rozeseté, a jestli některý z nich nezpůsobuje to opakované spuštění. Pokud vy víte, co dělá středník za cd, co dělá < nebo & jako parametr /bin/bash, bylo by vhodné to sem napsat, ať případně můžeme posoudit, zda to může mít vliv na to opakované spouštění, nebo ne.

[pupu]

Osobne bych v prvni rade zrusil ty presmerovani a vystupy poslal do nejakeho souboru, at je co analyzovat. Za druhe bych tam pridal jednoduchy test, jestli uz skript nahodou nebezi. Pak se uvidi...

[SAM:]

Zlikvidoval jsem přesměrování výstupu a 2>&1. Stroj opět zatuhnul po několika dnech.