Created attachment 2567 [details]
spamd -D log

Created attachment 2568 [details]
truss output for parent process

gzipped for length

Created attachment 2569 [details]
truss output for child process

The attached files were created by starting spamd with --max-conn-per-child=1,
then sending a single message, causing one of the children to become a zombie. 
spamd was then manually shut down with SIGTERM.

hmm, no sign of the child exiting in that truss output.  in fact, the child
truss output looks very incomplete -- it reads the passwd and spwd files, then
does no more system calls?

ideally there'd be a SIGCHLD in one or an _exit() in the child ;)

I know what you're saying, but that's where truss exited.  The process was a
zombie after that.

??

so it became a zombie without exiting?  I don't know *that* much about BSD on
Alpha, but surely that's impossible ;)   any chance you can get more data from
truss?

I'm not sure how.  I'm not terribly familiar with it, I'm just going by the
manpage.  I tried attaching it to the child processes twice and both times truss
exited with the same results.  I'm probably doing something wrong, but there
aren't a lot of options associated with truss.  I have no clue why it's exiting
before it logs the child's exit.

The command line I used was "truss -o child-truss.txt -p <pid of child>".  I'm
open to suggestions.

I believe that the definition of zombie (as far as computers are concerned)
is that the process is dead in that it can no longer execute any code and
should be exiting, but it is undead in that the final exit can not happen.
If I remember correctly, the child process is waiting (or the operating
system is waiting) for the parrent to reap the child.

The point of my last comment is that you can not truss a process that is a
zombie because it really does not exist.  If you truss it before it becomes
a zombie, I would expect that you would see every thing that it did before
becomming a zombie.  You will not see an exit as the process did not exit.
I expect that this is a Perl bug, possibly with child/parrent communication
when running on FreeBSD/Alpha.  Hopefully a newer version of Perl will fix
this.

I may have to wait for them to fix perl 5.8, then.  Currently it will compile on
Alpha, but pack() and unpack() fail testing, so it's not usable on that platform.

David -- just checking -- does this problem still exist for you? 

I've upgraded to FreeBSD 4.11-RELEASE since then, and rebuilt Perl.  The
children no longer become zombies, but they still don't respawn.  Eventually I'm
left with just the one original spamd process running, and no children.  If I
kill -HUP the process, the children are spawned.

I really suspect some kind of process handling bug in Perl on the Alpha platform.

It's not really a problem for me now...I just set --max-conn-per-child to a high
number, and since I'm now running rules du jour the process gets restarted every
so often anyway.

I'm now running 3.1.0-pre3 and it doesn't exhibit the problem.  Something in the
new forking algorithm must have fixed it.