Re: [Fetchmail-users] Flush `Trying to connect...' Message.

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

Am 13.06.2018 um 07:51 schrieb Ralph Corderoy:
> Hi Mattias,
>
>>> If a server is slow to accept a connection then I find the `Trying
>>> to connect to 1.2.3.4/993' message only appears on SIGINT whereas it
>>> would be useful to know that's what's being attempted during the
>>> delay.  Please flush this part of the line rather than having it
>>> appear only when the whole line is finished.
>>>
>>> This `two part line' style of output may occur elsewhere and need
>>> flushing benefit from flushing there too.
>> Please heed <http://www.fetchmail.info/fetchmail-FAQ.html#G3>
> fetchmail 6.3.26-6 on Arch Linux.
>
> To re-create the problem, run this Perl script to listen(2) on TCP
> socket 31415, but not accept(2).
>
>     #! /usr/bin/perl -w
>
>     use Socket;
>
>     socket(Server, PF_INET, SOCK_STREAM, getprotobyname('tcp')) &&
>     bind(Server, sockaddr_in(31415, INADDR_ANY)) &&
>     listen(Server, 0) or die;
>
>     print "sleeping\n";
>     sleep(3600);
>
> Then run fetchmail whilst Perl's sleeping, hitting Enter when prompted
> for a password.
>
>     LC_ALL=C fetchmail -f /dev/null -v -p imap -P 31415 127.1
>
> I see
>
>     Enter password for ralph@127.1: 
>     fetchmail: 6.3.26 querying 127.1 (protocol IMAP) at Wed Jun 13 06:46:17 2018: poll started
>
> After waiting a while I Ctrl-C to send SIGINT.
>
>     ^CTrying to connect to 127.0.0.1/31415...fetchmail: terminated with signal 2
>     $
>
> If that doesn't happen because the connection succeeds then stop
> fetchmail and re-run it;  it's probably the listen(2)'s queue implicitly
> accepting the connection.
>
> My desired output is
>
>     Trying to connect to 127.0.0.1/31415...^Cfetchmail: terminated with signal 2
>
> where the text before `^C' appeared without the SIGINT.
>
Hi Ralph,

Confirmed. Fetchmail buffers that internally, trying to collect a full
log line, with the result printed or syslogged on the same line, that's
why it buffers the part of the line without sending it anywhere. The
thing is also that internally, this isn't error logging...
The immediate but expensive patch for this particular situation is
attached (in case the list strips it, I am Cc'ing you) against the
legacy_64 branch from Git (on gitlab.com), but a proper fix needs more
changes all over the map.

Best regards,
Matthias