l i n u x - u s e r s - g r o u p - o f - d a v i s
Next Meeting:
July 7: Social gathering
Next Installfest:
Latest News:
Jun. 14: June LUGOD meeting cancelled
Page last updated:
2002 Apr 22 10:21

The following is an archive of a post made to our 'vox-tech mailing list' by one of its subscribers.

Report this post as spam:

(Enter your email address)
Re: [vox-tech] RH keeps crashing
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [vox-tech] RH keeps crashing

On Mon, 22 Apr 2002, Richard S. Crawford wrote:
> I know it's not much to go on, but when it comes to this area, that's about 
> the limit of my expertise.  In all honesty, I'm not even entirely sure 
> which system logs to check, or how to check them.

Isolating the problems and establishing what is the likly cadidate for
blame should help to point you to a log file.
Generally speaking, few services should bring a system to a halt:
the kernel (kind of like a service for hardware to the user's
 applications) (check /var/log/kern* and dmesg |less )
modules loaded into the kernel (should really be considered part of
 kernel up above) (check /var/log/kern*  and dmesg |less )
X - a seriously big piece of software. If you enable certain direct access
 options or GLX/GL options etc, there is risk for X to crash a system.
 Where the log file is for this may differ from one distro to another.
 A common spot is /var/log/XFree86* but may not be "there". You cans
  also try looking for /var/log/xdm* /var/log/gdm* or /var/log/kd* if
  you think it might be X related.

Beyoind the above, any daemonized or inetd service can also kill a system
by exhausting memory (actually nearly any program can do this). When this
kind of "bug" hits a system, it often does not freez - it just becomes
slower and more difficult to deal with over time (sometimes seconds or
minutes or hours - it depends upon how aggressive the "bug" is and how
much in the way of resources you have.  Two intentional "bugs" like these
that are very aggressive is an intentional fork-bomb or memory-grabber,
but these are intentional attacks run on a system and in most cases lead
up to the final freez by noting the system's performance getting worse,
and a review of "uptime" or top show the system load is much higher than

> I'm just hoping it isn't hardware... I'm not all that keen on replacing my 
> hard drive. ;-)

This kind of problem is usually not hard drive. With hardware problems,
you might see things more like IRQ/IO conflicts, overheating,
overclocking, not fully supported hardware and experimental drivers in
Linux, etc.


Version: 3.12
GCS/CM$/IT$/LS$/S/O$ !d--(++) !s !a+++(-----) C++$(++++) U++++$(+$) P+$>+++ 
L+++$(++) E W+++$(+) N+ o K w+$>++>+++ O-@ M+$ V-$>- !PS !PE Y+ !PGP
t@-(++) 5+@ X@ R- tv- b++ DI+++ D+ G--@ e+>++>++++ h(++)>+ r*>? z?
decode: http://www.ebb.org/ungeek/ about: http://www.geekcode.com/geek.html

vox-tech mailing list

LUGOD Group on LinkedIn
Sign up for LUGOD event announcements
Your email address:
LUGOD Group on Facebook
'Like' LUGOD on Facebook:

Hosting provided by:
Sunset Systems
Sunset Systems offers preconfigured Linux systems, remote system administration and custom software development.

LUGOD: Linux Users' Group of Davis
PO Box 2082, Davis, CA 95617
Contact Us

LUGOD is a 501(c)7 non-profit organization
based in Davis, California
and serving the Sacramento area.
"Linux" is a trademark of Linus Torvalds.

Sponsored in part by:
O'Reilly and Associates
For numerous book donations.