Subject: Re: fetchmail hang, dud read error?
To: Andrew Cagney <email@example.com>
From: Jaromir Dolecek <firstname.lastname@example.org>
Date: 08/15/2002 18:09:20
Andrew Cagney wrote:
> > 8983 fetchmail RET read 24/0x18
> > 8983 fetchmail CALL read(0x3,0x18af000,0x5)
> I think the errno -3 is due to the cntrl-c.
-3 is ERESTART. It's kernel internal thing, the errno is never actually
delivered to userland, it just appears in ktrace.
Don't you happen to have "old" (like more than 6 months) kdump?
kdump contains special code for such ktrace records, and it should
print 'RET read RESTART', rather than 'read -1 errno -3 ...'.
The internal EJUSTRETURN/ERESTART codes changed recently, that's
why kdump should be uptodate to catch this properly.
In other words: fetchmail hangs in read(), waiting for some incoming
data to arrive. The stuff after PSIG SIGINT appears to be executed
by signal handler (terminate_run() of fetchmail?).
> > 8983 fetchmail RET read -1 errno -3 Unknown error: 4294967293
> > 8983 fetchmail PSIG SIGINT caught handler=0x18107c0 mask=() code=0x0
> > 8983 fetchmail CALL write(0x1,0x1893000,0x24)
> > 8983 fetchmail GIO fd 1 wrote 36 bytes
> The above data is jibberish as SSL is also involved (....). Is it
> possible to separate out SSL (using openssl and a fetchmail plugin -- I
> know the plug-in bit just not the openssl bit).
> Right now my theory is that the buffer contains the correct response
> (0006 OK Completed) but also some leading jibberish :-(
Jaromir Dolecek <jdolecek@NetBSD.org> http://www.NetBSD.org/
-=- We should be mindful of the potential goal, but as the tantric -=-
-=- Buddhist masters say, ``You may notice during meditation that you -=-
-=- sometimes levitate or glow. Do not let this distract you.'' -=-