Bjoern Labitzke <hermit@labitzke.isdn.cs.tu-berlin.de> writes:
> In pine it looks like
> this: I want to send an encrypted mail, so the encryption filter with pgp
> is called. PGP does its work, exits, but remains in zombie state and pine
> waits for ages. When I kill pine, the zombie PGP gets cleaned up. The same
> happens with a sendmail process, when I want to send a mail. The mail gets
> sent, sendmail exits, but stays in zombie state, until I kill pine.

That's easy.

A process has to wait(2) for its children. Until it does, the children 
are "zombies" -- stubs of processes that exist mostly to preserve exit 
information so that wait(2) can function.

When a parent fails to wait(2) for its children, you can observe the
zombies. Once it wait(2)'s for them, they go away. If the parent exits 
WITHOUT wait(2)ing for them, the orphaned zombies are inherited by
init(8), process ID 1, and it wait(2)s for them, thus making them go
away.

Obviously Pine is somehow not wait(2)ing for the processes. This must
be a bug in Pine, or in the way that Pine has been configured.

It is *vaguely* possible that there has been a bug introduced into the 
OS, but if there was, a lot more people would be noticing it. You
might want to ktrace pine and see if it ever calls wait(2) properly.

> BTW: My xemacs 20.4 stopped working, too. It is dumping core now when
> started. I am not sure when I used it the last time, but I guess it was
> sometime in the last four weeks. Before that I never had any problems.
> Even the build of xemacs from the package now dumps core. 

Somehow I doubt that this is an xemacs or a system problem, because
I'm running xemacs right now on a fairly recent kernel and it is
working fine.

Perry