(I post it to mutt-users, too, because I called for help here first and I
realize many mutt users want getmail very much to assist mutt, like me.)
SYMPTOM
getmail always reports things like below in logfile:
retrieved message "3939610e6c2e596fee8bbb94d4c03a54"
new message "<[EMAIL PROTECTED]>": from <<#@[]>>
Aborting... (command "/usr/bin/procmail -m /home/jie/.procmail-filter"
returned -1 ())
and you'll repeately receive the same mail in your mailbox, while
ignoring the rest mails in remote pop server.
ANALYSYS
1. I can not blame procmail because it finished delivery, it has no
error in its log, and it exits with 0 if I run it from bash(1).
2. I check procmail mailing list archive: 2001-12/msg00036:
Re: Procmail returning -1 (trace of procmail spawned from getmail)
which concluded:
That getmail is seeing a different exit status would seem to
indicate that there's a bug in getmail...
3. I recalled and checked bash(1) that exit values range only from 0
to 255. The 'returned -1' is strange.
4. I looked into getmail.py and identified where the message from.
It appears like:
cmd = popen2.Popen3 (command, 1, bufsize=-1)
...
r = cmd.poll ()
if err or r:
raise getmailDeliveryException, 'command "%s" returned %i (%s)' \
% (command, r or 0, err)
5. I searched in Web for what's "poll" (I have no idea about
Python.) and get:
class Popen3
Class representing a child process. Normally instances are
created by the factory functions popen2() and popen3().
poll(self)
Return the exit status of the child process if it has finished,
or -1 if it hasn't finished yet.
wait(self)
Wait for and return the exit status of the child process.
6. Now it's clear that getmail.py using 'poll' is responsible for
the early aborting. getmail should not quit the game just because
his team member can not work as fast as him. ;-)
That 'poll' returns -1 doesn't indicate an error. It's just the
case the child process has not yet finished. It's not an exit
value of child process, either.
ACTION
Fix the bug by replacing the 'poll' with 'wait' in /usr/lib/getmail/getmail.py.
Now my getmail does a good job.
best regards,
charlie
P.S.
I've tried to use maildrop other than procmail, while having the
following log message:
Aborting... (command "/usr/bin/maildrop ~/.maildroprc" returned 19200 (maildrop:
signal 0x06))
I can not explain the 'returned 19200'. For someone's exercise. ;-)
