Health Monitoring with lm_sensors
A few years ago, a friend of mine had problems with his computer. It became unreliable; he would get odd errors, or the system would hang. He re-installed the operating system and his key applications, but the problems persisted. This cost him time, and his time is valuable.
The problem turned out to be simple: the cooling fan on his CPU's heat sink was dead. The overheating CPU, in turn, caused random problems. He wound up replacing the CPU as well as the heat sink, because the CPU had been damaged.
He could have avoided all of this if he had been running some sort of computer health monitoring system, such as lm_sensors.
lm_sensors is a set of Linux kernel modules for monitoring the vital signs of a computer: the voltages from the power supply, the temperature of the system and the CPU and fan speeds. lm_sensors includes a command-line utility for checking the current readings. A variety of graphical tools also are available for putting a pretty face on lm_sensors.
Before you attempt to install the lm_sensors kernel module, you should have the I2C driver modules installed. I2C, which stands for Inter-IC bus, is a simple serial data system for connecting chips so they can talk to one another. Most motherboards with health monitoring features use an I2C bus to access those features.
Make sure the I2C drivers are installed on your system. (If you build your own kernel, the I2C options are located under Character Devices.)
Install the packages that provide lm_sensors, or build it from source code and install. Then enter sensors-detect, a script that figures out how to install lm_sensors on your system. It will try various I2C modules and then try various lm_sensors modules, until it finds a combination that works on your system. When it is done, it provides instructions for how to set up configuration files in /etc, which load the correct modules when your system boots.
Once the modules for lm_sensors are installed and working, you can run the sensors command from a shell and receive some useful output. But you probably aren't done yet.
Your next step is to edit the /etc/sensors.conf file. This file sets some custom parameters that make lm_sensors work with your computer system. For example, you can add a label that changes Temp1 to CPU Temp; you can disable Temp3 completely if you don't have a sensor and it is reporting nonsense; and you can customize the math functions used to calculate the displayed values.
Ideally, before you edit /etc/sensors.conf, you should reboot your computer and enter the BIOS setup screens. (For most computers, you hit the Del key or the F1 key during bootup to enter the BIOS. Check the owner's manual for your system, or watch the screen during bootup for a message like Hit <Del> to enter Setup.) The BIOS setup should have a sub-menu showing the same numbers you would like lm_sensors to report. Make a note of the readings you are seeing. For example, if the CPU temperature is about 60 degrees Celsius, write that down.
Now, booted back into Linux, run the sensors command. If the numbers are all there and look correct, you are done. If not, you need to customize /etc/sensors.conf.
Take a look at the top of the output of the sensors command; it shows you with which chip lm_sensors is communicating. Find that chip in /etc/sensors.conf and look at the settings you can customize. /etc/sensors.conf is liberally commented, making it easier to figure out what you need to do. You also can read the man page, man sensors.conf.
Once you have customized /etc/sensors.conf, you must run the command sensors -s to put your changes into effect. Then run the sensors command once again to inspect the values it reports.
Additionally, you should make sure sensors -s runs each time your system boots.
You have the option to install sensord, the lm_sensors monitoring dæmon. You can configure this to log either to standard log files or to a round-robin database (a constant-size database set up to hold, for example, a week's worth of readings; new readings overwrite the oldest). By editing /etc/syslog.conf, you can arrange to receive e-mail when sensor readings go out of bounds.
Practical Task Scheduling Deployment
July 20, 2016 12:00 pm CDT
One of the best things about the UNIX environment (aside from being stable and efficient) is the vast array of software tools available to help you do your job. Traditionally, a UNIX tool does only one thing, but does that one thing very well. For example, grep is very easy to use and can search vast amounts of data quickly. The find tool can find a particular file or files based on all kinds of criteria. It's pretty easy to string these tools together to build even more powerful tools, such as a tool that finds all of the .log files in the /home directory and searches each one for a particular entry. This erector-set mentality allows UNIX system administrators to seem to always have the right tool for the job.
Cron traditionally has been considered another such a tool for job scheduling, but is it enough? This webinar considers that very question. The first part builds on a previous Geek Guide, Beyond Cron, and briefly describes how to know when it might be time to consider upgrading your job scheduling infrastructure. The second part presents an actual planning and implementation framework.
Join Linux Journal's Mike Diehl and Pat Cameron of Help Systems.
Free to Linux Journal readers.Register Now!
- SourceClear Open
- SUSE LLC's SUSE Manager
- My +1 Sword of Productivity
- Tech Tip: Really Simple HTTP Server with Python
- Murat Yener and Onur Dundar's Expert Android Studio (Wrox)
- Managing Linux Using Puppet
- Non-Linux FOSS: Caffeine!
- Google's SwiftShader Released
- Doing for User Space What We Did for Kernel Space
- SuperTuxKart 0.9.2 Released
With all the industry talk about the benefits of Linux on Power and all the performance advantages offered by its open architecture, you may be considering a move in that direction. If you are thinking about analytics, big data and cloud computing, you would be right to evaluate Power. The idea of using commodity x86 hardware and replacing it every three years is an outdated cost model. It doesn’t consider the total cost of ownership, and it doesn’t consider the advantage of real processing power, high-availability and multithreading like a demon.
This ebook takes a look at some of the practical applications of the Linux on Power platform and ways you might bring all the performance power of this open architecture to bear for your organization. There are no smoke and mirrors here—just hard, cold, empirical evidence provided by independent sources. I also consider some innovative ways Linux on Power will be used in the future.Get the Guide