On Fri, Aug 29, 2003 at 02:36:01PM +0200, Sten Daniel Sørsdal wrote:
> 
> Many of my servers tend to have their syslogd die on them.
> In dmesg i could see the signal number on one of them; 11
> But kill -l doesnt reveal which that is:
> 
> pid 17263 (syslogd), uid 0: exited on signal 11
> pid 87264 (syslogd), uid 0: exited on signal 11

See /usr/include/sys/signal.h --- signal 11 is SIGSEGV, segmentation
violation.  Most of the time that it's mentioned on this list it's due
to memory hardware errors causing crashes.  However, in this case as
the problem is localized to syslogd then I think you've found a bug.

> /var/log has lots of space, newsyslog does it's job regularly.
> The versions vary from 4.7 to 4.9-prerelease. Lots of memory available.
> Hardware ranges from 1ghz celerons, 400mhz p3's, 1.6ghz p4's.
> 
> The command lines are either; -nccvvs -ccvvs (but mostly) -vvs
> 
> They log to remote host that is currently unavailable. 
> (router emites destination host unreachable).
> The reason i mention this is that many types of software misbehave 
> when they receive this message.
> 
> 
> When i ran syslogd -dvvs in 'screen' it started logging to remote 'loghost'. 
> For a -long- time it kept repeating "Host is down" and tried to log to 'loghost' 
> 'loghost' is a local alias.
> 
> I'm finding it hard to reproduce.

Did you compile the system with a higher optimization level than the
recommended -O?  If so, then a) try recompiling using the recommend
optimization levels, which should cure your crashing problem and b)
you've found a bug in the system C compiler, which may or may not get
fixed, seeing as gcc-2.95.4 is quite a lot older that the current
3.3.x version as seen in FreeBSD 5.x.

Does this happen often enough that you can tell if it's happening on
all your machines or not?  Perhaps you are using CPUTYPE specific
optimizations -- again, try compiling without and see if the problem
goes away.

If, on the other hand, you haven't used excessive levels of
optimization, then there's something special about your environment
that has tickled a bug in syslogd.  Is this the same bug as PR
bin/51253?

This should certainly be reported through send-pr(1), and all extra
information you can supply that may lead someone to be able to
reproduce the problem would be really useful.  Have you got a core
dump from syslogd?  If so, keep hold of it, and the corresponding
syslogd binary from /usr/obj (which should not have hat debug symbols
stripped out) as anyone working on this is likely to ask you for a
backtrace.

        Cheers,

        Matthew

-- 
Dr Matthew J Seaman MA, D.Phil.                       26 The Paddocks
                                                      Savill Way
PGP: http://www.infracaninophile.co.uk/pgpkey         Marlow
Tel: +44 1628 476614                                  Bucks., SL7 1TH UK

Attachment: pgp00000.pgp
Description: PGP signature

Reply via email to