I recently had a mock interview with a senior Linux administrator who asked whether I could collect CPU, memory, and disk usage from a Bash script without using top, free, df, or any external commands. My first answer was no, but the interviewer hinted at the /proc and /sys virtual filesystems.
That made me realize that many familiar monitoring tools are mainly presenting data already exposed by the kernel. The follow-up questions were where I got stuck:
- How do you calculate CPU utilization from /proc/stat?
- How do you determine memory usage from /proc/meminfo?
- How can filesystem capacity and usage be obtained without df?
- What Bash features can parse these files without spawning commands such as cat, grep, or cut?
I understand that this may be more relevant for stripped-down systems, embedded environments, or unusual troubleshooting situations than for everyday administration. I would appreciate a clear explanation of the calculations, the relevant caveats, and whether this is a reasonable interview question for a Linux, DevOps, or SRE role.
4 Answers
The general principle is sound: utilities such as top and free read kernel-exposed counters and format them for people. Understanding /proc is valuable for minimal containers, embedded systems, broken installations, or situations where normal tools cannot start. However, memorizing every field and formula is less important than explaining how you would investigate it and checking the implementation of established tools when accuracy matters.
For a real interview, I would describe the approach, mention that CPU requires two samples, use MemAvailable for memory, and explain that filesystem statistics normally come from statvfs rather than a convenient /proc file.
For memory, /proc/meminfo reports values in kilobytes. The most useful modern calculation is usually:
used = MemTotal - MemAvailable
MemAvailable is preferable to simply subtracting MemFree because it estimates how much memory can be allocated without swapping, including reclaimable caches. On older kernels where MemAvailable is missing, an approximate fallback can combine MemFree, Buffers, Cached, and reclaimable slab while accounting for shared memory. The exact formula used by tools has changed over time, so it is better to treat the result as an estimate rather than an absolute physical-memory measurement.
Bash can parse the file using a while read loop with input redirection, and arithmetic expansion can calculate the result without cat, grep, or awk.
A simple Bash approach is to read each key and value, assign MemTotal and MemAvailable when encountered, then calculate (total - available) * 100 / total. Be careful about units and about a missing MemAvailable field.
For CPU usage, read the aggregate line beginning with cpu in /proc/stat twice, with a short delay between readings. Its fields are cumulative times measured in jiffies: user, nice, system, idle, iowait, irq, softirq, steal, guest, and guest_nice.
Add the fields to get total CPU time, and add idle plus iowait for idle time. Then calculate the differences between the two samples:
CPU usage = ((total_delta - idle_delta) / total_delta) * 100
A single reading cannot provide utilization because the values are counters; you need two samples. Also remember that guest times are included in other counters, so implementations should follow the behavior they are trying to reproduce rather than blindly double-counting fields.
The time values are called jiffies, which are kernel clock units rather than seconds. You do not need to convert them for the percentage calculation as long as both samples use the same unit.
Filesystem usage is the awkward part because /proc and /sys do not provide a simple per-mount equivalent of df. The usual underlying interface is the statvfs system call. It reports filesystem block counts and block size:
- total bytes = f_blocks * f_frsize
- free bytes = f_bfree * f_frsize
- non-root available bytes = f_bavail * f_frsize
- used bytes = (f_blocks - f_bfree) * f_frsize
The distinction between f_bfree and f_bavail matters because filesystems may reserve blocks for privileged processes. A pure Bash script cannot directly invoke statvfs without using a helper, library binding, or another program, so the strict “Bash with no external commands” requirement makes filesystem usage substantially harder than reading /proc/meminfo.
That is why a good answer should distinguish kernel data access from the scripting constraint. Reading /proc is possible with Bash built-ins, but statvfs is a system call and is not normally exposed as a Bash builtin.
The question can reveal useful operating-system knowledge for the right role, but it should not be treated as a pure memory test. A candidate who can reason from the available interfaces and validate the details is demonstrating the more important skill.