nnrpd given the same PID as innfeed

[Richard Kettlewell]

Julien ÉLIE <julien at trigofacile.com> writes:
> Has someone ever seen "exit 1" lines for innfeed in your news.notice files?
>
> Jun 15 17:37:14 news innd: innfeed! exit 1 elapsed 48133 pid 4474
>
>
>
> I have recently seen it a few times.  The problem is that during a fork,
> nnrpd is given the PID of innfeed if I trust the logs:
>
> Jun 15 17:37:14 news nnrpd[4474]: cpe-67-242-187-207.rochester.res.rr.com (67.242.187.207) connect - port 119
> Jun 15 17:37:14 news nnrpd[4474]: cpe-67-242-187-207.rochester.res.rr.com rejected by rule (Closed service.)
> Jun 15 17:37:14 news nnrpd[4474]: cpe-67-242-187-207.rochester.res.rr.com times user 0.032 system 0.016 idle 0.000 elapsed 0.036
> Jun 15 17:37:14 news nnrpd[4474]: cpe-67-242-187-207.rochester.res.rr.com time 36 nntpwrite 0(1) 
> Jun 15 17:37:14 news innd: innfeed! exit 1 elapsed 48133 pid 4474
>
>
> I don't know why it happens.  But the fact is it happens...
>
> That issue always appears (at least on my system) when a user tries to
> connect very very often.
> I blacklist such users in my readers.conf file, whence the "rejected
> by rule (Closed service.)".

I have two guesses.

1. It seems PROCscan() runs only intermittently, so there's a window of
opportunity between innfeed actually terminating and the log entry for
an nnrpd to start up.  It may by chance happen to get the PID that
innfeed used to have.  Perhaps that explains the weird PID behavior.

In this case, any log message from innfeed explaining its termination
might be above the nnrpd lines.

2. When a child (say, nnrpd) terminates, innd gets SIGCHLD and
immediately invokes PROCreap().  This looks for the process in
PROCtable.  However, if another child process has just been started then
PROCwatch() will be part way through executing realloc() to expand
PROCtable at the point the signal arrives.  So PROCreap() may see an old
and possibly corrupted version of the table.  This too might explain the
weird PID behavior.


The issue described in 2 needs to be fixed.  My usual approach in this
situation is to block signals except when waiting in select().  (The
signal mask must also be restored inside forks if this approach is
used.)  I'll submit a patch at some point, subject of course to any
discussion here.

ttfn/rjk