Linux's Tell-Tale Heart, Part 6
Hello, everyone. Nice to see your smiling faces back here on the corner, the SysAdmin's Corner, that is. This week, we're going to wrap up the "Tell-Tale Heart" series with something so cool, you may never look at your Linux system in the same way. You might not know it, but there is a phantom living on your computer: a filesystem with lots of directories and files, much like any other filesystem, except that this one isn't really there at all. In fact, it disappears every time you shut down, and is rebuilt every time you reboot.
While I was writing this article, I realized I was having almost too much fun. Some things in life are so cool that you just want to keep fiddling with them. In the last few articles, I've been comparing your Linux system logs to a kind of digital diary kept by your system. If logs are a peek at your system's private diaries, then the /proc filesystem (or pseudo-filesystem, since it doesn't really exist) is a means of looking into the very soul of your system.
Okay, I've said it twice now. How can the mysterious /proc filesystem not really exist? If I do an ls -l on the root directory, I get a directory of size zero. Try it out yourself.
# ls -l / (note: only showing partial listing) drwxr-xr-x 2 root root 4096 Aug 1 15:07 patch dr-xr-xr-x 90 root root 0 Aug 12 19:57 proc drwxr-x--- 113 root root 12288 Aug 14 14:55 root drwxr-xr-x 3 root root 4096 Jul 12 16:40 sbin drwxrwxrwt 8 root root 4096 Aug 14 15:21 tmp drwxr-xr-x 21 root root 4096 Mar 13 17:07 usr drwxr-xr-x 18 root root 4096 Jun 22 18:59 var
Notice that /proc does indeed have a zero size. Yet when I change to the /proc directory with cd /proc and do an ls there, I see tons of information.
# cd /proc # ls 1 10102 10105 10311 10315 10702 10710 10712 10714 10715 10716 10717 10718 10719 10720 10721 10722 10723 10755 10766 1145 1146 1147 1148 1149 1150 1151 1152 2 3 330 345 346 355 369 4 420 429 443 446 447 449 450 461 475 490 5 508 528 583 6 612 626 675 715 716 717 718 719 720 723 745 752 753 757 771 773 775 776 7922 808 811 8784 8786 8788 8789 8936 9008 9088 911 914 9957 apm bus cmdline cpuinfo devices dma fb filesystems fs ide interrupts ioports kcore kmsg ksyms loadavg locks mdstat meminfo misc modules mounts net partitions pci rtc scsi self slabinfo sound stat swaps sys tty uptime version
For an empty directory, there's quite a bit here. Let's start with some easy stuff.
Oops. Before I move on, let me offer a word of WARNING!!! <begin weasel words> Unless you know exactly what you are doing, do not go changing the contents of your /proc filesystem. There are some pretty neat things you can do with several of the entries and you can tweak your actual running system by changing various things here, but be warned. <end weasel words> Ahem, where was I? Oh, yeah...
Easy stuff. Look at the file called "cpuinfo", for starters. Another zero-size file. Now, cat the file and have a look at the results. This is what mine shows:
# cat /proc/cpuinfo processor : 0 vendor_id : GenuineIntel cpu family : 5 model : 2 model name : Pentium 75 - 200 stepping : 12 cpu MHz : 150.342254 fdiv_bug : no hlt_bug : no sep_bug : no f00f_bug : yes coma_bug : no fpu : yes fpu_exception : yes cpuid level : 1 wp : yes flags : fpu vme de pse tsc msr mce cx8 bogomips : 59.80
Actually it's a Pentium 150, but it is still kind of fascinating to read what my system thinks of itself. Let's see what happens when we look at the file called "interrupts". Guesses, anyone?
# cat /proc/interrupts CPU0 0: 6422178 XT-PIC timer 1: 43093 XT-PIC keyboard 2: 0 XT-PIC cascade 5: 3 XT-PIC soundblaster 8: 1 XT-PIC rtc 10: 34143 XT-PIC eth0 12: 541052 XT-PIC PS/2 Mouse 13: 1 XT-PIC fpu 14: 1622951 XT-PIC ide0 15: 6 XT-PIC ide1 NMI: 0
Similarly, doing a cat on the meminfo file will give you current stats about your memory, both physical and swap. Looking into /proc/scsi will reveal your SCSI assignments, while a look at the sound file will show you your sound card configuration. A cat of your /proc/partitions file will display your disk partition information, and "version" is your running kernel and how it was compiled. Keep looking. There's a lot here, and it's balls of fun.
By now, you may have noticed I did not tell you the whole truth. When you did an ls -l on /proc, you actually found two non-zero-size files. One of them is called "kcore" and it can be a fairly good size for something that takes up no space. If you really want to look into the heart of your Linux system, listen closely; you can almost hear it beating when you look here. This is a "mirror" of sorts for your kernel. Perhaps the lens of a microscope would be a better analogy. Notice how the file takes up about as much space as you have physical memory. That is no coincidence. kcore is your system's memory - its RAM, if you prefer. In fact, it is everything currently in RAM, and as such, it is a dynamic beast. The same can be said for much of what you see in /proc. Looking at "meminfo" from one minute to the next will yield a different set of numbers as the demands of real memory vs swap are handled.
The other "big" file (though much smaller) is something called "self", and if you do an ls -l on /proc, you'll notice that self is actually a pointer to a number. Here's what I get when I do that ls -l right now:
lr>wxrwxrwx 1 root root 64 Aug 16 13:28 self -> 2183
The reason I asked you to ls -l the whole /proc directory rather than just "self" is this: I wanted you to see that the number (in my case, 2183) is also a directory under the /proc directory. Now, do another ls -l. It's gone, isn't it?
What about all those numbers? What are they for? Each one seems to be a directory. What will you find there? Do this: try a ps ax to get a list of the running processes on your system. Even better, do it this way:
ps ax | cut -c1-5
That will get you just the process numbers without the long display. Now, compare that list to the numbers sitting in /proc. Look familiar? Every process currently running on your system has an analog sitting in the /proc filesystem. Let's have a look at what we can discover hidden in there. Just for fun, let's take one of the processes on my system. For this little exploring about, I am using a terminal emulator called Eterm. If you don't have it, get it from http://www.eterm.org. You'll thank me later. Sure, it's eye candy, but a little bit of eye candy isn't all bad, right? (There I go, wandering off again. Sorry.)
The process ID for one of my Eterm sessions is 834 (the result of ps ax | grep Eterm). If I cd to /proc/834 and do an ls -l, this is what I see:
total 0 -r--r--r-- 1 mgagne mgagne 0 Aug 16 13:59 cmdline lrwx------ 1 mgagne mgagne 0 Aug 16 13:59 cwd -> r/share/Eterm/themes/Eterm -r-------- 1 mgagne mgagne 0 Aug 16 13:59 environ lrwx------ 1 mgagne mgagne 0 Aug 16 13:59 exe -> r/bin/Eterm-0.8.10 dr-x------ 2 mgagne mgagne 0 Aug 16 13:59 fd pr--r--r-- 1 mgagne mgagne 0 Aug 16 13:59 maps -rw------- 1 mgagne mgagne 0 Aug 16 13:59 mem lrwx------ 1 mgagne mgagne 0 Aug 16 13:59 root -> / -r--r--r-- 1 mgagne mgagne 0 Aug 16 13:59 stat -r--r--r-- 1 mgagne mgagne 0 Aug 16 13:59 statm -r--r--r-- 1 mgagne mgagne 0 Aug 16 13:59 status
Once again, a number of these can be viewed with cat or more or less. The cmdline file shows the command that executed Eterm, while environ displays the environment variables at work here. Check out maps for a list of all the libraries at work with the current executable. Look inside that fd directory, and see if you can figure out what those numbers represent.
Sure, there are system commands that do a fine job of showing what is happening in /proc. The command top, for instance, is just such a snapshot for your processes. Files such as meminfo and pci can be graphically unwound with the help of KDE's kcontrol program. Just check out the Information tab. If you look long and hard enough, you will likely find a tool to display all this stuff in a nice, graphical format. In some ways, that's part of the reasoning behind the /proc filesystem: to give programmers/administrators/etc. an easier means of accessing core system information and modifying a running kernel. Get the tools later. Look around now. It's a kind of techno adventure, where the prize is a deeper understanding of what happens under your system's "hood". Yes, Bobby, that's the same hood that's not welded shut.
Did I just say modifying a running kernel? Hmmm... that sounds like a good place to stop and get you ready for something brand-new when next we meet here at the SysAdmin's Corner. (Ain't I a stinker?) Until next time, always remember: your Linux system is talking to you. Are you listening?
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!
- SUSE LLC's SUSE Manager
- My +1 Sword of Productivity
- Murat Yener and Onur Dundar's Expert Android Studio (Wrox)
- Managing Linux Using Puppet
- Non-Linux FOSS: Caffeine!
- Doing for User Space What We Did for Kernel Space
- SuperTuxKart 0.9.2 Released
- Parsing an RSS News Feed with a Bash Script
- Google's SwiftShader Released
- Rogue Wave Software's Zend Server
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