On Mon, Jul 31, 2006 at 08:21:50PM +0200, Nico Golde wrote: > Ok after discussing the issue with upstream I decided to > take your initial method because fetchmail is able to decide > itself how to deal with a wake-up when called correctly. > Also if I like the signal based method alot more.
:( Also I preferred the signal based solution. It has a lot of benefits: first of all it prints prettier logs! (su -c "etcetc") Jul 31 20:33:02 eddie fetchmail[3048]: No mail for [EMAIL PROTECTED] at pop.def.gh Jul 31 20:33:02 eddie fetchmail[3048]: No mail for [EMAIL PROTECTED] at pop.lmn.op (kill -SIGHUP ...) Jul 31 20:33:25 eddie fetchmail[2729]: awakened at Mon Jul 31 20:33:25 2006 Jul 31 20:33:27 eddie fetchmail[2729]: sleeping at Mon Jul 31 20:33:27 2006 Note pids: my method starts another process, while the signal one simply says "hello! Check mail please" to the existing process. And in addition, (from fetchmail(1)), "The wake-up action also clears any 'wedged' flags indicating that connections have wedged due to failed authentication or multiple timeouts." So seems to be better in case of network/server problems or password changes: the "su" method will start a new fetchmail, check mail and terminate the process, leaving the background daemon hanging as it was before, while the signal method _"should"_ work it out! (the signal solution seems to me reeeaaally lovable!!!) :) regards Riccardo
signature.asc
Description: Digital signature
