Skip site navigation (1)Skip section navigation (2)
Date:      Mon, 24 Apr 2000 14:32:15 +0000 (GMT)
From:      Andrew <andrew@soc.lg.gov.ua>
To:        Ryan Thompson <ryan@sasknow.com>
Cc:        Kaan XRS <kaanors@superonline.com>, freebsd-questions@FreeBSD.ORG
Subject:   Re: server
Message-ID:  <Pine.BSF.3.96.1000424142811.293B-100000@soc.lg.gov.ua>
In-Reply-To: <Pine.BSF.4.21.0004230247140.55888-100000@ren.sasknow.com>

next in thread | previous in thread | raw e-mail | index | archive | help
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 <ryan@sasknow.com>
>   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




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.3.96.1000424142811.293B-100000>