The following issue has been set as RELATED TO issue 0000361. ====================================================================== http://www.dbmail.org/mantis/view.php?id=370 ====================================================================== Reported By: ryo Assigned To: ====================================================================== Project: DBMail Issue ID: 370 Category: General Reproducibility: sometimes Severity: minor Priority: normal Status: feedback target: 2.1.7 ====================================================================== Date Submitted: 21-Jun-06 13:57 CEST Last Modified: 22-Jun-06 07:02 CEST ====================================================================== Summary: waitpid() in ParentSigHander() function shuld be called multiple time for zombies. Description: This issue is related to http://www.dbmail.org/mantis/view.php?id=361 (already resolved).
I update to svn2184, but I had any zombies. I think that when the parent process recieved multiple SIGCHLD at the same time the signal handler is called only once on UNIX system. So, waitpid() in ParentSigHander() function shuld be called multiple time for zombies. In addition, it seems that the waipid() function is not called (after call kill()) in the manage_stop_chldren function. I create the patch. Please see the attached file(dbmail-nozombie.patch). ====================================================================== Relationships ID Summary ---------------------------------------------------------------------- related to 0000363 Somtimes the count of grandchild proces... related to 0000361 IMAP zombies after about a day. ====================================================================== ---------------------------------------------------------------------- paul - 21-Jun-06 16:30 ---------------------------------------------------------------------- patch accepted ---------------------------------------------------------------------- aaron - 21-Jun-06 18:09 ---------------------------------------------------------------------- Wait, is this guaranteed not to deadlock? I think I'd rather have a for loop with a finite number of attempts, followed by some ominous trace message that there's a zombie on the loose. ---------------------------------------------------------------------- ryo - 22-Jun-06 04:19 ---------------------------------------------------------------------- According to the man page of waitpid, the retrun value of waitpid function is as follows. RETURN VALUE The process ID of the child which exited, or zero if WNO- HANG was used and no child was available, or -1 on error (in which case errno is set to an appropriate value). If zombie process does not exist then the waitpid function returns zero or -1. So, the program maybe is not locked by the while loop of my patch. I think that if you worry about the "while loop" lock then you limit the times of loop(eg, to HARD_MAX_CHILDREN). For example as follows. #include <pool.h> : int cnt = 0; : while((chpid = waitpid(-1,&sig,WNOHANG)) > 0 && (cnt++ < HARD_MAX_CHILDREN)) scoreboard_release(chpid); ---------------------------------------------------------------------- aaron - 22-Jun-06 06:12 ---------------------------------------------------------------------- Oh wait, sorry, I misread the patch. The situation that might lead to an infinite loop is if there is some child that is not a zombie and yet does not terminate. Is there a possibility of this occurring? ---------------------------------------------------------------------- ryo - 22-Jun-06 07:02 ---------------------------------------------------------------------- I think that if the waitpid() system call does not have any bug then an infinite loop does not occur. But I think that the program had better limit the times of loop by way of precaution (like the example of 0001263). Issue History Date Modified Username Field Change ====================================================================== 21-Jun-06 13:57 ryo New Issue 21-Jun-06 13:57 ryo File Added: dbmail-nozombie.patch 21-Jun-06 16:30 paul target => 2.1.7 21-Jun-06 16:30 paul Note Added: 0001256 21-Jun-06 16:30 paul Status new => resolved 21-Jun-06 16:30 paul Resolution open => fixed 21-Jun-06 16:30 paul Fixed in Version => SVN Trunk 21-Jun-06 18:09 aaron Note Added: 0001261 22-Jun-06 04:19 ryo Status resolved => feedback 22-Jun-06 04:19 ryo Resolution fixed => reopened 22-Jun-06 04:19 ryo Note Added: 0001263 22-Jun-06 06:12 aaron Note Added: 0001264 22-Jun-06 07:02 ryo Note Added: 0001265 03-Jul-06 12:54 paul Relationship added related to 0000363 03-Jul-06 12:56 paul Relationship added related to 0000361 ======================================================================