Cron greške u logovima ("grandchild failed")

U logovima se mogu naći svakakvi zapisi, i oni korisni i oni koji naoko samo smetaju. Ponekad izgledaju opasno, kao da će server svaki čas pasti, a ponekad ne možemo naći nikakav koristan zapis, mada server ima proglema u radu. Nisam znao u koju kategoriju spada zapis koji mi se pojavljuje dva puta dnevno u logovima:

Dec 17 03:09:01 zakon /USR/SBIN/CRON[31050]: (root) CMD (  [ -d
  /var/lib/php4 ] && find /var/lib/php4/ -type f -cmin
  +$(/usr/lib/php4/maxlifetime) -print0 | xargs -r -0 rm)

Dec 17 03:09:01 zakon /USR/SBIN/CRON[31049]: (CRON) error (grandchild
#31050 failed with exit status 1)

Da nema potrebe za panikom pokazao je članak na Portalu.  Tamo nažalost nisam pronašao informaciju koja bi u mom slučaju pomogla da otkrijem koja skripta u cronu prouzrokuje ove poruke, ali sam dobio ideju da provjerim je li u pitanju kakva zaostala datoteka iz starog paketa. Provijerimo što se sve nalazi u cron.d direktoriju, gdje se nalaze skripte koje cron pokreće:

# ls -l /etc/cron.d
total 18
-rw-r--r-- 1 root root  460 Dec 17  2003 amavisd
-rw-r--r-- 1 root root  755 Sep  1  2011 amavisd-cn
-rw-r--r-- 1 root root  196 Jun 14  2008 amavisd-new
-rw-r--r-- 1 root root  244 May 31  2004 anacron
-rw-r--r-- 1 root root  694 Jan  2  2010 clamav-unofficial-sigs
-rw-r--r-- 1 root root  357 Feb  1  2010 cron-apt
-rw-r--r-- 1 root root  355 Feb  1  2010 cron-apt~
-rw-r--r-- 1 root root  384 Jan 30  2012 freeradius-aai
-rw-r--r-- 1 root root  607 Jun  2  2008 john
-rw-r--r-- 1 root root  347 Jul  9  2004 logcheck
-rw-r--r-- 1 root root 1424 Jun 15  2012 mailman
-rw-r--r-- 1 root root  589 Jan 18  2012 mdadm
-rw-r--r-- 1 root root  270 Oct  5  2010 munin
-rw-r--r-- 1 root root  506 Oct 17  2006 munin-node
-rw-r--r-- 1 root root  456 Sep  6  2004 php4
-rw-r--r-- 1 root root  475 Mar 19  2011 php5
-rw-r--r-- 1 root root  239 Oct 30  2006 postfix-cn

Prvo upadaju u oči stare datoteke, te kopije koje ostavlja moj omiljeni editor "joe". A onda, uz sve to, može se uočiti i datoteka php4. Zar nismo davno prešli na php5? Jesmo. Pa onda možemo tu datoteku obrisati. Ali, nećemo je zravno brisati jer priapada nekom paketu, pa treba obrisati cijeli paket. Na sys.helpu su mi davno odgovorili kako to treba napraviti, pa da vidimo:

# cat /etc/cron.d/php4
# Look for and purge old sessions every 30 minutes
09,39 *     * * *     root   [ -d /var/lib/php4 ] && find /var/lib/php4/  -type f -cmin +$(/usr/lib/php4/maxlifetime) -print0 | xargs -r -0 rm

# dpkg --search /etc/cron.d/php4
php4-common: /etc/cron.d/php4

# apt-cache rdepends php4-common
<php4-common>

# dpkg -P php4-common
(Reading database ... 85066 files and directories currently installed.)
Removing php4-common ...
Purging configuration files for php4-common ...

Prvo sam s parametrom "--search" potražio paketu kojem pripada datoteka /etc/cron.d/php4, a zatim pomoću naredbe apt-cache rdepends pogledao koji paketi ovise o paketu "php4-common". Ne ovisi ni jedan, dakle možemo ga obrisati! (Usporedite ispis sa primjerice naredbom "apt-cache rdepends php5-common").

A što da se datoteka php4 nije ovako isticala, kako bismo mogli naći uzročnika poruka u logovima? Nakon malo proučavanja, možemo vidjeti da cron prijavljuje PID procesa koji nije uspješno završio (u ovom slučaju to je 31050). Na ovaj način možemo identificirati naredbu unutar skripte koja nije završila uspješno, pa ostaje samo izgrepati u kojoj se datoteci ta naredba nalazi.

Treća opcija je "zaprljati ruke", te odmah pogledati unutar svih cron datoteka gdje bi se mogao naći problematičan unos. Recimo, možemo probati pokrenuti naredbe unutar skripti:

# find /var/lib/php4/ -type f -cmin +$(/usr/lib/php4/maxlifetime) ; echo $?
bash: /usr/lib/php4/maxlifetime: No such file or directory
find: missing argument to `-cmin'
1

Dakle, uzrok je greške nepostojanje direktorija /usr/lib/php4/maxlifetime. Slične greške mogu prouzročiti različite naredbe. Po tome možete prepoznati o kojoj se skripti radi. Pripazite da skripte pokrećete kao neprivilegirani korisnik, ako je tako pokreće i cron. Neke stvari možete pokvariti ako slijepo pokrećete skripte kao korisnik root.

Zadnja mogućnost je da pogledate kada se izvršila skripta. Tada jednostavno pregledajte sve skripte u cron.d i potražite to vrijeme.

Nadam se da je pomoglo, ukoliko ste imali sličan problem.