Linux System Calls Explained For Beginners

In this blog, we will look into Linux System Calls, 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 usually work with servers.

Syscall is a foundational concept in this regard.

When you appear for DevOps/SRE interviews, you can expect questions related to syscalls

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

Kernel Space

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

As per Wikipedia,

A kernel is a computer program at the core of a computer's operating system that constantly has complete control over everything in the system (Wikipedia).

The 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 (System Calls)

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, let's 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.

Conclusion

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 helpful to in roles like DevOps, SRE, and backend engineering when troubleshooting performance issues, debugging applications, etc.

If you have any doubts about this blog, drop it on the comment!