I get the following "syslog" message in /var/adm/messages:

Dec  2 20:40:04 venus innd: ME cant nonblock 15 Operation not supported

Answer: (from paulr@umbc4.umbc.edu (Paul Riddle))

It turns out that this is happening because /usr/spool/news on the
machine running innd is an NFS-mounted filesystem, and innd is trying
to do an FIONBIO on my feed file, which is under /usr/spool/news/out.going.

(tal@plts.org adds:)
All news transports (INN, C news, B news) want the spool partition to
be local.  Newsreader can read from an NFS mounted partition without
any problems but innd should only see local partitions.  NFS has a
blatant disregard for many of the file semantics that are needed for a
good netnews implementation.  If you don't agree, please feel free to
prove the authors of B news, C news, and INN wrong.  Include source
code. :-)

Greg Andrews <gerg@netcom.com> adds:

The spool can certainly be kept on an NFS filesystem without anything
breaking, as the FAQ suggests.  I've kept the spool on an NFS server,
split between two NFS servers, and split between a local filesystem
and two NFS servers.  Reads and writes over NFS tend to be slower
than over local disk, even if the NFS backbone is 100BaseT or CDDI.

The out.going filesystem can be put on an NFS server, but the file
locking becomes a problem on some Unixes.  I bypassed that by
borrowing the lockfile technique I saw in the old "cleanup" release 
of C-News, and writing a replacement for nntpsend in Perl.  I also 
eliminated the numerous 'ctlinnd flush' commands that can choke a 
busy server.  The lockfile technique is pretty simple and seems to 
work well for multiple machines mounting a common out.going filesystem 
via NFS.
The nntpsend replacement script creates a lockfile unique to itself
(using the machine name and PID), and locks sites by hard linking
site lockfiles to its own lockfile.

The newslib filesystem can also be put on the NFS server, though
the only advantage is a minor one:  If everything's on the same
NFS server, you only need to mount one filesystem on the client
machines.

Systems without unix-domain sockets sometimes see this error.  Just
ignore it.

Some parts © 2009 Advameg, Inc.