Location of SetupDaemon in nnrpd.c

Alex Kiernan alexk at demon.net
Thu Jun 13 10:28:57 UTC 2002

Heiko Schlichting <inn-workers at CIS.FU-Berlin.DE> writes:

> > Anyone remember the detail of this change to nnrpd.c:
> Sure.

Excellent, thanks.

> Putting it back to the old place will break nnrpd. It could (and will)
> happen that you request an article and do not get an answer. You can retry
> and it succeeds. That is not acceptable in production.
> If the master opens the buffers you have only one set of filehandles. The
> forked childs will use a sequence of seek() and read() to get the article.
> If you have one child, this will always succeed. But the problem occurs if
> there are more than one child: child-1 does a seek() but before the read of
> child-1 occurs, child-2 does it's own seek. Then child-2 can successfully
> read the article but child-1 cannot. In reality the situation is more
> complex because nnrpd seeks and reads the CNFS article heading and article
> in two seperate actions. Therefore child-1 can get an article heading if an
> article content is expected.
> In practice, the seek and read are very close and you might never notice
> problems with only a few nnrpd childs (although things can go wrong too).
> We noticed significant failures on our main production server when there
> are many nnrpd childs (today there up to 2000 nnrpd childs). With so many
> nnrpd childs a huge amounts of article requests will fail.

Ah, but we now use pread() everywhere in cnfs (writes don't, they use
seek/writev, but thats not a problem), so I think at least from the
cnfs perspective we could move it back (assuming we're not on a
platform which uses the pread() emulation in lib/pread.c).

That said everything else which is initialised in SetupDaemon would
need checking (history, overview etc.), plus the other storage
mechanisms (timecaf looks like it would be the only one which broke
from a quick inspection).

Maybe the right approach is to split initialisation for all of these
subsystems into two parts, one of which is daemon safe, the other not.

> Therefore: Don't open the CNFS buffers in the daemon, never!
> Below the signature you find my report of the year 2000.

Thanks - kept for future reference!

Alex Kiernan, Principal Engineer, Development, THUS plc

More information about the inn-workers mailing list