From: Matthias A. <mat...@gm...> - 2010-08-05 00:18:32
|
Am 28.07.2010, 15:44 Uhr, schrieb Thomas Jarosch: > On Wednesday, 28. July 2010 15:31:19 Matthias Andree wrote: >> > 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. > > I just patched that out :o) Before pushing the "new" version to the > productive system, I've verified the coredump gives a useful backtrace. > >> 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. > > No gdb on the productive box. I've just installed the unstripped version > (took me 30min to discover the -s switch in the compile statement. > Whoops). > Now we need to wait a month or so... thanks for your suggestions! Hi Thomas, Well... perhaps not. The attached patch sets the timeout for the getauth() stage (which entails STARTTLS-like negotiation). Please try that too and see if you get timeout reports while fetchmail tries to negotiate TLS. It should. Thanks for the report and offered help in debugging. Would be good if you could report back in a month or so :-) Best regards -- Matthias Andree |