Knowing the sequence in which Linux starts processes as it boots is important. You can use this knowledge to start and stop services, such as the Web server and Network File System (NFS). The next few sections provide you with an overview of how Linux boots and starts the initial set of processes. These sections also familiarize you with the shell scripts that start various services on a Linux system.
Understanding the init process When Linux boots, it loads and runs the core operating system program from the hard drive. The core operating system is designed to run other programs. A process named init starts the initial set of processes on your Linux system.
To see the processes currently running on the system, type ps ax | more
You get an output listing that starts like this:
PID TTY STAT TIME COMMAND 1 ? S 0:22 init [2]
The first column, with the heading PID, shows a number for each process. PID stands for process ID (identification) — a sequential number assigned by the Linux kernel. The first entry in the process list, with a PID of 1, is the init process. It’s the first process, and it starts all other processes in your Linux system. That’s why init is sometimes referred to as the mother of all processes.
What the init process starts depends on
- The run level, an identifier that identifies a system configuration in which only a selected group of processes can exist.
- The contents of the /etc/inittab file, a text file that specifies which processes to start at different run levels.
- A number of shell scripts that are executed at specific run levels. (The scripts are located in the /etc/init.d directory and a number of subdirectories in /etc — these subdirectories have names that begin with rc.)
Most Linux distributions use seven run levels — 0 through 6. The meaning of the run levels differs from one distribution to another. Table 1-6 shows the meanings of the run levels and points out some of the actions specific to Fedora, Debian, SUSE, Ubuntu, and Xandros.
| Table 1-6 | Run Levels in Linux |
| Run Level | Meaning |
| 0 | Shut down the system |
| 1 | Run in single-user standalone mode (no one else can log in; you work at the text console) |
| 2 | Run in multiuser mode (Debian, Ubuntu, and Xandros use run level 2 as the default run level) |
| 3 | Run in full multiuser mode (used for text mode login in Fedora and SUSE) |
| 4 | Run in full multiuser mode (unused in Fedora and SUSE) |
| 5 | Run in full multiuser mode (used as the default run level with graphical login in Fedora and SUSE) |
| 6 | Reboot the system |
The current run level together with the contents of the /etc/inittab file control which processes init starts in Linux. The default run level is 2 in Debian, Ubuntu, and Xandros. In Fedora and SUSE, run level 3 is used for text mode login screens and 5 for the graphical login screen. You can change the default run level by editing a line in the /etc/inittab file.
To check the current run level, type the following command in a terminal window: /sbin/runlevel
In Debian, the runlevel command prints an output like this:
N 2
The first character of the output shows the previous run level (N means no previous run level), and the second character shows the current run level (2). In this case, the system started at run level 2. If you’re in a GUI desktop in Fedora, the runlevel command should show 5 as the current run level.
Examining the /etc/inittab file
The /etc/inittab file is the key to understanding the processes that init starts at various run levels. You can look at the contents of the file by using the more command, as follows:
more /etc/inittab
To see the contents of the /etc/inittab file with the more command, you don’t have to log in as root.
To interpret the contents of the /etc/inittab file, follow these steps:
- Look for the line that contains the phrase initdefault. Here’s that line from the /etc/inittab file from a Debian system:
id:2:initdefault:
That line shows the default run level. In this case, it’s 2. - Find all the lines that specify what init runs at run level 2.
Look for a line that has a 2 between the first two colons (:). Here’s a relevant line in Debian:l2:2:wait:/etc/init.d/rc 2
This line specifies that init executes the file /etc/init.d/rc with 2 as an argument.
If you look at the file /etc/init.d/rc in a Debian system, you find it’s a shell script. You can study this file to see how it starts various processes for run levels 1 through 5.
Each entry in the /etc/inittab file tells init what to do at one or more run levels — you simply list all run levels at which the process runs. Each inittab entry has four fields — separated by colons — in the following format:
id:runlevels:action:process
Table 1-7 shows what each field means.
| Table 1-7 | Fields in Each inittab Entry |
| Field | Meaning |
| id | A unique one- or two-character identifier. The init process uses this field internally. You can use any identifier you want, as long as you don’t use the same identifier on more than one line. |
| runlevels | A sequence of zero or more characters, each denoting a run level. For example, if the runlevels field is 12345, that entry applies to each of the run levels 1 through 5. This field is ignored if the action field is set to sysinit, boot, or bootwait. |
| action | What the init process will do with this entry. If this field is initdefault, for example, init interprets the run levels field as the default run level. If this field is set to wait, init starts the program or script specified in the process field and waits until that process exits. |
| process | Name of the script or program that init starts. Some settings of the action field require no process field. For example, when the action field is initdefault, there’s no need for a process field. |
To try a new run level, you don’t have to change the default run level in the /etc/inittab file. If you log in as root, you can change the run level (and, consequently, the processes that run in Linux) by typing init followed by the run level.
For example, to put the system in single-user mode, type the following:
init 1
Thus, if you want to try run level 3 without changing the default run level in /etc/inittab file, enter the following command at the shell prompt:
init 3
The system ends all current processes and enters run level 3. By default, the init command waits 20 seconds before stopping all current processes and starting the new processes for run level 3.
To switch to run level 3 immediately, type the command init -t0 3. The number after the -t option indicates the number of seconds init waits before changing the run level.
You can also use the telinit command, which is simply a symbolic link (a shortcut) to init. If you make changes to the /etc/inittab file and want init to reload its configuration file, use the command telinit q.
Understanding the Linux startup scripts
The init process runs a number of scripts at system startup. In the following discussions, a Debian system is used as an example, but the basic sequence is similar in other distributions — only the names and locations of the scripts may vary.
If you look at the /etc/inittab file in a Debian system, you find the following lines near the beginning of the file:
script. si::sysinit:/etc/init.d/rcS
The first line is a comment line. The second line causes init to run the /etc/init.d/rcS script — the first Linux startup script that init runs in a Debian system. The rcS script performs many initialization tasks, such as mounting the file systems, setting the clock, configuring the keyboard layout, starting the network, and loading many other driver modules. The rcS script performs these initialization tasks by calling many other scripts and reading configuration files located in the /etc/rcS.d directory.
After executing the /etc/init.d/rcS script, the init process runs the /etc/init.d/rc script with the run level as an argument. For example, for run level 2, the following line in /etc/inittab specifies what init executes:
l2:2:wait:/etc/init.d/rc 2
This example says init executes the command /etc/init.d/rc 2 and waits until that command completes.
The /etc/init.d/rc script is somewhat complicated. Here’s how it works:
- It executes scripts in a directory corresponding to the run level. For example, for run level 2, the /etc/init.d/rc script runs the scripts in the /etc/rc2.d directory.
- In the directory that corresponds with the run level, /etc/init.d/rc looks for all files that begin with K and executes each of them with the stop argument. This argument kills any currently running processes. Then it locates all files that begin with S and executes each file with a start argument. This argument starts the processes needed for the specified run level.
To see it executed at run level 2, type the following command:
ls -l /etc/rc2.d
In the resulting listing, the K scripts — the files whose names begin with K — stop (or kill) servers, whereas the S scripts start servers. The /etc/ init.d/rc script executes these files in the order in which they appear in the directory listing.
Manually starting and stopping servers
In Linux, the server startup scripts reside in the /etc/init.d directory. You can manually invoke scripts in this directory to start, stop, or restart specific processes — usually servers. For example, to stop the FTP server (the server program is vsftpd), type the following command:
/etc/init.d/vsftpd stop
If vsftpd is already running and you want to restart it, type the following command:
/etc/init.d/vsftpd restart
You can enhance your system administration skills by familiarizing yourself with the scripts in the /etc/init.d directory. To see its listing, type the following command:
ls /etc/init.d
The script names give you some clue about which server the script can start and stop. For example, the samba script starts and stops the processes required for Samba Windows networking services. At your leisure, you may want to study some of these scripts to see what each one does. You don’t have to understand all the shell programming; the comments help you discover the purpose of each script.
Automatically starting servers at system startup
You want some servers to start automatically every time you boot the system. The exact commands to configure the servers vary from one distribution to another.
In Fedora and SUSE, use the chkconfig command to set up a server to start whenever the system boots into a specific run level. For example, if you start the SSH server, you want the sshd server to start whenever the system starts. You can make that happen by using the chkconfig command. To set sshd to start whenever the system boots into run level 3, 4, or 5, type the following command (while logged in as root):
chkconfig --level 345 sshd on
In Fedora and SUSE, you can also use the chkconfig command to check which servers are turned on or off. For example, to see the complete list of all servers for all run levels, type the following command:
chkconfig –list
In Debian, Ubuntu, and Xandros, you can use the update-rc.d command to enable a server to start automatically at system startup. For example, to set sshd to start automatically at the default run levels, type update-rc.d sshd defaults in a terminal window while logged in as root. You can also specify the exact run levels and the sequence number (the order in which each server starts). To find out more about the update-rc.d command, type man update-rc.d in a terminal window.
Taking Stock of Linux System Configuration Files Linux includes a host of configuration files. All these files share text files that you can edit with any text editor. To edit these configuration files, you must log in as root. A selection of the most popular configuration files appears in Table 1-8, along with a brief description of each. This table gives you an idea of what types of configuration files a system administrator has to work with. In many cases, Linux includes GUI utility programs to set up many of these configuration files.
| Table 1-8 | Some Linux Configuration Files |
| Configuration File | Description |
| /boot/grub | Location of files for the GRUB boot loader. |
| /boot/grub/menu.lst | Configuration file for the boot menu that GRUB displays before it boots your system. |
| /boot/System.map | Map of the Linux kernel (maps kernel addresses into names of functions and variables). |
| /boot/vmlinuz | The Linux kernel (the operating system’s core). |
| /etc/apache2/httpd.conf | Configuration file for the Apache Web server (Debian). |
| /etc/apt/sources.list | Configuration file that lists the sources — FTP or Web sites or CD-ROM — from which the Advanced Packaging Tool (APT) obtains packages (Debian, Ubuntu, and Xandros). |
| /etc/at.allow | Usernames of users allowed to use the at command to schedule jobs for later execution. |
| /etc/at.deny | Usernames of users forbidden to use the at command. |
| /etc/bashrc | System-wide functions and aliases for the bash shell (Fedora). |
| /etc/bash.bashrc | System-wide functions and aliases for the bash shell (Debian, SUSE, Ubuntu, and Xandros). |
| /etc/cups/cupsd. conf | Printer configuration file for the Common UNIX Printing System (CUPS) scheduler. |
| /etc/fonts | Directory with font configuration files. (In particular, you can put local font configuration settings in the file /etc/fonts/local.conf.) |
| /etc/fstab | Information about file systems available for mounting and where each file system is to be mounted. |
| /etc/group | Information about groups. |
| /etc/grub.conf | The configuration for the GRUB boot loader in Fedora and SUSE. |
| /etc/hosts | List of IP numbers and their corresponding hostnames. |
| /etc/hosts.allow | Hosts allowed to access Internet services on this system. |
| /etc/hosts.deny | Hosts forbidden to access Internet services on this system. |
| /etc/httpd/conf/ httpd.conf | Configuration files for the Apache Web server (Fedora). |
| /etc/init.d | Directory with scripts to start and stop various servers. |
| /etc/inittab | Configuration file used by the init process that starts all the other processes. |
| /etc/issue | File containing a message to be printed before displaying the text mode login prompt (usually the distribution name and the version number). |
| /etc/lilo.conf | The configuration for the Linux Loader (LILO) — one of the boot loaders that can load the operating system from disk (present only if you use the LILO boot loader). |
| /etc/login.defs | Default information for creating user accounts, used by the useradd command. |
| /etc/modprobe.conf | Configuration file for loadable kernel modules, used by the modprobe command (Fedora and SUSE). |
| /etc/modules.conf | Configuration file for loadable modules (Debian and Xandros). |
| /etc/mtab | Information about currently mounted file systems. |
| /etc/passwd | Information about all user accounts. (Actual passwords are stored in /etc/shadow.) |
| /etc/profile | System-wide environment and startup file for the bash shell. |
| /etc/profile.d | Directory containing script files (with names that end in .sh) that the /etc/profile script executes. |
| /etc/init.d/rcS | Linux initialization script in Debian, SUSE, Ubuntu, and Xandros. |
| /etc/rc.d/rc.sysinit | Linux initialization script in Fedora. |
| /etc/shadow | Secure file with encrypted passwords for all user accounts (can be read by only root). |
| /etc/shells | List of all the shells on the system that the user can use. |
| /etc/skel | Directory that holds initial versions of files such as .bash_profile that copy to a new user’s home directory. |
| /etc/sysconfig | Linux configuration files (Fedora and SUSE). |
| /etc/sysctl.conf | Configuration file with kernel parameters that are read in and set by sysctl at system startup. |
| /etc/termcap | Database of terminal capabilities and options (Fedora and SUSE). |
| /etc/udev | Directory containing configuration files for udev — the program that provides the ability to dynamically name hot-pluggable devices and create device files in the /dev directory. |
| /etc/X11 | Directory with configuration files for the X Window System (X11) and various display managers such as gdm and xdm. |
| /etc/X11/xorg.conf | Configuration file for X.org X11 — the X Window System (Fedora, Ubuntu, and SUSE). |
| /etc/xinetd.conf | Configuration for the xinetd daemon that starts a number of Internet services on demand. |
| /etc/yum.conf | Configuration for the yum package updater and installer (Fedora). |
| /var/log/apache2 | Web server access and error logs (Debian). |
| /var/log/cron | Log file with messages from the cron process that runs scheduled jobs. |
| /var/log/boot.msg | File with boot messages (SUSE). |
| /var/log/dmesg | File with boot messages (Debian, Fedora, Ubuntu, and Xandros). |
| /var/log/httpd | Web server access and error logs (Fedora). |
| /var/log/messages | System log. |
When you’re the system administrator, you must keep an eye on how well your Linux system is performing. You can monitor the overall performance of your system by looking at information such as
- Central processing unit (CPU) usage
- Physical memory usage
- Virtual memory (swap-space) usage
- Hard drive usage
Linux comes with a number of utilities that you can use to monitor one or more of these performance parameters. The following sections introduce a few of these utilities and show you how to understand the information presented by said utilities.
Using the top utility
To view the top CPU processes — the ones that use most of the CPU time — you can use the text mode top utility. To start that utility, type top in a terminal window (or text console). The top utility then displays a text screen listing the current processes, arranged in the order of CPU usage, along with various other information, such as memory and swap-space usage. Figure 1-5 shows a typical output from the top utility.
Figure 1-5: You can see the top CPU processes by using the top utility.The top utility updates the display every five seconds. If you keep top running in a window, you can continually monitor the status of your Linux system. To quit top, press Q or Ctrl+C or close the terminal window.
The first five lines of the output screen (see Figure 1-5) provide summary information about the system, as follows:
- The first line shows the current time, how long the system has been up, how many users are logged in, and three load averages — the average number of processes ready to run during the last 1, 5, and 15 minutes.
- The second line lists the total number of processes and the status of these processes.
- The third line shows CPU usage — what percentage of CPU time is used by user processes, what percentage by system (kernel) processes, and during what percentage of time the CPU is idle.
- The fourth line shows how the physical memory is being used — the total amount, how much is used, how much is free, and how much is allocated to buffers (for reading from the hard drive, for example).
- The fifth line shows how the virtual memory (or swap space) is being used — the total amount of swap space, how much is used, how much is free, and how much is being cached.
The table that appears below the summary information (refer to Figure 1-5) lists information about the current processes, arranged in decreasing order by amount of CPU time used. Table 1-9 summarizes the meanings of the column headings in the table that top displays.
| Table 1-9 | Column Headings in top Utility’s Output |
| Heading | Meaning |
| PID | Process ID of the process. |
| USER | Username under which the process is running. |
| PR | Priority of the process. |
| NI | Nice value of the process — the value ranges from -20 (highest priority) to 19 (lowest priority) and the default is 0. (The nice value represents the relative priority of the process: The higher the value, the lower the priority and the nicer the process because it yields to other processes.) |
| VIRT | Total amount of virtual memory used by the process, in kilobytes. |
| RES | Total physical memory used by a task (typically shown in kilobytes, but an m suffix indicates megabytes). |
| SHR | Amount of shared memory used by process. |
| S | State of the process (S for sleeping, D for uninterruptible sleep, R for running, Z for zombies — processes that should be dead but are still running — or T for stopped). |
| %CPU | Percentage of CPU time used since last screen update. |
| %MEM | Percentage of physical memory used by the process. |
| TIME+ | Total CPU time the process has used since it started. |
| COMMAND | Shortened form of the command that started the process. |
Using the uptime command
You can use the uptime command to get a summary of the system’s state. Just type the command like this:
uptime
It displays output similar to the following:
15:03:21 up 32 days, 57 min, 3 users, load average: 0.13, 0.23, 0.27 This output shows the current time, how long the system has been up, the number of users, and (finally) the three load averages — the average number of processes that were ready to run in the past 1, 5, and 15 minutes.
Load averages greater than 1 imply that many processes are competing for CPU time simultaneously.
The load averages give you an indication of how busy the system is. Using the vmstat utility
You can get summary information about the overall system usage with the vmstat utility. To view system usage information averaged over 5-second intervals, type the following command (the second argument indicates the total number of lines of output vmstat displays):
vmstat 5 8
You see output similar to the following listing:
procs -----------memory---------- ---swap-- -----io---- --system-- ----cpu---- r b swpd free buff cache si so bi bo in cs us sy id wa
0 0 31324 4016 18568 136004 1 1 17 16 8 110 33 4 61 1
0 1 31324 2520 15348 139692 0 0 7798 199 1157 377 8 8 6 78
1 0 31324 1584 12936 141480 0 19 5784 105 1099 437 12 5 0 82
2 0 31324 1928 13004 137136 7 0 1586 138 1104 561 43 6 0 51
3 1 31324 1484 13148 132064 0 0 1260 51 1080 427 50 5 0 46
0 0 31324 1804 13240 127976 0 0 1126 46 1082 782 19 5 47 30
0 0 31324 1900 13240 127976 0 0 0 0 1010 211 3 1 96 0
0 0 31324 1916 13248 127976 0 0 0 10 1015 224 3 2 95 0
The first line of output shows the averages since the last reboot. After that, vmstat displays the 5-second average data seven more times, covering the next 35 seconds. The tabular output is grouped as six categories of information, indicated by the fields in the first line of output. The second line shows further details for each of the six major fields. You can interpret these fields by using Table 1-10.
| Table 1-10 | Meaning of Fields in the vmstat Utility’s Output |
| Field Name | Description |
| procs | Number of processes and their types: r = processes waiting to run, b = processes in uninterruptible sleep, w = processes swapped out but ready to run. |
| memory | Information about physical memory and swap-space usage (all numbers in kilobytes): swpd = virtual memory used, free = free physical memory, buff = memory used as buffers, cache = virtual memory that’s cached. |
| swap | Amount of swapping (the numbers are in kilobytes per second): si = amount of memory swapped in from disk, so = amount of memory swapped to disk. |
| io | Information about input and output. (The numbers are in blocks per second, where the block size depends on the disk device.) bi = rate of blocks sent to disk, bo = rate of blocks received from disk. |
| system | Information about the system: in = number of interrupts per second (including clock interrupts), cs = number of context switches per second — how many times the kernel changed which process was running. |
| cpu | Percentages of CPU time used: us = percentage of CPU time by user processes, sy = percentage of CPU time used by system processes, id = percentage of time CPU is idle, wa = time spent waiting for input or output (I/O). |
Checking disk performance and disk usage
Linux comes with the /sbin/hdparm program to control IDE or ATAPI hard drives, which are common on most PCs. One feature of the hdparm program is that you can use the -t option to determine the rate at which data is read from the disk into a buffer in memory. For example, here’s the result of typing /sbin/hdparm -t /dev/hda on one system:
/dev/hda: Timing buffered disk reads: 178 MB in 3.03 seconds = 58.81 MB/sec
The command requires the IDE drive’s device name (/dev/hda for the first hard drive and /dev/hdb for the second hard drive) as an argument. If you have an IDE hard drive, you can try this command to see how fast data is read from your system’s disk drive.
To display the space available in the currently mounted file systems, use the df command. If you want a more readable output from df, type the following command:
df -h Here’s a typical output from this command:
Filesystem Size Used Avail Use% Mounted on
/dev/hda5 7.1G 3.9G 2.9G 59% /
/dev/hda3 99M 18M 77M 19% /boot
none 125M 0 125M 0% /dev/shm
/dev/scd0 2.6G 2.6G 0 100% /media/cdrecorder
As this example shows, the -h option causes the df command to display the sizes in gigabytes (G) and megabytes (M).
To check the disk space being used by a specific directory, use the du command — you can specify the -h option to view the output in kilobytes (K) and megabytes (M), as shown in the following example:
du -h /var/log
Here’s a typical output of that command: The du command displays the disk space used by each directory, and the last line shows the total disk space used by that directory. If you want to see only the total space used by a directory, use the -s option. For example, type du -sh /home to see the space used by the /home directory. The command produces output that looks like this:
89M /home
Viewing System Information with the /proc File System
Your Linux system has a special /proc file system. You can find out many things about your system from this file system. In fact, you can even change kernel parameters through the /proc file system (just by writing to a file in that file system), thereby modifying the system’s behavior.
The /proc file system isn’t a real directory on the hard drive but a collection of data structures in memory, managed by the Linux kernel, that appears to you as a set of directories and files. The purpose of /proc (also called the process file system) is to give you access to information about the Linux kernel as well as to help you find out about all processes currently running on your system.
You can access the /proc file system just as you access any other directory, but you have to know the meaning of various files to interpret the information. Typically, you can use the cat or more commands to view the contents of a file in /proc. The file’s contents provide information about some aspect of the system.
As with any directory, start by looking at a detailed directory listing of / proc. To do so, log in as root and type ls -l /proc in a terminal window. In the output, the first set of directories (indicated by the letter d at the beginning of the line) represents the processes currently running on your system. Each directory that corresponds to a process has the process ID (a number) as its name.
Notice also a very large file named /proc/kcore; that file represents the entire physical memory of your system. Although /proc/kcore appears in the listing as a huge file, no single physical file occupies that much space on your hard drive — so don’t try to remove the file to reclaim disk space.
Several files and directories in /proc contain interesting information about your Linux PC. The /proc/cpuinfo file, for example, lists the key characteristics of your system, such as processor type and floating-point processor information. You can view the processor information by typing cat /proc/ cpuinfo. For example, here’s what appears when cat /proc/cpuinfo is run on a sample system:
processor : 0 vendor_id : GenuineIntel
cpu family : 15
model : 3
model name : Intel(R) Celeron(R) CPU 2.53GHz
stepping : 3
cpu MHz : 2533.129
cache size : 256 KB
fdiv_bug : no
hlt_bug : no
f00f_bug : no
coma_bug : no
fpu : yes
fpu_exception : yes
cpuid level : 5
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge
mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss
ht tm pbe pni monitor ds_cpl cid
bogomips : 4997.12
This output is from a 2.5 GHz Celeron system. The listing shows many inter esting characteristics of the processor. Note the line that starts with fdiv_bug. Remember the infamous Pentium floating-point division bug? The bug is in an instruction called fdiv (for floating-point division). Thus, the fdiv_ bug line indicates whether this particular Pentium has the bug.
The last line in the /proc/cpuinfo file shows the BogoMIPS for the processor, as computed by the Linux kernel when it boots. BogoMIPS is something that Linux uses internally to time-delay loops.
Table 1-11 summarizes some of the files in the /proc file system that provide information about your Linux system. You can view some of these files on your system to see what they contain, but note that not all files shown in Table 1-11 are present on your system. The specific contents of the /proc file system depend on the kernel configuration and the driver modules that are loaded (which, in turn, depend on your PC’s hardware configuration).
| Table 1-11 | Some Files and Directories in /proc |
| File Name | Content |
| /proc/acpi | Information about Advanced Configuration and Power Interface (ACPI) — an industry-standard interface for configuration and power management on laptops, desktops, and servers. |
| /proc/bus | Directory with bus-specific information for each bus type, such as PCI. |
| /proc/cmdline | The command line used to start the Linux kernel (for example, ro root=LABEL=/ rhgb). |
| /proc/cpuinfo | Information about the CPU (the microprocessor). |
| /proc/devices | Available block and character devices in your system. |
| /proc/dma | Information about DMA (direct memory access) channels that are used. |
| /proc/driver/rtc | Information about the PC’s real-time clock (RTC). |
| /proc/filesystems | List of supported file systems. |
| /proc/ide | Directory containing information about IDE devices. |
| /proc/interrupts | Information about interrupt request (IRQ) numbers and how they are used. |
| /proc/ioports | Information about input/output (I/O) port addresses and how they’re used. |
| /proc/kcore | Image of the physical memory. |
| /proc/kmsg | Kernel messages. |
| /proc/loadavg | Load average (average number of processes wait- ing to run in the last 1, 5, and 15 minutes). |
| /proc/locks | Current kernel locks (used to ensure that multiple processes don’t write to a file at the same time). |
| /proc/meminfo | Information about physical memory and swap-space usage. |
| /proc/misc | Miscellaneous information. |
| /proc/modules | List of loaded driver modules. |
| /proc/mounts | List of mounted file systems. |
| /proc/net | Directory with many subdirectories that contain information about networking. |
| /proc/partitions | List of partitions known to the Linux kernel. |
| /proc/pci | Information about PCI devices found on the system |
| /proc/scsi | Directory with information about SCSI devices found on the system (present only if you have a SCSI device). |
| /proc/stat | Overall statistics about the system. |
| /proc/swaps | Information about the swap space and how much is used. |
| /proc/sys | Directory with information about the system. You can change kernel parameters by writing to files in this directory. (Using this method to tune system performance requires expertise to do properly.) |
| /proc/uptime | Information about how long the system has been up. |
| /proc/version | Kernel version number. |
You can navigate the /proc file system just as you’d work with any other directories and files in Linux. Use the more or cat commands to view the contents of a file.
next Understanding Linux Devices
0 comments:
Post a Comment