Date: Sun, 23 Apr 2000 03:01:04 -0600 (CST) From: Ryan Thompson <ryan@sasknow.com> To: Kaan XRS <kaanors@superonline.com> Cc: freebsd-questions@freebsd.org Subject: Re: server Message-ID: <Pine.BSF.4.21.0004230247140.55888-100000@ren.sasknow.com> In-Reply-To: <3902B909.1595FC7F@superonline.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.4.21.0004230247140.55888-100000>