Linux Syscalls Explained

👋 Hi! I’m Bibin Wilson. In each edition, I share practical tips, guides, and the latest trends in DevOps and MLOps to make your day-to-day DevOps tasks more efficient. If someone forwarded this email to you, you can subscribe here to never miss out!

In this edition, we will explore a concept frequently discussed in DevOps and SRE interviews, especially in top product companies.

Not everyone in DevOps gets to work with system internals or troubleshoot performance issues daily.

Even in my 12+ years of DevOps career, I spent 80% of the time in design and implementation and 20% in troubleshooting issues.

It totally depends on the job nature and the projects you choose to work on.

However, it is very important for DevOps/SRE folks to have a strong understanding of system troubleshooting because we work with servers most of the time.

Syscall is a foundational concept in this regard.

To get started, we need to be clear on few basics.

Kernel Space

This is where the core of the operating system, the kernel, operates.

As per wikipedia,

Kernel controls everything: memory, processes, hardware, drivers, security, and more.

Also, it directly interacts with the CPU, RAM, disk, and other hardware and has unrestricted access to all system resources.

Userspace

This is the environment where user facing applications run (Web servers, Chrome, Text editors, command utilities etc).

It is like a restricted zone because it can’t directly access hardware or manage system resources.

That is why usually, if an application crashes, it doesn’t crash the whole OS.

Syscall

The programs in Userspace need Kernel Space to access system resources.

This communication is handled via System Calls (Syscalls).

In this communication the Kernel acts as a middleman, making sure userspace programs don’t mess up the system.

Practical Example: The ls Command

To better understand the interaction between user space and kernel space, let's consider a real-world example using the simple Linux ls command.

ls is a userspace utility that lists directory contents.

Every time you type ls to list files, your system is secretly making dozens of syscalls to communicate with the Kernel.

The following illustration gives you an idea of how all these interactions happen, from the user to the system hardware (disk) through the kernel.

Types of System Calls

Now, lets look at the types of system calls.

1. Process Control

To manage processes (creation, termination, execution).

1. fork(): Create a new process.

2. exec(): Replace the current process with a new program.

3. exit(): Terminate a process.

4. wait(): Pause until a child process finishes.

5. kill(): Send signals to processes (e.g., terminate or pause).

2. File Management

To handle file operations (read, write, modify metadata).

• open(): Open a file for reading/writing.

• close(): Release access to a file.

• read(): Read data from a file.

• write(): Write data to a file.

• unlink(): Delete a file.

• chmod(): Change file permissions.

3. Device Management

To control hardware devices (treated as files in Unix-like systems).

• ioctl(): Configure device-specific operations.

• read(): Read data from a device.

• write(): Write data to a device.

4. Information Maintenance

To get or set system/process data.

• getpid(): Retrieve the current process ID.

• time(): Fetch system time.

• sysinfo(): Check system resource usage.

• setpriority(): Adjust process scheduling priority.

5. Communication (IPC)

To enable inter-process communication (IPC) or networking.

• pipe(): Create a unidirectional data channel.

• shmget(): Allocate shared memory.

• socket(): Establish network communication.

• send(): Transfer data over a network.

• recv(): Receive data over a network.

Wrapping Up

Using syscalls in day-to-day work is very rare unless you work with low-level system programming, kernel development, performance tuning etc.

However, understanding syscalls can be useful in roles like DevOps, SRE, and backend engineering when troubleshooting performance issues, debugging applications etc.

For example, in tomorrows edition we will look at how to trace syscalls to debug application issues.