Re: [nmh-workers] strace show # pauses/takes 5+ sec | network issue? ( not nmh )

[nmh]

Hi Ken:

On Sun 9/8/19 18:09 -0400 Ken Hornstein wrote:
>>So what should I be asking my vps provider?  Is this some network issue?
>
>Almost certainly "yes".  If I had to guess I would think it was a DNS
>timeout on something somewhere.

I thought it might be dns. Earlier in the day, twice in a row it hung near the 
end of
this snip:

[...]
socket(AF_INET, SOCK_DGRAM|SOCK_CLOEXEC|SOCK_NONBLOCK, IPPROTO_IP) = 4
connect(4, {sa_family=AF_INET, sin_port=htons(53), 
sin_addr=inet_addr("71.19.155.120")}, 16) = 0
clock_gettime(CLOCK_REALTIME, {tv_sec=1567958940, tv_nsec=908626657}) = 0
poll([{fd=4, events=POLLOUT}], 1, 0)    = 1 ([{fd=4, revents=POLLOUT}])
sendmmsg(4, [{msg_hdr={msg_name=NULL, msg_namelen=0, 
msg_iov=[{iov_base="\325T\1\0\0\1\0\0\0\0\0\0\5ibisbil\4mumble\3org\0\0\1\0\1", 
iov_len=32}], msg_iovlen=1, msg_controllen=0, msg_flags=0}, msg_len=32}, 
{msg_hdr={msg_name=NULL, msg_namelen=0, 
msg_iov=[{iov_base="ql\1\0\0\1\0\0\0\0\0\0\5ibisbil\4mumble\3org\0\0\34\0\1", 
iov_len=32}], msg_iovlen=1, msg_controllen=0, msg_flags=0}, msg_len=32}], 2, 
MSG_NOSIGNAL) = 2

where ibisbil.mumble.com is the obfuscated hostname of the fedora vps with the 
problem, and 71.19.155.120
is the 1st nameserver in ibisbil.mumble.com:/etc/resolv.conf. Later in the day 
though the strace stalled
consistently at the spot shown in my first post.

>But unfortunately these system call traces are not very helpful.  This
>is because you are tracing the command "command", and all that shows is
>you execute a nmh command and it waits 5 seconds for it to complete.

OK/thanks. In the future I will plan to run for example:

    strace -o /tmp/foo -t -f /usr/local/nmh/bin/scan last

>If this happens in the future you should probably use the -f option to
>trace all children of the specified process/command, and the -t option
>to print the system call timestamps (that would let you see exactly
>where the delay is).  I also like using -o to direct the trace output to
>a file rather than having it mixed in with the output of a process.

Appreciate learning about the -t, -f,  and -o switches!

--
Tom