Re: [exim] stuck exim processes

Top Page
Delete this message
Reply to this message
Author: Evgeniy Berdnikov
Date:  
To: exim-users
Subject: Re: [exim] stuck exim processes
On Thu, Feb 17, 2022 at 07:36:38PM -0800, Michael Tratz via Exim-users wrote:
> > On Feb 16, 2022, at 4:17 PM, Jeremy Harris via Exim-users <exim-users@???> wrote:
> >
> > You don't even get a single line from truss as it attaches?
> > I wonder if the process is spinning in userland?
> > Does "top" or similar show it?
>
> That stuck process is just sitting there and not doing anything. It still shows in top, but it’s just idle.


Process can't be "just idle", it must have its state and data structures,
the most interesting is stack. Process state may displayed with "ps wchan":

ps -p <pid> -o pid,wchan,cmd

Stack may be printed by debugger:

gdb -p <pid> -f /path/to/exim
(gdb) bt full

But output from gdb won't be useful unless gdb can access to tables
with local symbols, as Jeremy pointed:

> > If it is, I guess the next step would be to crash it with
> > a signal, having set up for coredumps (NB, exim is a setuid binary
> > in most installations. Security considerations apply).
> > Of course, it was likely compiled with full optimisation
> > which will hinder us. Having a "-O0 -ggdb" build would
> > help. I don't know what FreeBSD does about debuginfo;
> > is that likely to be a separate install item, to get
> > symbols for the binary?


The puzzling thing is that truss "shows nothing" on attach.
It may be indication of some kernel bug, which may also affect behaviour
of gdb. I suspect we observe abnormal process state similar to "zombie",
say, process deletion is not completed but userspace data structures
are already deleted.
--
Eugene Berdnikov