Bjorn Wiren <etxbwir(_at_)cbe(_dot_)ericsson(_dot_)se>:
I can't explain why adding "set syslog" fixes the daemon's behavior.
Since my last posting, I've found that the fetchmail daemon *always*
dies (silently) if I force it to re-read `.fetchmailrc', be it due to
a trivial modification or even just a `touch'.
I can't reproduce this:
snark:~$ cd ~/WWW/fetchmail
snark:~/WWW/fetchmail$ fetchmail
snark:~/WWW/fetchmail$ ps ax | grep fetch
3368 pts/0 S 0:00 mutt -z -f =fetchmail
3388 ? S 0:00 fetchmail
3487 pts/1 S 0:00 grep fetch
snark:~/WWW/fetchmail$ touch ~/.fetchmailrc
snark:~/WWW/fetchmail$ ps ax | grep fetch
3368 pts/0 S 0:00 mutt -z -f =fetchmail
3388 ? S 0:00 fetchmail
3492 pts/1 S 0:00 grep fetch
snark:~/WWW/fetchmail$
I was falsely under the impression that authentication failure was the
reason for the crash; in order to test auth fail behaviour, I
intentionally hosed the password in `fetchmailrc', but it was actually
the re-reading bug that killed it. If I instead change the remote
password, the daemon keeps going.
The reason for silent death in case `.fetchmailrc' is *broken* is
explained in the man pages ("Bugs and known problems" near the end),
but the fact that it dies although `.fetchmailrc' is correct must be
considered a bug.
I have now made a self rescheduling at-job that monitors fetchmail - a
real clumsy solution, but it works. (Hmm, I might just as well use the
`at' mechanism *instead* of daemon mode, checking the exit code each
time.)
Hm. Could you possibly try using strace ot gdb to figure out why your
copy is dying?
--
<a href="http://www.tuxedo.org/~esr/";>Eric S. Raymond</a>