How To: Check CPU Temps With lm_sensors

There are a variety of ways to check your CPU temps, and this one will be covering this with lm_sensors. It’s a handy application and it’s often installed by default. Moreover, it’ll be available for pretty much every distro out there.

This time around, we’ll be using the above-mentioned lm-sensors. Wikipedia describes lm_sensors as thus:

lm_sensors (Linux-monitoring sensors) is a free open-source software-tool for Linux that provides tools and drivers for monitoring temperatures, voltage, humidity, and fans. It can also detect chassis intrusions.

It then says that a citation is needed. Thank you, Wikipedia. That’s helpful.

With so little to go on, we can check the man page. Alas, man lm_sensors has no entry. You’ll actually need to use the less obvious man sensors. That description isn’t much better, but it beats a blank.

sensors is used to show the current readings of all sensor chips. sensors -s is used to set all limits as specified in the configuration file. sensors –bus-list is used to generate bus statements suitable for the configuration file.

This will, of course, also tell you more about using lm_sensors, though there really aren’t a whole lot of options. It outputs what it outputs and you’ll like it. You’ll potentially get more information than just the CPU temps, but this article is about how to check CPU temps.

Check CPU Temps:

This rest of this article should be short and straightforward. Like normal, open up your default terminal emulator by pressing CTRL + ALT + T. Once the terminal is open, you can install lm_sensors easily enough. Try one of the following (note the varied names):

Debian/Ubuntu/etc:

Suse/OpenSUSE:

Fedora/RHEL/Rocky:

Arch/Manjaro/etc:

So far so good, yes? Well, now we need sensors to find our hardware and that’s another command in the terminal. Specifically, it’s this:

That’s going to run and it’s interactive. You will have to type “YES” over and over again. You’ll eventually need to hit the ENTER button. Fortunately, once you’re done, it’s all over and you never have to do it again – unless you add/change hardware that has sensors.

With lm_sensors loaded properly, let’s check CPU temps! It’s a really simple command – and it’s just:

If you are an American that is easily frightened by the metric system, you can just add the -f switch for Fahrenheit, like so:

Your output should look something like this:

lm_sensors in action
That’s a pretty standard output. Note the included CPU temps (listed by core, starting at core 0).

It should be noted that there’s more to the output than the CPU temps. This is not always the case. Your hardware may not have sensors that report back the operating conditions – but your CPU will almost always report that data so that the OS can do things like throttle-down for energy saving purposes. Be sure to run man sensors to see the rest of the options.

Closure:

Congratulations! You can now easily tell how hot (or cold) your CPU is running. You should also look up your CPU’s temperature thresholds. This way you’ll be able to tell if your CPU is running hotter than it should be running. Doing this can save your hardware or give it greater longevity.

Thanks for reading! If you want to help, or if the site has helped you, you can donate, register to help, write an article, or buy inexpensive hosting to start your own site. If you scroll down, you can sign up for the newsletter, vote for the article, and comment.

The Meaning Of “Load Average” On Linux?

You may have come across “Load Average” in your Linux travels. It’s common for it to be misinterpreted but it’s simpler than you might think. In this article, I’ll try to explain it for you.

Knowing the load average may let you know when you need more powerful hardware. It could indicate that there’s a runaway process, or that there has been some sort of hack and you’re now running malware, perhaps mining cryptocurrency in the background. The load average is valuable information, though many folks don’t seem to know what it means.

I also see some load average misconceptions when I travel the ‘net. There are faulty interpretations and faulty implications. For example, it doesn’t necessarily mean that you were hacked or need hardware, it just means you need to start looking into the cause of a high load average. It doesn’t mean definitely anything – it could just be that you had a high load for a while due to a compute-intensive process.

This shouldn’t take very long, or be all that complicated, but we’ll see if I’m able to put it into words. I’ve never tried to put it into words before! Let’s see how that works out.

Linux Load Average:

First, let’s crack open your terminal. Use your keyboard and press CTRL + ALT + T. That should open your default terminal.

With the terminal open, run this simple command:

You should get an output similar to this:

So, let’s explain what’s going on here. 

Those are the average of CPU usage over the last 1 minute, 5 minutes, and 15 minutes. Each 1 is a CPU (or CPU core) that was waiting because it was busy. It was waiting, unable to process data because it was too busy running existing scheduled jobs. So, you can have some pretty high numbers.

Sometimes, you’ll see like a 1.04 as a result and that means that one CPU/core had a high average load over the past minute. The load average isn’t what the score was at 1, 5, or 15 minute intervals. It’s an average of CPU usage over time

If you have an 8 core CPU and they’re all busy over a minute, you’ll end up with a load average of 8.x, and you may still have a functioning (perhaps slowed down) computer. At the same time, if you’re on an old dual-core CPU then you may find that 2.x means your computer is entirely unusable due to the lag.

Obviously, most folks are going to want a lower load average but some folks may want a higher average so that they know they’re getting the most out of their hardware. As a general rule, you want your CPU’s load average lower so that you can move data in and out of it quickly. Having a high CPU load can create a bottleneck and that’s less than optimal.

Closure:

There we go… I think I explained it well enough. If not, just let me know and I’ll try to answer any comments that are questions. If you can think of a better way to describe it, feel free to add that too! Either way, it’s another article for the archives. Pretty soon, the year will be over!

Thanks for reading! If you want to help, or if the site has helped you, you can donate, register to help, write an article, or buy inexpensive hosting to start your own site. If you scroll down, you can sign up for the newsletter, vote for the article, and comment.

When Did I Last Reboot My Linux Box?

If you want to know when you did your last reboot on your Linux box, it’s actually pretty easy. This article explains how. I’m still not feeling quite up to snuff, so a quick and easy article is the call for the day!

You can run uptime in the terminal, and that will tell you how long your system has been up and running. The output will look something like this:

At this point, you could do the math and find your last reboot time. Of course, this being Linux, there’s an easier way to do this. This will be a quick (and easy) article and hopefully I’m doing a bit better tomorrow.

Find Last Reboot:

Like so many of these things, we need to start with the terminal open. You can do that by using your keyboard. Just press CTRL + ALT + T and your default terminal emulator should pop right up!

With that open, you can start with:

Which will give you an output similar to:

But, the command’s usefulness doesn’t stop there. No, no it does not! You can modify the command in a couple of ways to get some more refined response. Let’s say you only want the last three results? If so, you’d use this command:

This will give you an output like this:

You can also use ‘grep’ for your refining needs. Let’s say you want to know when you last rebooted in the month of May? Well, you can easily do that!

The output of which would look similar to this:

And, there you see it. As you can see, there were three reboots in the month of May on that box. This information may be useful for debugging reasons or even compliance reasons. How you use the information is up to you! Ain’t my job to tell you how.

Closure:

There. There’s your darned article for the day!

Seriously, yesterday’s article was really messed up. Fortunately, the kind folks at Reddit chimed in and were eager to help! The folks at Linux.org are usually good at catching the mistakes, of which there were many, but probably didn’t as the article is one from the old site and probably only skimmed it if they read it at all.

This leads me to think that I’m eventually going to have issues with getting an article up every other day. I’m still going to try, and I’ve done so since the start, but it’s pretty likely that I’ll eventually miss a day. I’ll try to take steps to not let that happen, but the real world is a fickle mistress.

Thanks for reading! If you want to help, or if the site has helped you, you can donate, register to help, write an article, or buy inexpensive hosting to start your own site. If you scroll down, you can sign up for the newsletter, vote for the article, and comment.

Let’s Install INXI

INXI is something I mention a lot. In fact, I’ve done a whole INXI article before, I like it that much. It makes sharing detailed hardware information easy. The people trying to help you when you need support may need detailed information about your hardware, which is where INXI excels and why it exists.

You may notice that I didn’t actually link to said previous article. It was a very different article. This one is really just about installing INXI, so that you can toss it out as a quick link while asking for more information. I’ll rewrite the old article to suit this site, probably when I want an ‘easy’ article. Anyhow…

When you post on forums, such as Linux.org, your question may require sharing information about your hardware. Unless otherwise specified, the way I’d run INXI is this:

Or:

The output of either of those will give you an adequate amount of information and covers most all the bases. It’s most of the available information without being all of the available information. You may be asked to run a more specific command and you should post the data between the [code]<output from command>[/code] tags to make it more easily read.

So, why this article? Well, there might as well be an article that tells you how to install it. This? This is that article. You’re welcome!

Installing INXI:

Let’s get right to it and start with the easy way. Start by opening  your terminal by pressing CTRL + ALT + T. Once that’s open, use the following command as is appropriate for your distro’s package manager.

Debian/Ubuntu: 

RHEL/Fedora:

Manjaro:

OpenSUSE:

Any of those should work with the right distro. INXI is a commonly used application and a great tool for your toolbox. So, depending on your distro, use one of those commands.

If you need to install it manually, and you’ll likely need elevated permissions for this, you can just run:

Because that doesn’t include the man page, you can grab that and install it with a simple command:

If nothing else, those last two commands should work on every Linux desktop system out there, though I suppose you may need to first install wget and need permission to write to the correct directories.

Now that you have INXI (and the manual) installed, just use the inxi -h command. If you’re asking for support somewhere, they’ll probably tell you which command they want you to run when they ask you to run it.

See also: https://smxi.org/

Closure:

Yup… This is a short article, and intentionally so. The goal here is to write an article that helps people install INXI. I think I’ve done that. I may write an article that’s more detailed, meaning ways of using INXI, but today is not that day. Today, it’s just about installation.

Thanks for reading! If you want to help, or if the site has helped you, you can donate, register to help, write an article, or buy inexpensive hosting to start your own site. If you scroll down, you can sign up for the newsletter, vote for the article, and comment.

How To: Use S.M.A.R.T. To Check Disk Health

Disk health is an important matter. Your storage media has a useful lifespan and the clock is ticking it from day one. Either hard disk drive (HDD) or solid state drive (SSD), your storage media has a limited lifespan.

You should plan on your drives failing because, given enough time or use, they will fail. This is a known limitation and there are ways to monitor disk health. Heck, in theory, many systems are supposed to monitor disk health and alert you of impending failure (see some BIOS options), though I’ve personally had poor luck relying on automated alerts. I periodically perform manual disk health checks.

We’ll be using “S.M.A.R.T.” (Self-Monitoring Analysis and Reporting Technology) and “smartmontools” for this exercise. It’s actually pretty accurate data – sorta… If it tells you there’s a problem, chances are good that drive health is an issue. However, drives are perfectly happy failing without giving you any warning at all. As I said in the opening paragraph, there’s a limit to how long your drives will last – but it will eventually and certainly fail.

At the same time, there are probably many of us who have ‘magical’ drives. I have an external HDD that gets used constantly – and it’s well over a decade old. On the other end of the spectrum, I’ve had drives fail within weeks of the warranty ending – and sometimes before the warranty ended. Drive failure is real and you should be prepared for it. The best way to be prepared for it is to have spares and a good backup plan.

So, let’s get started! (Also, click on the Wikipedia link above.)

Install ‘smartmontools’:

As I said above, we’ll be using ‘smartmontools’ to check the disk health with S.M.A.R.T. reporting. It’s a fairly robust application and is available for the major distros. Smartmontools is easily installed with your package manager, or you can do it in the terminal. If you want to do that, first open the terminal with CTRL + ALT + T and, once open, enter the appropriate command.

Debian/Ubuntu:

RHEL/Fedora:

Arch/Manjaro:

Any of those will work on the appropriate systems. If you use a distro that’s not listed, it’s probably available in your repositories. It’s a fairly common tool and disk health is important!

This doesn’t work with NVMe drives. If you’re looking for NVMe support, look up ‘nvmi-cli’. I’ll probably write an article on the subject sometime in the future.

Anyhow, the tool you’ll be using from smartmontools is ‘smartctl’. It’s included with the package and is pretty easy to use. Read on to see how!

Check Disk Health With ‘smartctl’:

First, you should check to see if the device reports disk health by looking to see if the device has S.M.A.R.T. enabled. You can run this command:

Where ‘/drive/path’, it’s often something like ‘/dev/sda’. You can look up your drive’s path easily enough. If it’s not enable, you can turn it on with:

Now, you can go ahead and check the status. To do that, you run:

That should output some data. Remember how I highly recommended you click the Wikipedia link above? Well you should. The data in the report is fairly well-covered on the Wiki page. If you didn’t click it above, you can click now.

Anyways, the data in the report above might be old because the command may output some stale information. To refresh the data in the report, you can run a short (or long) test. In this first case, we’re going to run a short test (lasting 2 minutes or less) with this command:

Wait the couple of minutes as prompted and then run the original command again to get a report with the updated information:

You can also run a long test. That’s done by changing the short to long, as in the command used above. It’s done like this:

That’ll take up to 10 minutes and you can check the results after that time has passed. Once again, you will simply run the same command you’ve been using all along:

Anyhow, pay attention to the results in that report. They’ll give you a lot of information. You can check the results and technical details against the Wikipedia link. With that information in hand, you can keep a reasonable eye on your disk health.

There’s more to smartctl and even smartmontools, but not a whole lot that’s terribly interesting or important. Simply run man smartctl and look through the options. The most interesting/valuable disk health checks are covered above, but there’s nothing wrong with knowing more about your tools.

Closure:

You know, if you install ‘gnome-disks’ then you can just do all of this graphically. Chances are good that all the distros out there that have smartmontools also have gnome-disks. If that’s more your style, just install it and poke around. It’s right there in the ‘three dot’ menu. Like so:

gnome-disks - check disk health with  SMART status
A nice GUI way! Give it a shot if you want!

But, that’d be cheating! It’d also be a much more basic article and where’s the fun in that? Nowhere. That’s where the fun isn’t. Seriously, the GUI method with gnome-tools works just fine for this if you’d prefer to go that route. Again, check your results against the Wikipedia link posted throughout the article. 

Anyhow, there’s another article in the books. One more article said and done, in my attempt to keep this going for a full year. It has been pretty fun. This article is about disk health and reminds me that I need to write one about backing up your data. That’s good, ’cause it means I’ve still got all sorts of ideas for articles! 

Don’t forget, you too can write articles. I don’t mind and it’d help me reach the year goal going!

Thanks for reading! If you want to help, or if the site has helped you, you can donate, register to help, write an article, or buy inexpensive hosting to start your own site. If you scroll down, you can sign up for the newsletter, vote for the article, and comment.

EDIT: Edited on 06/29/23 to correct spelling.

Linux Tips
Creative Commons License
This work is licensed under a Creative Commons Attribution 4.0 International License.