Learn › Linux Foundations › System Inspection
Part 1 of 2: lscpu, nproc, lsblk, lspci and lshw (Sections 21.1 to 21.5). No machine test here; it completes on the final step. The chapter lab waits at the end of Part 2.
This chapter covers the following topics:
This is Part 1 of 2. It covers Sections 21.1 to 21.5, the hardware Linux reports: the processors, the disks, the devices on the PCI bus, and one inventory of the whole machine. Part 2 covers Sections 21.6 to 21.11: memory, the running processes, the files they hold open, and how to end a process. It ends in the chapter lab, which covers all eleven sections.
What you already know: Section 4.13 printed /proc/cpuinfo, and Section 4.14 listed the network interfaces in /sys/class/net. Section 4.9 read the mount table, Section 5.11 measured free space with df, and Section 11.2 sent the output of a command into a file with >. This part reads the same kernel facts through tools that summarize them, and saves two of the answers into files.
Objectives
After this part you can:
Select Start machine in the adjacent workspace and use its Terminal. The command cards show selected, recorded examples from a prepared server, with omitted lines marked ...; inspect the real output in your Terminal. Hardware facts come from that machine, so its processor model, sizes and device addresses can differ from the examples. This part has no separate graded lab; it completes on its final step. The chapter assessment starts a separate fresh machine after Part 2 and checks commands and saved reports.
Five questions before the material. A wrong answer costs nothing: the explanation states the fact and names the section that teaches it.
>>> The kernel detects the hardware when the machine starts and publishes what it found as files under /proc and /sys. lscpu reads those files and prints a summary. Section 21.1.
>>> nproc counts the processors this machine may run programs on. The virtual machine was given one, whatever the physical chip holds. Section 21.2.
>>> lsblk reports the size of each block device: its capacity. How much of a filesystem is used or free is what df from Section 5.11 reports. Section 21.3.
>>> lspci lists what is attached to the PCI bus. The kernel operates a device through a driver, and lspci -k prints the driver in use for each device. Section 21.4.
>>> Parts of the hardware description are readable by root only. lshw still prints everything an ordinary account can read, and warns that the list may be incomplete. Section 21.5.
Section 1.1 defined the kernel, the central part of the operating system that drives the hardware. It detects devices at startup and as they appear, then exposes current facts through virtual files under /proc and /sys. Section 4.13 printed one of those files, /proc/cpuinfo, and Section 4.14 listed /sys/class/net. The tools in this part read kernel reports and print summaries. None of these inspection commands changes a device.
A processor, or CPU (central processing unit), is the part of a computer that runs programs. lscpu prints one summary of the processors: what kind they are, how many there are, and how they are arranged. It takes no argument, so it reads the same wherever you stand. Print the summary:
prompt: admin@server1:~$ answer: lscpu output: Architecture: x86_64 CPU op-mode(s): 32-bit, 64-bit Address sizes: 48 bits physical, 48 bits virtual Byte Order: Little Endian CPU(s): 1 On-line CPU(s) list: 0 Vendor ID: AuthenticAMD Model name: AMD EPYC 7713 64-Core Processor CPU family: 25 Model: 1 Thread(s) per core: 1 Core(s) per socket: 1 Socket(s): 1 ... Virtualization features: Hypervisor vendor: KVM Virtualization type: full ... hint: Section 21.1. The processor summary command, lscpu, typed on its own with no option and no path.
Your model name and several numbers differ, because they describe the physical machine your server runs on. The lines marked ... are skipped here: the list of processor features, the caches, and the known processor weaknesses with the kernel's protection against each.
Read it from the top. Architecture is the family of instructions the processor understands; x86_64 is the 64-bit form of the Intel and AMD family. CPU(s) is the number of processors the kernel can run programs on: 1. On-line CPU(s) list numbers them from 0, the same numbers as the processor lines of /proc/cpuinfo. Vendor ID and Model name name the maker and the chip.
The next three lines explain the count. A socket is the place on a board where one processor chip sits. A core is one complete processor inside a chip. A thread is a share of a core that can run a program of its own. CPU(s) is threads per core times cores per socket times sockets: 1 times 1 times 1 is 1.
A virtual machine is a computer made in software: a program on a physical machine, the host, gives it memory, disks and processors of its own. That program is a hypervisor. The lines Hypervisor vendor: KVM and Virtualization type: full say that server1 is such a machine, run by KVM, the hypervisor built into Linux.
This explains two numbers that seem to disagree. On this server, the model name describes the host's chip, while CPU(s): 1 says how many virtual processors this machine was given. Another hypervisor may present a different model name. Read this machine's processor count from CPU(s), or from nproc in the next section, rather than from the model name.
nproc prints one number: how many processors are available to it. Scripts use it to decide how many tasks to run at the same time, because one number is easier to use than a summary to read. It takes no path. Print the count:
prompt: admin@server1:~$ answer: nproc output: 1 hint: Section 21.2. The counting command nproc, with nothing after it.
One, the same count as CPU(s) in lscpu. The number is the whole output: nothing to search for, which is why a script asks nproc rather than lscpu.
A program can be limited to some of the processors, and plain nproc counts only the ones the program asking may use. --all counts every processor the kernel knows, whether or not this program may use it. Print that count:
prompt: admin@server1:~$ answer: nproc --all output: 1 hint: Section 21.2. The counting command with its option --all.
Also one. Nothing on this server limits a program to fewer processors, so the two forms agree. Where they differ, plain nproc gives the number your program can actually use.
This chapter adds one directory to the server, inspect, in your home directory. Part 2 uses most of it; this part saves two answers into it. List ~/inspect:
prompt: admin@server1:~$ answer: ls ~/inspect ||| ls inspect ||| ls ~/inspect/ ||| ls inspect/ output: README.txt answers logs hint: Section 21.2. The listing command from Chapter 2, then the directory ~/inspect.
Three entries: a README, the directory answers, which is empty and is where the chapter lab asks you to save reports, and the directory logs, which Part 2 reads.
Section 11.2 sent the output of a command into a file with > instead of to the screen. A reading saved in a file can be compared, kept and read again later, and the chapter lab grades some answers from files like this against what the machine itself reports. Save the count of processors into ~/inspect/answers/cpus.txt:
prompt: admin@server1:~$ answer: nproc > ~/inspect/answers/cpus.txt ||| nproc > inspect/answers/cpus.txt output: hint: Section 21.2. The counting command, then > and the path ~/inspect/answers/cpus.txt (Section 11.2).
Nothing on the screen: the number went into the file. The shell created cpus.txt, because it did not exist yet, and connected it to the output of nproc before nproc ran.
Print the file you have just written, ~/inspect/answers/cpus.txt:
prompt: admin@server1:~$ answer: cat ~/inspect/answers/cpus.txt ||| cat inspect/answers/cpus.txt output: 1 hint: Section 5.1. The printing command, then the path ~/inspect/answers/cpus.txt.
The same 1 that nproc printed, now kept on disk.
A block device is storage the kernel reads and writes in fixed-size blocks: a disk, or a part of one. A partition is a part of a disk set aside as if it were a disk of its own; on many servers you see them as sda1 and sda2 under sda. lsblk, list block devices, prints every block device the kernel knows as a tree: each disk, then the partitions inside it. It reads the kernel's own list, so it takes no path. List the block devices:
prompt: admin@server1:~$ answer: lsblk output: NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINTS sda 8:0 0 24.5G 0 disk / sdb 8:16 0 496M 0 disk [SWAP] hint: Section 21.3. The block device command lsblk, with nothing after it.
Your sizes may differ. One row per device, one column per fact. NAME is the device, which is also its file under /dev. MAJ:MIN is the pair of numbers the kernel knows it by. RM is 1 for a removable device. SIZE is its capacity. RO is 1 for a read-only device. TYPE is disk for both rows. MOUNTPOINTS is where it is attached to the tree.
sda is the disk df reported in Section 5.11, mounted at /. sdb is a second disk that holds the swap space, disk space the kernel uses as extra memory; [SWAP] marks it, and Section 4.9 met its line in /etc/fstab. Neither disk carries partitions: on this server each filesystem covers a whole disk, so the tree has no branches.
Section 5.11 defined a filesystem, a formatted storage area attached to the tree at a mount point. -f asks lsblk for the filesystem on each device instead of its size and numbers:
prompt: admin@server1:~$ answer: lsblk -f ||| lsblk --fs output: NAME FSTYPE FSVER LABEL UUID FSAVAIL FSUSE% MOUNTPOINTS sda ext4 1.0 linode-root 0e7d42e2-d1b3-bc32-7ed6-ce43411b61cc 21.5G 5% / sdb swap 1 linode-swap f1408ea6-59a0-11ed-bc9d-525400000001 [SWAP] hint: Section 21.3. The block device command with its filesystem option -f.
Your free space and percentage differ. FSTYPE is the kind of filesystem: ext4, the usual Linux filesystem, on sda, and swap on sdb. FSVER is its version. LABEL is a name you can give a filesystem, and it is empty when none was given. UUID is a unique ID written into the filesystem when it was made; /etc/fstab names what to mount by these IDs (Section 4.9). FSAVAIL and FSUSE% are the space still available on a mounted filesystem and the share of it in use.
The SIZE column of lsblk is the capacity of the disk, and it does not change when files are written. How much of that room is used and how much is free belongs to the filesystem, and Section 5.11 read it with df. df -h / on the same server:
Filesystem Size Used Avail Use% Mounted on
/dev/sda 25G 1.6G 22G 7% /Your figures differ. The two sizes do not match, and both are right. lsblk measures the whole disk and prints one decimal. df measures the room the filesystem offers for files, and rounds it up to a whole number. That room is a little less than the disk, because the filesystem keeps part of the disk for its own records. For the disks a machine has, read lsblk; for the space left, read df, or the FSAVAIL column of lsblk -f.
Save the output of lsblk into ~/inspect/answers/disks.txt, the same way Exercise 21-5 saved the count:
prompt: admin@server1:~$ answer: lsblk > ~/inspect/answers/disks.txt ||| lsblk > inspect/answers/disks.txt output: hint: Section 21.3. The block device command with no option, then > and the path ~/inspect/answers/disks.txt.
Silent again. Read it back with cat ~/inspect/answers/disks.txt:
Compare the saved table with a fresh lsblk on the same machine. Saving the report changes where its output goes, not the disk's capacity. The chapter lab compares your saved file with its own reading from that machine.
A bus is the connection the parts of a computer use to talk to each other. PCI, Peripheral Component Interconnect, is the bus most devices inside a computer are attached to: network cards, disk controllers, graphics. lspci lists every device on it, one line each. On a virtual machine these are the devices the hypervisor presents. List them:
prompt: admin@server1:~$ answer: lspci output: 00:00.0 Host bridge: Intel Corporation 82G33/G31/P35/P31 Express DRAM Controller 00:01.0 VGA compatible controller: Device 1234:1111 (rev 02) 00:02.0 SCSI storage controller: Red Hat, Inc. Virtio SCSI 00:03.0 Ethernet controller: Red Hat, Inc. Virtio network device 00:1f.0 ISA bridge: Intel Corporation 82801IB (ICH9) LPC Interface Controller (rev 02) 00:1f.2 SATA controller: Intel Corporation 82801IR/IO/IH (ICH9R/DO/DH) 6 port SATA Controller [AHCI mode] (rev 02) 00:1f.3 SMBus: Intel Corporation 82801I (ICH9 Family) SMBus Controller (rev 02) hint: Section 21.4. The PCI listing command lspci, with nothing after it.
Your list may differ in its addresses and names. Each line reads left to right. First comes the address of the device on the bus: bus, slot and function, such as 00:03.0. Then its class, which says what kind of device it is, then the vendor and the model. A device the naming database does not know is printed by its numbers instead: the word Device, then the vendor number and the device number.
Most lines are the chipset the hypervisor emulates, the bridges and controllers every PC has. Two lines carry the machine's real work: the Ethernet controller, the network card whose interface Section 4.14 found as eth0, and the SCSI storage controller the disks sda and sdb are attached to. Red Hat, Inc. is the vendor of the virtio devices, the virtual hardware KVM machines use: the company registered the numbers these devices carry.
A device needs software that knows how to operate it. A driver is the kernel component that handles a device; many drivers come as kernel modules, files the kernel can load when needed. -k shows the driver in use and possible modules where that information is available:
prompt: admin@server1:~$ answer: lspci -k output: 00:00.0 Host bridge: Intel Corporation 82G33/G31/P35/P31 Express DRAM Controller Subsystem: Red Hat, Inc. QEMU Virtual Machine 00:01.0 VGA compatible controller: Device 1234:1111 (rev 02) Subsystem: Red Hat, Inc. Device 1100 Kernel driver in use: bochs-drm Kernel modules: bochs 00:02.0 SCSI storage controller: Red Hat, Inc. Virtio SCSI Subsystem: Red Hat, Inc. Virtio SCSI Kernel driver in use: virtio-pci Kernel modules: virtio_pci 00:03.0 Ethernet controller: Red Hat, Inc. Virtio network device Subsystem: Red Hat, Inc. Virtio network device Kernel driver in use: virtio-pci Kernel modules: virtio_pci 00:1f.0 ISA bridge: Intel Corporation 82801IB (ICH9) LPC Interface Controller (rev 02) Subsystem: Red Hat, Inc. QEMU Virtual Machine Kernel driver in use: lpc_ich Kernel modules: lpc_ich 00:1f.2 SATA controller: Intel Corporation 82801IR/IO/IH (ICH9R/DO/DH) 6 port SATA Controller [AHCI mode] (rev 02) Subsystem: Red Hat, Inc. QEMU Virtual Machine Kernel driver in use: ahci Kernel modules: ahci 00:1f.3 SMBus: Intel Corporation 82801I (ICH9 Family) SMBus Controller (rev 02) Subsystem: Red Hat, Inc. QEMU Virtual Machine Kernel driver in use: i801_smbus Kernel modules: i2c_i801 hint: Section 21.4. The PCI listing command with the kernel option -k.
Your lines may differ. Under each device, indented, up to three lines. Subsystem names the model as the maker of the whole board describes it. Kernel driver in use names the driver operating the device right now. Kernel modules names the modules able to drive it.
The network card and the disk controller are both driven by virtio-pci, the kernel's driver for virtio devices. If a device has no Kernel driver in use line, this report does not show a kernel driver attached to it. That is a reason to investigate, not proof that the device or the service using it has failed. Compare the device with the relevant interface or storage report before deciding on a change.
lshw, list hardware, combines what the tools above print, and more, into one inventory arranged as a tree: the machine, its board, the memory, the processors, the buses and
Practice Chapter 21, Part 1. System Inspection: lscpu, nproc, lsblk, lspci and lshw in a real Linux terminal at The Linux Camp. Progress is verified automatically as you type commands on the machine.