Am 22.01.25 um 16:16 schrieb Francesco Potortì:
I made this an upstream feature request recorded at
https://gitlab.com/fetchmail/fetchmail/-/issues/65
In fact, when the problema appears, reading the message at the end of the list
may not be enough, as when fetchmail meets it, it hangs, so no messages are in
fact read (with POP, at least). The only solution would be to skip that
message entirely.
Or finding the bug, but it took me awhile to setup debugging for the case of
that message, but did not work. I can think of a lot of other things to do,
but that would require too much time :(
The actual thing is finding out the cause of this hang, and treating it
properly. A backtrace would be good, and we probably need to hack the
source code to deliberately set the timeout timer (setitimer), but avoid
trapping the related SIGALRM handler or letting it run through
sigsetjmp/siglongjmp -- because that unwinds the stack and we lose the
backtrace and where the issue happened. That's assuming a timeout causes
the socket error, and not something server side, not something in the
network, not some kernel or router bugs, and no genuine errors of
communication that would cause the socket error. That would be only for
debug use, not for "productive" use. This can then be wrapped in a
debugger such as gdb or lldb and at least gdb can be told to pass
arguments to the executable to debug and auto-run it.
A somewhat more complete approach has been committed to Gitlab onto this
branch:
<https://gitlab.com/fetchmail/fetchmail/-/tree/fetchmail65-linux-backtrace-on-timeout?ref_type=heads>
It requires meson to build and is currently slightly past fetchmail
6.5.2, but I don't believe your log showed a timeout. At least fetchmail
6.5.2 would additionally report a timeout on the line before the socket
error, so this appears to be something else.
It might also be that the local mda you seem to be forwarding to acts up
and the socket error isn't from input but output. Dot-stuffed lines can
cause this. But we really need a way to reproduce this, including most
of your configuration (I don't need hostnames, passwords, usernames
currently), else we're poking in the dark.
