Linux – Can a high load cause a system to reboot

linux

Assuming the system is a red hat variant, x86 architecture. Assume no cooling issues.

Is it possible for a very high load on the machine to cause it to reboot?

I understand that a machine make become unresponsive, certainly. But can it actually reboot?

If so, how does this occur?

Best Answer

Not enough detail here...

But maybe, maybe not... This depends on the nature of the load and what's producing it. A high load on its own will not cause a system to reboot, but may be indicative of some other major issue that could cause an unplanned shutdown. E.g. a high-transaction mailserver or database server running a load of 80 is far different than a system whose RAID controller locks-up.

The easiest example could be storage. An instant rise in load following the loss of storage connectivity or a RAID controller malfunction could easily push the system load to 100+ on a busy system. The system may remain pingable and usable to some extent, but I/O operations could fail. Certain commands may stop working even though the TCP/IP stack is in memory and available.

So it's possible to kernel panic in this condition, or for the system or applications to stall. On quality hardware, there may be a watchdog timer that warm-boots the server. HP and the Automatic Server Recovery (ASR) feature or VMware's HA virtual machine monitoring could take this action.

Related Solutions

Linux Bash – How to Sort du -h Output by Size

As of GNU coreutils 7.5 released in August 2009, sort allows a -h parameter, which allows numeric suffixes of the kind produced by du -h:

du -hs * | sort -h

If you are using a sort that does not support -h, you can install GNU Coreutils. E.g. on an older Mac OS X:

brew install coreutils
du -hs * | gsort -h

From sort manual:

-h, --human-numeric-sort compare human readable numbers (e.g., 2K 1G)

Linux – Inode too big. Linux Filesystem

Check is your version of e2fsprogs (e.g. e2fsck -V). There was apparently a bug prior to version 1.40.2 that could cause e2fsck (which is called by fsck for EXT2/EXT3 filesystems) to incorrectly report filesystem corruption of this type:

Fix a bug in e2fsck which caused it to incorrectly salvange directories when the last entry's rec_len is bogusly too big. This resulted in a nonsense filesystem corruption to be reported, and required a second run of e2fsck to fully fix up the directory.

The RHEL 4 servers that I have access to have version 1.35 on them, so this could be the real cause of your problem. It might be worth installing a newer version and running fsck again to be sure.

If that doesn't help, it may indeed be a filesystem problem. According to this thread, it appears that this can happen if you have a directory containing a very large number of files (millions or more). "Fixing" it with fsck will result in the inode being truncated, as you saw. In the case of a directory inode, truncation will cause the directory to "lose" files, and those orphaned files will end up in the filesystem's lost+found directory. They will be named after their inode number, not their original names, so although you'll still have the files, it may be difficult to tell them apart.

Best Answer

Related Solutions

Linux Bash – How to Sort du -h Output by Size

Linux – Inode too big. Linux Filesystem

Related Topic