At 6:48 PM -0400 6/19/06, Gerard E. Seibert wrote:
OS: FreeBSD 6.1 Stable
I am not sure if this is a qpopper problem or not. I have several
accounts that I use 'fetchmail' to gather for me. One of these
accounts can grow quite large. All too frequently, when I attempt
to POP mail from this account from another computer on my network,
the action fails. This is the message I find in the
/var/log/messages file:
Jun 19 18:21:50 seibercom qpopper[2839]: I/O error flushing output
to client spamcop at boss [192.168.0.3]: Operation not permitted (1)
I think that generally means the client has disconnected, often
because it timed out, and Qpopper never got a SIGHUP. Are you
running the latest Qpopper? There were some bugs fixed that closed
some situations in which Qpopper didn't get the signal.
'spamcop' is the name of the account and 'Boss' is one of the
computers on the network.
If I attempt to open the file with 'pico' I receive an error
message that the file has a long line.
You normally wouldn't expect a spool to have lines that long. That
does suggest some sort of corruption.
Does anyone have any suggestions as to what is happening here and
how to rectify it?
You could enable Qpopper tracing and/or use truss(1), ktrace(1), or
similar tool on the popper process, to try and see what is going on.
To enable tracing in Qpopper:
1. Do a 'make clean'
2. Re-run ./configure, adding '--enable-debugging'.
3. Edit the inetd.conf line for Qpopper, adding '-d' or '-t <tracefile-path>'.
4. Send inetd (or xinetd) a HUP signal.
(Steps 3 and 4 are only needed if you use inetd (or xinetd). In
standalone mode, you can add '-d' or '-t <tracefile-path>' to the
command line directly.)
(In either standalone or inetd mode, if you use a configuration file
you can add 'set debug' or 'set tracefile = <tracefile>' to either a
global or user-specific configuration file instead of steps 3 and 4.)
This causes detailed tracing to be written to the syslog or to the
file specified as 'tracefile'.
