# The Linux Kernel and Related Matters
As discussed in the introduction what most people mean when the say Linux is actually GNU/Linux. Where, speaking very simplified, GNU provides most commands while the Linux Kernel provides the core operating system. That is process scheduling, hardware abstraction, memory management, networking and similar things.
In a nutshell, the kernel accepts commands and see to them getting executed.
# Special Places under /
# /proc
Directly under the root of your file system / you can find proc which is a
pseudo filesystem that contains information about currently running processes
as well as information on the systems hardware and the current kernel
configuration.
# /dev
Contains your hardware devices. The existence of this directory again underlines a very important aspect of the Linux mindset. Everything is a file! This might seem strange at first, but think about it. Hardware devices can be read from and written to, just like files. This way of thinking enables some quite amazing features and massively simplifies the interaction model. Think about this:
On a properly configured system /dev/dsp is your speaker so doing this
cat /boot/vmlinuz > /dev/dsp
will play the sound of your current kernel.
For /dev there is a naming schema, kind of. However it is completely illogical
in the majority of cases. The documentation is your friend here.
# /sys
Is a rather old directory that has been around since the early days of the
kernel. It contains information and configuration options for hardware devices.
If you think of it as /proc for your /dev you are not far of.
# Process Hierarchy
It might seem obvious by now. Processes in Linux are organized in a tree
structure. After booting the kernel starts /sbin/init and assigns it the
process id of 1. This process in turn spawns all other processes, which in turn
spawn other processes. The spawning process is called parent process, while the
spawned process is called the child process. The process id of the parent is
stored with the meta-information of the child process as PPID.
A visual representation of this tree is available via the pstree command.
# ps
This command lets you view processes running on your system. By default ps
will only show the processes running in the current shell.
Figure out how you can make ps output a tree like structure.
To view all processes on a system you can for example use ps aux. Doing this
can be quite overwhelming, especially on a busy system.
TIP
Try using grep to limit the output to things you are interested in.
One common use-case is listing all processes of a user.
TIP
Find how you can do this without using grep.
# top
top in contrast to ps gives you a dynamic view of processes. It is by
default sorted by CPU usage. There is a huge list of commands that can be used
within top to customize the output. As usual hitting h or ? will display a help
screen.
Here is a short list of the most commonly used configuration shortcuts:
| Key | Meaning |
|---|---|
| P | Sort by CPU usage |
| M | Sort by memory usage |
| R | Toggle sort direction |
| k | Kill a process |
| r | Change (renice) the priority of a process |
top is commonly used to monitor a system and interact with runaway processes.
In addition top will give a nice overview of the total system load in its
first line. This specific information can be also be viewed using uptime or
through the content of /proc/loadavg.
For a nicer and more colorful representation take a look at htop.
# free
By default free will display a snapshot of memory usage. The -s parameter
together with an integer X will refresh the output every X seconds. If the
systems memory is running low, the system will start terminating processes.
Monitoring memory gives you the option of taking action prior to having the OS
take action for you. For more details check the out-of-memory-killer
implementation and configuration currently in use by your system.
# Log Files
Log files are most often found in /var/log but the way they get there can
vary. Some processes log on their own while others delegate this work to another
process. These logging daemons vary from distribution to distribution but always
serve the same function, taking messages and writing them to a log.
Example logging daemons include:
- syslogd
- klogd
- rsyslogd
- systemd-journald
- and many others
Lets check some common log files and what they contain:
| File | Content |
|---|---|
| secure | Messages from processes the require authentication of authorization |
| boot.log | Messages that where emitted during startup |
| cron | Messages from the systems job scheduler |
| dmesg | Messages from the kernel during boot |
| Xorg.0.log | Logs from the X-Window-Server (GUI) |
| messages | Messages that do not fit anywhere else |
| syslog | Alternate name for messages in some systems |
Log files are usually rotated at regular intervals or based on amount of data in the file. For the files mentioned above the rotation is usually time based and the older files are either suffixed with an integer or a date/timestamp. How many of these old log files are kept around depends on the logging daemon and your configuration.
Most log files contain text but some contain binary. You can use the file
command to figure out which are which or you can just try opening them with an
editor and see if it works. For binary log files there is usually a tool around
that makes them readable. One example is /var/log/btmp which can be viewed
with lastb.
TIP
Now go and find another such pair.
# dmesg
As mentioned /var/log/dmesg contains kernel messages produced during system
startup while kernel message emitted during runtime are found in
/var/log/messages be default. Be aware that they are mixed in with logs from
other sources. This can be changed in the configuration file of your syslog
daemon.
TIP
Go and try this now.
The dmesg command will display the kernel ring buffer which can hold a large
number of messages. The exact size of this buffer is set at kernel compile time
and can therefore not be changed trivially.
Filtering the output of dmesg through
something else might be advisable depending on its size.
TIP
Think of at least two commands you could use to make the output more readable.