From owner-freebsd-questions Mon Apr 24 6:18:45 2000 Delivered-To: freebsd-questions@freebsd.org Received: from lumsi.lugansk.ua (lumsi.lugansk.ua [62.244.34.14]) by hub.freebsd.org (Postfix) with ESMTP id 108BF37BB02 for ; Mon, 24 Apr 2000 06:18:25 -0700 (PDT) (envelope-from andrew@soc.lg.gov.ua) Received: (from uusoc@localhost) by lumsi.lugansk.ua (8.8.8/8.8.8) with UUCP id QAA00409; Mon, 24 Apr 2000 16:03:38 +0300 X-Authentication-Warning: lumsi.lugansk.ua: uusoc set sender to andrew@soc.lg.gov.ua using -f Received: from localhost (andrew@localhost) by soc.lg.gov.ua (8.9.3/8.9.3) with ESMTP id OAA02234; Mon, 24 Apr 2000 14:32:15 GMT (envelope-from andrew@soc.lg.gov.ua) Date: Mon, 24 Apr 2000 14:32:15 +0000 (GMT) From: Andrew To: Ryan Thompson Cc: Kaan XRS , freebsd-questions@FreeBSD.ORG Subject: Re: server In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=KOI8-R Content-Transfer-Encoding: 8BIT Sender: owner-freebsd-questions@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Try recompile your kernel with options "MAXMEM=(128*1024)" options NO_MEMORY_HOLE On Sun, 23 Apr 2000, Ryan Thompson wrote: > Please CC freebsd-questions@freebsd.org when replying > > Kaan XRS wrote to Ryan Thompson: > > > Everything is OK in kernel. Hardware: 233MMX 128MB Ram 6.4 gb Hdd. It > > doesn`t give any error in /var/log/messages while rebooting. 20 ircd > > servers and their services are running on this servers. I haven`t > > updated to 4.0 yet but have you received an error like this before? > > > > Kaan ÖRS > > When you say "error like this", you must realize that there are many > reasons why a kernel will panic and auto-reboot the system... So, YES, I > have witnessed machines auto-reboot (personally, only due to hardware > malfunctions, or human error, or call panic()'s while testing), but NO, I > don't know why your particular configuration is forcing reboots. > > If there are indeed no errors in /var/log/messages, and you did not see > any unusual console messages during "normal" system operation, or right > before the reboot (you should have, since the system appears to have been > shut down cleanly), then you truly need to try kernel dump debugging. Do > read the handbook section on making the most of a crash dump. > > OTOH, if you can find some shred of evidence (logs) to show us that might > suggest to someone of experience WHY your system is exhibiting this > behaviour, someone (perhaps myself) can assist you in determining how to > correct the underlying problem. Even subjective indicators can help: > > o Does this happen during times of high load? > is it disk intensive, or CPU intensive? > o If you can monitor it, how much memory is free during: > o "Normal" operation > o Right before the reboot > A good way to do this is to add a new CRON job that runs > every minute that pipes the output of vmstat to a log file. > After a reboot, examine that log file and try to look for > spikes or dips or anything unusual. > > If that isn't a fine enough measure (i.e., spikes occur > in << 60 seconds), a perl script that sleep()s for a few > seconds and pipes `vmstat` to a file might be advantageous. > o Other things to watch for are active processes, problem users, > etc. > > > > -- > Ryan Thompson > Systems Administrator, Accounts > Phone: +1 (306) 664-1161 > > SaskNow Technologies http://www.sasknow.com > #106-380 3120 8th St E Saskatoon, SK S7H 0W2 > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-questions" in the body of the message > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-questions" in the body of the message