Re: [exim] av_scanner is broken suddenly?

Top Page
Delete this message
Reply to this message
Author: Evgeniy Berdnikov
Date:  
To: exim-users
Subject: Re: [exim] av_scanner is broken suddenly?
On Wed, Dec 30, 2020 at 02:25:19PM +0700, Victor Sudakov via Exim-users wrote:
> Evgeniy Berdnikov via Exim-users wrote:
> > Yes, I have. And have you looked at packet time stamps?
> > IMHO, 3-5 us time interval between SYN-ACK and RST is
> > too low for userspace responce.
>
> Well, the whole story is happening within one hypervisor (bhyve) so
> network delays can be very low.


It does not matter: any hypervisor should perform a context switch bitween
kernel process and userspace process, even for container virtulization.
It's havy task.

> > However, get strace as Jeremy suggested.
> > I expect ECONNREFUSED on connect().
>
> Is this ktrace informative https://termbin.com/zjsv ?


I have never seen such a trace before... However, it seems that relevant
part for connection to 192.168.153.104:3310 is here:

  8889 exim     CALL  socket(PF_INET,0x1<SOCK_STREAM>,IPPROTO_IP)
  8889 exim     RET   socket 5
  8889 exim     CALL  setitimer(0,0x7fffffff30d0,0x7fffffff30b0)
  8889 exim     STRU  itimerval { .interval = {0, 0}, .value = {5, 0} }
  8889 exim     STRU  itimerval { .interval = {0, 0}, .value = {0, 0} }
  8889 exim     RET   setitimer 0
  8889 exim     CALL  setsockopt(0x5,IPPROTO_TCP,TCP_FASTOPEN,0x254270,0x4)
  8889 exim     RET   setsockopt 0
  8889 exim     CALL  sendto(0x5,0x2322d6,0xa,0,0x7fffffff3150,0x10)
  8889 exim     STRU  struct sockaddr { AF_INET, 192.168.153.104:3310 }
  8889 exim     GIO   fd 5 wrote 10 bytes
       "zINSTREAM\0"
  8889 exim     RET   sendto 10/0xa
  8889 exim     CALL  setitimer(0,0x7fffffff30d0,0x7fffffff30b0)
  8889 exim     STRU  itimerval { .interval = {0, 0}, .value = {0, 0} }
  8889 exim     STRU  itimerval { .interval = {0, 0}, .value = {4, 999970} }
  8889 exim     RET   setitimer 0
  8889 exim     CALL  close(0xffffffff)
  8889 exim     RET   close -1 errno 9 Bad file descriptor


As packet is sent, it may be some problem with TCP_FASTOPEN, probably
with its handling in hypervisor and/or external firewall.

Consequent close(-1) is definitely an error, but let us ignore it now.
Then exim reads file and tries to write into this socket:

  8889 exim     CALL  sendto(0x5,0x7fffffff3344,0x4,0,0,0)
  8889 exim     RET   sendto -1 errno 57 Socket is not connected
  8889 exim     CALL  close(0x5)


So, the fact that connection is broken is not visible for exim process.

BTW, this trace may be more meaningful with time stamps, turn them on
if possible.
--
Eugene Berdnikov