Re: [exim] stuck exim processes

トップ ページ
このメッセージを削除
このメッセージに返信
著者: Michael Tratz
日付:  
To: exim-users
題目: Re: [exim] stuck exim processes


> On Feb 16, 2022, at 4:17 PM, Jeremy Harris via Exim-users <exim-users@???> wrote:
>
> (taking the 2xx variant)
>
>> I tried truss to trace the system calls of both processes. 77631 is not printing anything.
>
> 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.
I will see if I can find another one and let truss run overnight maybe it will print something after waiting for a long time. I may not have been patient enough. :-)

>
> 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?


I haven’t had time to recompile the port with the debug symbols. I will do so once I can. Right now I’m pretty swamped with other things on my to-do list.

>
> --------
>
>> This happens for messages which get a 4xx or 5xx error.
>
> For all 4xx/5xx ? Or "when it goes wrong, for those, that's
> how it goes" ?


Again not for all. Just if it goes wrong exim does that same pattern. I did notice it happens consistently with certain remote servers. For example. smtp.secureserver.net <http://smtp.secureserver.net/> (GoDaddy) seems to always be a good culprit. I see a lot issues with them. But this wasn’t the case with 4.94.2 Another one was cloudmail102.zonecybersite.com <http://cloudmail102.zonecybersite.com/>. There are more, but I just started looking if I add certain servers to hosts_avoid_tls if I get less of those stuck processes.

Thanks,

Michael