Learn › Linux Foundations › Important Files and Paths
cat - a hands-on Linux lab on a real virtual machine.
Read the live state of a running Linux machine through /proc, a virtual filesystem the kernel generates on demand. The numbered PID directories, the zero-byte files that still print text, and the field layout of /proc/uptime and /proc/loadavg. /proc is structure-only: your values change on every read, so the drills teach the shape and the moves, not the digits.
Run ls on a normal folder and you see files that sit on a disk: they take up space, they have a size, they stay put until something changes them. Now meet a folder where none of that is true.
There is a directory on every Linux machine called /proc. It looks like an ordinary folder full of files. But those files are not stored anywhere. There is no disk behind them. The moment you read one, the kernel, the core program that runs the whole system, invents its contents on the spot and hands them back as plain text. Read the same file two seconds later and the numbers have already changed.
The black boxes in this lesson are a practice terminal: a safe sandbox that only checks the one command each step teaches, so you cannot break anything. /proc is generated live from a running machine, so the exact numbers, the process IDs, and the hardware details shown here are one real capture kept as an example. On the live machine at the end of the module, you read /proc on your own system and see your own values. Focus on the SHAPE, not the digits.
/proc is a virtual filesystem. A filesystem is the way Linux presents storage as folders and files. A virtual one presents something that is NOT storage using those same familiar folders and files. In /proc, the kernel exposes the live state of the running system as text you can cat like any other file.
Think of it as a window, not a cabinet. A filing cabinet holds papers that stay until you move them. A window shows you whatever is happening outside right now, and the view changes on its own. /proc is the window: every read shows the system as it is at that instant.
Two kinds of thing live inside. First, numbered directories, one for every program currently running, each named by that program's ID number. Second, system files such as uptime, loadavg, cpuinfo, and meminfo, each answering one question about the machine as a whole. Look at the listing first:
ls /proc
prompt: student@linuxcamp:~$ answer: ls /proc output: 1 14 823 cpuinfo loadavg meminfo uptime 9 412 901 filesystems mounts stat version hint: Type ls, a space, then the path /proc: ls /proc
The numbers (1, 9, 14, 823...) are directories, one per running program. The number IS the program's PID, its process ID, the unique tag the kernel gives every running program. /proc/1 is always the first program the system started at boot. The words (cpuinfo, loadavg, meminfo, uptime...) are the system files. Your machine will list DIFFERENT PID numbers, because different programs are running, but you will always see this same mix: a pile of numbers plus a handful of named files.
Before you read a value, look at how big these files are. In an earlier lesson you learned ls -l, the long listing that shows each file's size in bytes. Point it at a /proc file and something odd happens.
Before you run this, decide what you expect the size column to say. A file full of system information should be, what, a few hundred bytes? Run it and look at the number:
ls -l /proc/uptime
prompt: student@linuxcamp:~$ answer: ls -l /proc/uptime output: -r--r--r-- 1 root root 0 Jul 5 14:22 /proc/uptime hint: Use the long listing ls -l you already know, on the path /proc/uptime: ls -l /proc/uptime
The size is 0. Zero bytes. Every file in /proc reports a size of zero, because there is nothing on a disk to measure. The file does not exist until you read it, and the instant you do, the kernel produces its contents fresh. So ls sees an empty shell and reports 0, yet cat on that very same file prints a full line of text. A zero-byte file that is nonetheless full of information is the signature of /proc. It is not a bug and not an empty file. It is the kernel telling you: there is no stored copy here, ask me and I will generate it.
Now read one. /proc/uptime answers a simple question: how long has this machine been running? cat prints its contents, which is a single line of exactly two numbers separated by a space.
cat /proc/uptime
prompt: student@linuxcamp:~$ answer: cat /proc/uptime output: 12345.67 98765.43 hint: Type cat, a space, then the path /proc/uptime: cat /proc/uptime
Two numbers, both counted in seconds. The first, 12345.67, is how long the system has been powered on since its last boot: here about 12,345 seconds, which is a little under three and a half hours. The second, 98765.43, is total idle time, the seconds all the processor cores spent doing nothing, added together. On a machine with several cores the idle total can be larger than the uptime, because each core counts its own idle seconds separately. Your two numbers will be completely different from these, and that is the point of the next step.
Here is the demonstration that makes /proc click. These files are not snapshots. They are generated at the moment you read them, so the value is never the same twice. Read /proc/uptime once, then read it again, and watch the first number climb.
Run the exact same command a second time:
cat /proc/uptime
prompt: student@linuxcamp:~$ answer: cat /proc/uptime output: 12349.12 98801.55 hint: The very same command as before, run once more: cat /proc/uptime
Look at the first number: it grew from 12345.67 to 12349.12. A few seconds passed between the two reads, and the file reported those seconds. Nothing was updated by hand. The kernel regenerated the file the instant you asked. This is why you must never store a /proc value and reuse it later: by the time you look again, it is stale. Always re-read. The number you want is only ever true at the moment you read it.
One more system file, and this is the one engineers reach for most. /proc/loadavg reports how busy the machine has been. cat prints a single line of five fields.
cat /proc/loadavg
prompt: student@linuxcamp:~$ answer: cat /proc/loadavg output: 0.15 0.10 0.05 1/234 5678 hint: Type cat, a space, then the path /proc/loadavg: cat /proc/loadavg
Five fields, left to right. The first three, 0.15 0.10 0.05, are the load averages over the last 1, 5, and 15 minutes: a rough measure of how many programs were waiting to run. Low numbers mean a quiet machine; numbers climbing above your core count mean a busy one. The fourth field, 1/234, is two counts joined by a slash: 1 process running right now out of 234 that exist in total. The last field, 5678, is the PID of the most recently created process. Your five values will differ, but the shape, three decimals, then a fraction, then one number, is identical on every Linux machine.
You have now read the same data that the famous monitoring tools read. When you run top to watch running programs, or free to check memory, or uptime to see the load, those tools are not doing anything magic. They open files in /proc, read exactly the text you just read, and format it prettily. /proc/loadavg is where the uptime command gets its load figures. /proc/meminfo is where free gets its memory totals. /proc/cpuinfo holds a block of details for each processor core.
The two big reference files are worth knowing by name even though their contents are long. cat /proc/cpuinfo prints a block per core (model name, speed, and more), so a four-core machine repeats the block four times. cat /proc/meminfo prints dozens of memory figures, starting with MemTotal and MemFree. Both are pure text, both are generated live, and both look different on every machine. You do not need to memorise their contents, only that /proc is where this information lives.
The numbered directories are the other half of /proc. Each one is a folder of live facts about a single running program, named by its PID. /proc/1 is special: PID 1 is the very first process the kernel starts at boot, the ancestor of everything else. Inside its directory, the file comm holds the short name of that program.
cat /proc/1/comm
prompt: student@linuxcamp:~$ answer: cat /proc/1/comm output: systemd hint: Type cat, a space, then the path down into process 1: cat /proc/1/comm
The numbered directories come and go. A program starts, the kernel creates its /proc/<PID> directory; the program exits, the directory vanishes. So a PID you read a minute ago may point to nothing now, or to a different program entirely once the number is reused. PID 1 is the reliable one, always present, though the name inside comm may read systemd on one machine and init on another depending on what that system uses to start up. Never assume a numbered directory will still be there; list /proc again to see what is running right now.
Scaffolding off. No command is printed this time. You have every piece you need.
You have just sat down at an unfamiliar machine and you want to know how busy it has been over the last few minutes: the load averages, plus how many processes are running. You know there is one file that holds exactly that, five fields on a single line, and you know the command that prints a file's contents.
prompt: student@linuxcamp:~$ answer: cat /proc/loadavg output: 0.15 0.10 0.05 1/234 5678 hint: Combine the print-a-file command with the load file's path. Think cat, then the path under /proc that ends in loadavg.
That is the everyday move. cat printed the file, and the path /proc/loadavg pointed it at the live load figures. You recalled both from memory, which is the same recall the real machine will ask of you. Your five numbers will differ from these and will differ again the next time you read them, because /proc is generated fresh on every read. The shape is what you carry: three load averages, a running-over-total fraction, and the last PID.
You earned this cheat sheet. Every row is something you just ran:
And the one idea that ties it together: /proc is a live window, not a stored file. Every value is generated the instant you read it, so it is always current and never worth saving. When a tool like top, ps, or free shows you a number, it read that number from /proc.
If you ever want the raw truth behind a monitoring tool, go to the source. Instead of trusting a dashboard, cat the matching /proc file yourself: /proc/loadavg for load, /proc/meminfo for memory, /proc/uptime for how long the box has been up. Same data, no middleman.
The practice terminal has shown you the shape of /proc. You know it is a virtual filesystem the kernel generates live, that its files report size 0 yet print full text, that the numbered directories are running programs by PID, and that uptime and loadavg answer whole-machine questions in a fixed field order. Every one of those you typed yourself.
The Important Files module ends with one real Linux machine, the Important Files capstone mission, and that is where you read /proc for real. A VM boots just for you, with its own live kernel, its own PIDs, its own climbing uptime. It hands you objectives that use exactly what you practiced across this module: the account and group files, the host and boot files, and the live /proc window you just opened. One difference from here: the mission shows no commands. You read the objective, you recall the command, you type it. That recall is what makes it stick.
Finish the other Important Files lessons, then go read a live kernel for yourself.
Practice /proc in a real Linux terminal at The Linux Camp. Progress is verified automatically as you type commands on the machine.