Re: [Fetchmail-devel] Imap idle and SIGUSR1

[Matthias A. <mat...@gm...>]

Am 07.03.2017 um 14:33 schrieb Jef Driesen:
> Hi,
>
> I have a fetchmailrc to poll a single imap server, with the "idle" 
> option enabled for instant notifications. This works really great, 
> except that once in a while, the server appears to get confused. It 
> still responds to the idle command as it should:
>
> fetchmail: IMAP> A0117 IDLE
> fetchmail: IMAP< + idling
> fetchmail: IMAP> DONE
> fetchmail: IMAP< A0117 OK IDLE completed
> fetchmail: IMAP> A0118 IDLE
> fetchmail: IMAP< + idling
> fetchmail: IMAP> DONE
> fetchmail: IMAP< A0118 OK IDLE completed
>
> But for some reason it doesn't notice new mail has arrived. This is 
> probably a server side bug, for which I'm trying to find a workaround.

There is none in fetchmail.

> I tried to send SIGUSR1 to wakeup the fetchmail daemon. But that doesn't 
> seem to have any effect. It looks like fetchmail ignores the signal 
> while it's waiting on idle. Is that intentional? I would expect it to 
> end the idle, and start a new poll.

SIGUSR1 is set to SIG_IGN all the time, except when fetchmail is
sleeping at the end of a poll and waiting for the daemon sleeping
interval to expire before the next poll. There might be a nasty
interaction around EINTR pseudo-failures to system calls while signals
are delivered in the IDLE mode, because we already have a SIGALRM-based
path for read timeouts (in case the system doesn't figure the connection
has gone down).

> How can I force fetchmail to start over, other than restarting the 
> daemon completely?

Currently you can't, sorry. IDLE is fraught with limitations and
"cannot"s and whatnot, and it appears that upstream servers also have
their quirks judging from your observation. Short of reviewing,
redesigning and rewriting considerable parts of fetchmail's concept and
implementation, that cannot easily be fixed, and I wonder if other IMAP
extensions might be more useful.