Date: Tue, 31 May 2005 20:39:47 +0300 From: Andriy Gapon <avg@icyb.net.ua> To: freebsd-stable@freebsd.org Cc: torfinn.ingolfsen@broadpark.no, freebsd-ports@freebsd.org Subject: xffm - xfsamba4 broken in 5-stable? Message-ID: <429CA163.70608@icyb.net.ua>
next in thread | raw e-mail | index | archive | help
I've had the same problem and I think everybody using recent FreeBSD has it. The culprit seems to be the following line in tubo.c: if (kill(PID,SIGCONT) == 0) return TRUE; I am not sure about other OS's and what POSIX mandates in this case, but FreeBSD 5.4 allows to send signals to child processes that have exited but have not been reaped by parent. They show up in ps like this: 5320 pd Z+ 0:00,05 <defunct> Because of the quoted line of code nmblookup processes are never reaped and xfsamba4 goes into infinite loop. Probably FreeBSD 5.1 had problems with respect to the described situation (it was an experimental release after all) and that line was a work-around for some FreeBSD bug, but now it actually breaks things. Removing that line fixed xfsamba4 for me, but I encountered another problem after that, my PDC (NT4) doesn't respond to the following request (Samba3 client): nmblookup -A <master browser ip> so instead I had to use nmblookup -M -S -- - and this made xfsamba4 perfectly well. P.S. just found the following about POSIX, kill, and defunct child processes: http://www.opengroup.org/onlinepubs/009695399/functions/kill.html Existing implementations vary on the result of a kill() with pid indicating an inactive process (a terminated process that has not been waited for by its parent). Some indicate success on such a call (subject to permission checking), while others give an error of [ESRCH]. Since the definition of process lifetime in this volume of IEEE Std 1003.1-2001 covers inactive processes, the [ESRCH] error as described is inappropriate in this case. In particular, this means that an application cannot have a parent process check for termination of a particular child with kill(). (Usually this is done with the null signal; this can be done reliably with waitpid().) -- Andriy Gapon
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?429CA163.70608>