I used to do this however, with version 5.9.0 I have not experienced this failure. Bill Mullen wrote: > > When you execute fetchmail, either as a cron job or at the command line, > you can include the --quit parameter to kill the existing instance of the > daemon before restaring with the other parameters on the line. So, a cron > entry such as: > > 30 */2 * * * fetchmail --quit -d 600 > > would kill & restart the daemon every 2 hours. > > > On Sat, 29 Dec 2001, Karl J. Runge wrote: > > > I believe we are seeing the same problem. My wife has this > > cronjob set up to run every two hours: > > > > 20 */2 * * * fetchmail -d 600 m1x >> $HOME/.fetchmail.err 2>&1 > > > > "m1x" is her mediaone alias in ~/.fetchmailrc > > > > Every week or so (sometimes more frequent) the fetchmail process will > > get hung somehow and not try to fetch any new mail. Sometimes for days > > if we don't notice (my wife is somewhat lax about her personal email... > > we'd have fix this by now if it was her work mail :-) > > > > The only thing I can think of is to kill the fetchmail process > > periodically from another cron entry just to keep things going. > > > > How frequently does it go into this state for you? Ours is too > > infrequent to debug easily. I will try to do some more diagnostics > > (netstat, lsof, ...) next time fetchmail gets in this state. > > > > > > On Sat, 29 Dec 2001, [EMAIL PROTECTED] (Michael O'Donnell) wrote: > > > > > > > > I instruct fetchmail to go into the background > > > and contact my ISP's POP server every so > > > often to haul newly arrived messages onto > > > the local disk. It seems that every so > > > often the daemon gets stupid, continuing > > > to run but failing to notice newly arrived > > > email, even if I kick it in the prescribed > > > manner with another (non-daemon) instance. > > > I'll notice after a while that I've not seen > > > any new messages for some time so I'll kill > > > and restart the fetchmail daemon and that > > > new incarnation will then notice and transfer > > > all the waiting messages that the stuporous > > > incarnation had been seemingly unaware of. > > > > > > I haven't yet gone to the trouble of doing > > > a serious debug (like with strace) of this > > > problem, yet. Anybody heard of this problem > > > or have any ideas about what could be wrong? > > > > > > ***************************************************************** > > To unsubscribe from this list, send mail to [EMAIL PROTECTED] > > with the text 'unsubscribe gnhlug' in the message body. > > ***************************************************************** > > > > -- > > Bill Mullen > [EMAIL PROTECTED] > Dec 29, 2001 > > > ***************************************************************** > To unsubscribe from this list, send mail to [EMAIL PROTECTED] > with the text 'unsubscribe gnhlug' in the message body. > ***************************************************************** >
-- Jerry Feldman <[EMAIL PROTECTED]> Boston Linux and Unix user group http://www.blu.org PGP key id:C5061EA9 PGP Key fingerprint:053C 73EC 3AC1 5C44 3E14 9245 FB00 3ED5 C506 1EA9 ***************************************************************** To unsubscribe from this list, send mail to [EMAIL PROTECTED] with the text 'unsubscribe gnhlug' in the message body. *****************************************************************
