standalone-nnrpd "dies" when hitting ressource limits

Russ Allbery rra at
Wed Jul 12 05:43:38 UTC 2000

Moved to inn-workers.  (FYI for folks, inn-patches and inn-bugs are odd
mailing lists in that they allow submissions by non-members and therefore
all messages go through the admin staff at ISC to be manually approved to
prevent spam.  Accordingly, if you're already on inn-workers, it's often
best to just hold discussions there where messages can be automatically

Heiko Schlichting <heiko at> writes:
> Sven Paulus wrote:

>> the standalone nnrpd parent process dies if there are temporary
>> problems when it is trying to fork(). [...]

> I think this is what MAX_FORKS is used for. If you don't want this
> behavior you can increase MAX_FORKS. But in most cases it is a better
> solution to terminate the standalone nnrpd than crashing other processes
> on the system like inn or innfeed.

> Your patch would make MAX_FORKS useless and increases the risk for a
> harmful standalone nnrpd. You can just raise MAX_FORKS to a high value
> and should have the same effect if you really want this.

I'm not sure I agree.  At first glance, I like Sven's patch and think it
improves the situation.

Currently, nnrpd when in daemon mode accepts the connection and then
attempts to fork off an nnrpd to deal with it.  It tries MAX_FORKS times,
and if fork continues to fail, the main nnrpd daemon exits and no more
reader connections are allowed.

Sven's patch would change this so that it tries MAX_FORKS times and if it
still can't fork off a child, the connection is immediately dropped and
nnrpd goes back into the loop waiting for another connection.

The latter behavior strikes me as obviously more robust; if the forking is
a temporary problem, nnrpd doesn't kill itself off and can recover once
the system is healthier.  With the current behavior, nnrpd is toast and
has to be manually restarted when the system is fixed.  MAX_FORKS still
does have an effect; the connection is dropped after that many attempts
and it takes another incoming connection to get it to try again.

The current behavior doesn't seem to have any upsides.  I don't think that
nnrpd killing itself is likely to help innd; innd, particularly when using
controlchan, rarely forks off new processes.  Channel feeds are
long-running.  And if the reason for the process table overload is
something other than nnrpds, one more nnrpd killing itself is unlikely to
be of much assistance.


Russ Allbery (rra at             <>

More information about the inn-workers mailing list