innfeed error

[Jan Ingvoldstad]

On Tue, 10 Apr 2001 15:03:20 -0400, Emily Hall-Girard
<ehallgirard at advisortech.com> said:

> moya innfeed[30043]: ME source lost . Exiting

> (This example is pulled from the spooler file on my moya server)

> The feeds are not communicating with one and other and I am not sure
> what there errors mean.

Basically, innd went bye-bye.

See what innfeed and innd were doing shortly before and after that; it
may be a configuration issue, or something else that is obvious from
the context (example from a news.notice log, hostnames and dates
changed to protect the guilty):

  Apr 10 21:55:30 nntp.example.com innd: innfeed! closed
  Apr 10 21:55:30 nntp.example.com innd: controlchan! closed
  Apr 10 21:55:30 nntp.example.com innd: control:12 closed
  Apr 10 21:55:30 nntp.example.com innd: localconn:14 closed
  Apr 10 21:55:30 nntp.example.com innd: remconn:5 closed
  Apr 10 21:55:30 nntp.example.com innd: ME HISstats 0 hitpos 0 hitneg 0 missed 0 d
  ne
  Apr 10 21:55:30 nntp.example.com innfeed[9364]: ME source lost . Exiting
  Apr 10 21:55:30 nntp.example.com innfeed[9364]: news-feed final seconds 25 offere
  d 0 accepted 0 refused 0 rejected 0 missing 0 accsize 0 rejsize 0 spooled 0 on_c
  lose 0 unspooled 0 deferred 0/0.0 requeued 0 queue 0.0/200:100,0,0,0,0,0
  Apr 10 21:55:30 nntp.example.com innfeed[9364]: news-feed:0 final seconds 25 offe
  red 0 accepted 0 refused 0 rejected 0 accsize 0 rejsize 0
  Apr 10 21:55:30 nntp.example.com innfeed[9364]: news-feed global seconds 25 offer
  ed 0 accepted 0 refused 0 rejected 0 missing 0 accsize 0 rejsize 0 spooled 0 uns
  pooled 0
  Apr 10 21:55:30 nntp.example.com innfeed[9364]: ME global seconds 27 offered 0 ac
  cepted 0 refused 0 rejected 0 missing 0 accsize 0 rejsize 0 spooled 0 unspooled 
  0
  Apr 10 21:55:30 nntp.example.com innfeed[9364]: ME finishing at Fri Apr 10 21:55:30 2001
  Apr 10 21:55:30 nntp.example.com innd: SERVER perl filtering disabled
  Apr 10 21:55:31 nntp.example.com innd: SERVER shutdown received signal 15

In this case, it's a regular shutdown of innd.  Obviously, that's not
exactly your case, but there may be other relevant hints.


Or it may not be quite so obvoius, and you might have to do a process
trace (or start innd with gdb and trace the program execution):

  truss -p 29491

(that would be "strace -p 29491" under Linux)

  read(29, " P a t h :   n e w s - f".., 4095)    = 1708
  brk(0x00D19800)                                 = 0
  brk(0x00D1A000)                                 = 0
  brk(0x00D1A000)                                 = 0
  brk(0x00D1A800)                                 = 0
  brk(0x00D1A800)                                 = 0
  brk(0x00D1B000)                                 = 0
  getcontext(0xFFBEEBD0)
  llseek(6, 0, SEEK_CUR)                          = 0x240982E5
  fstat64(6, 0xFFBEE060)                          = 0
  ioctl(6, TCGETA, 0xFFBEDFEC)                    Err#25 ENOTTY
  write(6, " [ 1 5 5 6 3 2 C 7 6 C 4".., 57)      Err#27 EFBIG
      Received signal #31, SIGXFSZ [default]
          *** process killed ***

SIGXFSZ under Solaris means that the file that was attempted written
was too big for the current user's limits (the EFBIG error is, not
unsurprisingly, related to that).

If this is your problem also, check the output of the ulimit command,
and adjust as necessary (that was the solution to the example case).
If not, the output from strace (around the time the source is lost) is
of interest for finding out what happened.

-- 
In the beginning was the Bit, and the Bit was Zero.  Then Someone
said, Let there be One, and there was One.  And Someone blessed them,
and Someone said unto them, Be fruitful, and multiply, and replenish
the Word and subdue it: and have dominion over every thing that is.