nntpcached dies

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



We use nntpcache_2.3.2.1_freebsd.tar

After 1 -3 days the nntpcached dies. In /var/log/messages is the following
message:
Oct  2 10:52:34 proxy /kernel: pid 19453 (nntpcached), uid 8: exited on
signal 10


FreeBSD 2.2.2-RELEASE
CPU: Pentium (132.95-MHz 586-class CPU)
  Origin = "GenuineIntel"  Id = 0x52c  Stepping=12
  Features=0x3bf<FPU,VME,DE,PSE,TSC,MSR,MCE,CX8,APIC>
real memory  = 67108864 (65536K bytes)
Physical memory hole(s):
avail memory = 62459904 (60996K bytes)
Probing for devices on PCI bus 0:
chip0 <Intel 82439> rev 3 on pci0:0
chip1 <Intel 82371SB PCI-ISA bridge> rev 1 on pci0:7:0
chip2 <Intel 82371SB IDE interface> rev 0 on pci0:7:1
pci0:7:2: Intel Corporation, device=0x7020, class=0x0c, subclass=0x03 int d
irq 15 [no driver assigned]
vga0 <VGA-compatible display device> rev 84 int a irq 15 on pci0:17
vx0 <3COM 3C905 Fast Etherlink XL PCI> rev 0 int a irq 10 on pci0:18
mii[*mii*]: disable 'auto select' with DOS util! address 00:60:08:29:df:81
ahc0 <Adaptec 2940 SCSI host adapter> rev 0 int a irq 11 on pci0:19
ahc0: aic7870 Single Channel, SCSI Id=7, 16 SCBs
ahc0 waiting for scsi devices to settle
(ahc0:0:0): "SEAGATE ST31200N 8648" type 0 fixed SCSI 2
sd0(ahc0:0:0): Direct-Access 1006MB (2061108 512 byte sectors)
(ahc0:1:0): "IBM DCAS-32160 S65A" type 0 fixed SCSI 2
sd1(ahc0:1:0): Direct-Access 2063MB (4226725 512 byte sectors)
(ahc0:2:0): "IBM DCAS-32160 S65A" type 0 fixed SCSI 2
sd2(ahc0:2:0): Direct-Access 2063MB (4226725 512 byte sectors)
(ahc0:5:0): "SONY SDT-5000 3.30" type 1 removable SCSI 2
st0(ahc0:5:0): Sequential-Access density code 0x13,  drive empty
Probing for devices on the ISA bus:
sc0 at 0x60-0x6f irq 1 on motherboard
sc0: VGA color <16 virtual consoles, flags=0x0>
ed0 not found at 0x280
sio0 at 0x3f8-0x3ff irq 4 on isa
sio0: type 16550A
sio1 at 0x2f8-0x2ff irq 3 on isa
sio1: type 16550A
lpt0 at 0x378-0x37f irq 7 on isa
lpt0: Interrupt-driven port
lp0: TCP/IP capable interface
psm0: disabled, not probed.
fdc0 at 0x3f0-0x3f7 irq 6 drq 2 on isa.

my nntpcache.config:
# $Id: nnconf.cf.in,v 1.1.1.1 1998/01/03 20:20:39 proff Exp $

# Note: you can't set compile-time defaults for stringl (not string)
# types. The specified stringl defaults will be automatically migrated
# over to the run-time configuration file however, so this shouldn't
# pose any problems.

# location of configuration directory, the config files below
# are relative to this path. kinda important
configDir /nntpcache/etc

# location of configuration file (hey, thats me, here)
configFile nntpcache.config

# server configuration file
serversFile nntpcache.servers

# access control configuration file
accessFile nntpcache.access

# the root directory for nntpcached all cache files are created under.
# if the chroot option is on, this this path is relative to chrootDir
# (but still needs a leading slash)
cacheDir /nntpcache/spool

# who should receive email complaints / reports?
adminEmail usenet@marmeladinger.adv.magwien.gv.at

# file/directory creation umask
umask 022

# for high security, it is possible to run nntpcache in a minimal chrooted
# environment. the only files/directories nntpcached should need in the
# chroot hierarchy are cacheDir and those associated with the resolving
# of hostnames (typically /etc/host.conf, /etc/resolve.conf and /etc/hosts)
# and syslog (/dev/log) (you will also need to run a syslogd on the
# chrooted /dev/log (e.g syslogd -p /usr/local/nntpcache_root/dev/log))
#
# on systems (such as solaris) which wrap connect() and other tcp functions
# in library calls which open /dev/tcp* you may also need to mknod (or
# tar copy) the required devices.
#
# note that the configuration files do not need to be, and should not be,
# in the chroot hierarchy
#
# nb. nntpcached must be invoked as root for chroot() to succeed
chrootDir /usr/local/nntpcache_root
chroot off

# change the format below to your most frequently used cached server.
# nntpcached is smart and doesn't translate xover information if the
# remote server is using the same overview scheme as nntpcached
# (xover format translation is a relatively expensive operation). You can
dump
# the xover format, by telneting to the nntp.server, port 119 and typing
#
#       list overview.fmt
#
# note that if you change the format, you will need to purge the xover
# cache. the following command will do just that:
#
#    find /nntpcache/spool -type f -name \*_xover -print | xargs rm
#
# order IS important. The below is the default for INN1.4+ servers.
overviewFmtInternal Subject: From: Date: Message-ID: References: Bytes:
Lines: Xref:full

# the following is used for a few brain-dead servers that xover but refuse
# to provide an overview.fmt. You really need to get this right if you
# expect to talk to such a delinquent bozo server.
#overviewFmtBozo Subject: From: Date: Message-ID: References: Bytes: Lines:

# IHAVE servers. If an IHAVE command is issued, then it will be passed
# onto the servers specified here. This is for situations where nntpcache
# is acting as an intermediary between two news-servers attempting to
# feed each other news. (watch out for recursion). Note that you
# shouldn't need to specify multiple servers here unless they are
# are unconnected insofar as usenet network topology is concerned.
#ihaveServers localhost:120

# speedup IHAVE handshakes. If you have multiple IHAVE servers, then
# this will cause a NNTP_TOOKIT message to be returned to the IHAVE client
# as soon as the first NNTP_TOOK message comes in from anyone of the
# IHAVE servers listed above, rather than waiting until all servers
# have accepted or rejected the article.
#ihaveSpeedHandshake on

# Maximum number of servers to consult for <msgid> cache-misses. When
# an article (etc) is required by <msgid> that is not in the cache,
# nntpcache has no information on which servers have it. It deals with
# this by first asking the current server (i.e the last server that
# found a <msgid> style request, or is serving the current group), then
# checking all the other servers in the order they are mentioned in
# the nntpcache.servers configuration file. There are two issues here.
#
#      1) Recursive servers. If both servers are nntpcache servers,
#         and each has the other listed as one of its servers, then
#         if there is a cache miss on a <msgid> style article request,
#         and the current server didn't have the article (perhaps
#         simply because the article expired), then first server
#         will ask the second server for the <msgid> which may
#         forward the request to the first server and so on. We
#         can't just filter out requests going back to the host that
#         the client came in on, as some of these maybe quite
#         legitimate, although we could perhaps create a failed
#         message id request cache, so when the second forward
#         comes back, the request can be denied without consulting
#         other servers that potentially have it. this sort of
#         solution does however have race conditions, in the unlikely
#         event that two clients request the same message id at the
#         same time.
#
#      2) Many servers scenario. Fortunately this case isn't nearly
#         as pathological as the above. When there are many servers
#         listed in nntpcache.servers it can take quite some time
#         to progress though them all, only to find that the <msgid>
#         in question has expired. This can lead to user hair-pulling.
#         The other issue here, is that if your reader population is high
#         and you are pulling in groups from external servers (i.e that
#         don't belong to you directly), the news admins who run them
#         may become annoyed with the constant requests for expired
#         <msgid>'s.
#
# the default of 2 (below) will search the current server and one
# other (the first server, or the second server if the first server is
# the current server).

maxMsgIDsearch 2

# maximum number of concurrent readers
# this must be smaller than MAX_CHILDREN in cf/nconf.h
maxReaders 200

# permissible characters in a group name. Anything not matching is simply
# stripped out. You may want to modify this if your news feed uses kanji
# or iso high bit characters et al in regional group names.
# nb. two of the microsoft.* groups from msnews.microsoft.com have
# ampersands ('&') in them. I know I'm wearing black.
safeGroup
.abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ1234567890_-+=':

# group security. if activated, nntpcache performs group level security
# checks on all messages and group oriented commands, not just connection
# security checks. group-level POST checks are always on, regardless
# (because POSTs are so rare as to not be a performance issue).
groupSecurity on

# list security. if activated, nntpcache performs group level security
# checks on every group involved in a group listing (i.e a LIST of
# active, active.times, newsgroups or a NEWGROUPS). This will remove
# all groups from the listing which the client does not have read
# access to. If you do not mind users seeing groups that exist and
# which they can not access, then leave this option off. The checking
# is an intensive operation, because every group in the list
# (and that's normally ALL groups for a LIST active or LIST newsgroups
# i.e around 15,000 groups as of this writing) have to be matched
# against the group security entries in the access file.
# If you want to strip out particular groups for all clients, then
# use the strip access control, as it comes into effect during
# nntpcache group collation (rare) rather than during group listings
# (frequent)
listSecurity on

# some servers return newsgroups in 'newsgroups' and 'active.times'
# that have no corresponding entry in 'active'. Do we permit this?
# note that the ListActiveThreshold won't have any effect unless
# listPermitLonelyness is false
listPermitLonelyness no

# some servers state they carry a group, but on closer inspection
# the group appears to be permanently barren. On the other hand,
# the server may carry the group, but the group never sees any
# articles (other than spam). What is the minimum article high
# count before we will believe that a group is active?
listActiveThreshold 0

# filter articles by scanning article and/or header content
# according to the filters specified in the access file.
# our content filtering routines are as greased as
# a lawyer-turned bail bondsman on Prince William Sound beech
# demonstrating Reef Tan, but you may find yourself getting
# wet if a lot of traffic comes in. You need to have groupSecurity
# on for this to have proper effect.
contentFilters on

# as above, but for XOVER and XHDR commands. You can only
# filter these commands based on header patterns, not article
# content. filtering is transparent as XOVERs and XHDRs
# are used to build the list of messages in a group.
xoverFilters on

# NoCem - auto-spam killer
# see http://www.nocem.org for more information about nocem
nocem off

# initial scan - what is the maximum number of articles
# we will read in one session?
#nocemInitialScan 8192

# what is the minimum time period between scans for new
# nocem articles?
#nocemInterval 20m

# groups to monitor for nocem messages
#nocemGroups news.lists.filters

# Process NoCem messages from (regex)
# The default (.) is everyone. However provided PGP
# authentication of NoCem messages is enabled (see
# further below) only the NoCem messages we have public
# keys for will be accepted
#nocemFrom .

# nocem type regex
#nocemType spam|spew|MMF

# nocem action regex
#nocemAction hide

# require PGP signed nocem messages this is turned off if nntpcache's
# configure script couldn't find PGP on the file-system. If turned off
# net kooks(tm) can forge nocem advisories. No worse than news-server
# that accepts cancel control messages, but ideally you should have
# signature verification turned on.

#nocemPGP yes

# start of PGP signed nocem message. we only
# handle clear signed messages. for performance reasons
# we don't use the PGP generated data, except for messages
# sent to stderr, which we use to check for signature validity
# All nocem messages are currently clear-signed,
# but we may need to review this policy if (say) PGP compressed
# nocem messages are seen on the wire.
#nocemPGPbegin  -----BEGIN PGP SIGNED MESSAGE-----

# end of PGP signed nocem message. necessary to prevent
# out of window attacks (pgp in stream mode will normaly
# process all messages in the stream, not just the first)
#nocemPGPend  -----END PGP SIGNATURE-----

# command used for PGP signature verification - returns with exit
# status zero if the signature is valid. %s expands to a temp file in
# which nntpcache expects the stderr messages from pgp.  if chroot is
# on, then you will need /bin/sh and a statically linked version of
# PGP (or ld.so/rtld and the relevant libraries) within the chrooted
# region - and the path below will be relative to it. These flags have
# only been tested with PGP2.6
#nocemPGPcommand pgp -f +batchmode >/dev/null 2>%s

# nocemPGPgood
#nocemPGPgood ^Good signature

# PGPPATH
# By default pubring.pgp is stored in /nntpcache/etc. If
# chroot is on, you will need to copy pubring.pgp into /nntpcache/spool
# and change this path to be relative to /nntpcache/spool (or whatever
# you have set cacheDir to be)
#nocemPGPPATH /nntpcache/etc

# relay unknown commands to the most recently used news-server.
# may bypass group (and other) security features, depending on
# what commands the remote news-server supports.
relayUnknowns no

# nntpcached sets it's uid to that of the username specified below
# before it listens for connections. you *can* run nntpcache even
# though you do not have root access, by setting the user and
# group variables to those your own and bindAddr (see
# below) to a high port (i.e >1024)
user news

# what group to run as
group news

# organization (Yankee spelling)
# used when the reader posting doesn't specify one, or
# when replaceOrganization is on
Organization proxy.dienste.wien.at - News-Server

# force replacement of already present Organization header in posts.
# (Suuuure you're from the Julian Assange Memorial Society)
replaceOrganization no

# strip post header regex
# remove headers matching the following regex
postStripHeader ^X-foo:

# expire if there are under this number of blocks in the cache partition
minBlocksFree 10000

# address:port to listen for connections on (can be changed with
# -b at run time). nb. DEFAULT:119 = all interfaces, port 119.
# if you do not have root, you will need to make the port a
# number greater than PORT_RESERVED (usually 1024) e.g
# bindAddr DEFAULT:2119.` You will also need to change the
# NNTPSERVER and/or NNTPPORT environmental variables (or
# whatever configuration your news reader uses for such
# things) accordingly
bindAddr DEFAULT:119

# max mmap data size. a 15,000 group newsfeed takes around 4Mb for our
# internal cache structures. we set the data space here to 16Mb
# as there is almost no overhead for the unused portion.
# if this figure runs out, BAD juju will happen.
maxMmap 16M

# if set, we don't use a memory mapped file for our cache structures,
# but rather store the lot in an anonymous memory region. this means
# modifications by nntpcached to the mmaped region are not saved
# between restarts of nntpcached. On the other hand, such information
# tends to expire relatively quickly. anonymous regions have superior
# performance characteristics (i.e it's all in memory) -- depending on
# how effectively your OS cache's mmaped disk blocks.  this value has
# no effect one way or the other if mmap_tests determined that shared,
# inherited, anonymous memory maps or file maps were non-existent or
# buggy -- nntpcached will just choose whatever works :)
anonMmap yes

# run expire if there are under this number of inodes in the cache partition
minFilesFree 2000

# don't let the history file grow larger than this (bytes)
hisHighWater 60M

# when it does, trim it back to this (bytes)
hisLowWater 40M

# as above, but for the newsgroups list. usually
# not as important, as it is fetched with less
# frequency
secondaryNewsgroupsCache false

# When we do an expire, kill articles older than this
maxArtAge 1w

# check disk space, etc for automatic expiry this often
# (but only after a client connects or disconnects)
expireCheckPeriod 5m

# how often do we update overview.fmt's?
# the master nntpcache will pause incoming connections
# during this (brief) process. this data should never
# change, so the refetch is set to be quite infrequent
overviewFmtTimeout 7d

# perform identd lookups
rfc931          no

# hide the name of the current roup from ps(1)
taskInfoPrivacy no

# nnrpd compatible log messages (i.e innreport fodder)
logInn          yes

# log network input/output
logFromClient   yes
logToClient     yes
logFromServer   yes
logToServer     yes

# log {active,newsgroups,active.times} merger messages. these can be
# quite voluminous if you have a lot of group deny rules.
# also log ignored groups due to group <-> server pattern correlations
# both of these are logged at syslog level LOG_DEBUG
logListMerge    yes
logListMergeCorrelation yes

# verbose nocem logging
logNocem                no

# you probably do not want to turn any of these syslog messages
# off execpt for logDebug, and maybe logInfo on very high-volume
# installations
logDebug                yes
logInfo         yes
logWarnings     yes
logErrors               yes

# collect statistics. involves scanning some strings for length, if you
# are paranoid about performance, turn it off.
# note that some statistics will still be collected (i.e in many cases
# it is actually faster to collect the statistics than decide whether
# statistics are collected or not), but the values will not be wholly
# accurate.

statistics              yes

# a magic article id is used to serve up a magic article containing
# nntpcache statistics. if you don't want users reading your cache
# statistics then set this to something obscure

statsArticleID  stats@nntpcache

httpServer yes

# address to bind the nntpcache web-server to

httpBindAddr DEFAULT:9119

# If chroot is in effect, this needs to be relative to /nntpcache/spool
httpFiles /nntpcache/etc/http

# don't refresh list cache unless at least this amount of time has passed
# since the last check, despite lower timeout values given anywhere
# else
minUpdateDelay 10m

# some news servers (particularly those running on microsloth boxes)
# don't support all the list types that nntpcache does. Most often
# attempts by nntpcache to view unavailable lists generate a 501
# syntax error. However it is possible that there was some other cause
# of the error. It's also possible that the news server may be
# upgraded in the future and the list will become available.  How long
# do we flag a server/list combination as unavailable when we
# receive an error in response to a list request?
minUpdateRefusedDelay 1m

# if we are refreshing the list cache for a particular list/server
# combination and the attempt is unsuccessful (excluding the above),
# what is the minimum delay before the next check?
minUpdateFailDelay 10m

# period after which a network connection is considered dead
networkTimeout 5m

# exit if client is idle for longer than this period
idleTimeout 25m

# shutdown the remote connection if it idle for longer than this period.
# nntpcache will open a connection to the remote server for each
# cache miss. for very high volume sites, this means the remote
# server can start to build up a lot of rarely active NNTP sockets
remoteIdleTimeout 10m

# If a server has gone down, don't try and reconnect until this
# time period has elapsed (we run out of cache till then).
serverDownRecheck 1m

# output buffer size (to client newsreader)
# large buffers gain efficiency, but increase the
# time it takes for a client to see the first part of a
# long XOVER or ARTICLE. We use the size below for
# the internal stdio-buffer and the socket layer buffer
outputBufferSize 8k

# in each nntpcache sub-process, file descriptor's
# and the index into each xover file are cached during
# xover/xhdr scans, at one per 512 articles.
# this variable sets how many of these we can cache.
# do not set to less than two or bad juju will find
# its way into your life
maxXoverNodes 20

# you probably do not need to change anything here on in

statsFile nntpcache.stats

# history database file name
historyFile cache.history

# file in which to store the nntpcached master server process id. PID_FILE
# has the addr:port number appended, incase multiple nntpcached's are
running
pidFile nntpcache.pid

# overview.fmt file, no point in changing this
overviewFmtFile overview.fmt

# shared mmap file, no need to change this.
# if USE_MMAP_ANON is defined then the following isn't used
mmapFile cache.mmap

# shared mmap base pointer file, no need to change this.
# if USE_MMAP_ANON is defined then the following isn't used

mmapBaseFile cache.base




Wolf


[Index of Archives]     [Yosemite]     [Yosemite Campsites]     [Bugtraq]     [Linux]     [Trn]

Powered by Linux