From: Matthias A. <mat...@gm...> - 2010-07-28 15:31:24
|
Am 28.07.2010 11:31, schrieb Thomas Jarosch: > On Tuesday, 27. July 2010 16:56:52 Matthias Andree wrote: >> > I recently had two cases of hanging fetchmail processes >> > during TLS negotiation with two different servers. >> >> Might be a missing call to set_timeout() around the POP3 STLS/getauth() >> related methods. Try wrapped SSL ("ssl" option) as a workaround, it >> might help, and if so, help debugging. > > The issue only appears every other month or so. I also thought about adding > debug output to set_timeout() so we could trace the last set timeout, > though this will only give a close approximation where that problem is. > (or none at all if the code mostly uses the same timeout values) > > This morning I had a better idea: Enable core dumps and kill the task via > "kill -11" if it hangs again. Then we'll know for sure where it's stuck. Don't. fetchmail in most modes suppresses writing core files with setrlimit(), to avoid passwords hitting the disk outside the .netrc or .fetchmailrc files. Instead, if fetchmail hangs, just attach gdb with "gdb /usr/bin/fetchmail-unstripped 12345", where fetchmail-unstripped is an executable compiled with -g or better -ggdb3 option, and installed before the run, without running strip and without adding -s to the install command line. Then, once gdb has attached to the hanging process, "backtrace full" will provide the necessary debug output. Inside gdb you can issue "signal 2" (SIGINT) and "continue" to have fetchmail terminate the run in an orderly manner. > I prefer not to add the workaround for now > as I'd like to trace the real issue. :) -- Matthias Andree |