{"id":613,"date":"2025-04-10T04:00:36","date_gmt":"2025-04-10T04:00:36","guid":{"rendered":"https:\/\/blog.ngocha.biz\/?p=613"},"modified":"2025-04-10T04:00:36","modified_gmt":"2025-04-10T04:00:36","slug":"linux-syscall","status":"publish","type":"post","link":"https:\/\/blog.ngocha.biz\/?p=613","title":{"rendered":"Linux Syscall Explained For Beginners"},"content":{"rendered":"

In this blog, we will look into Linux System Calls<\/strong>, frequently discussed in DevOps and SRE interviews, especially in top product companies.<\/p>\n

Not everyone in DevOps gets to work with system internals or troubleshoot performance issues daily.<\/p>\n

Even in my 12+ years of DevOps career, I spent 80% of the time in design and implementation and 20% in troubleshooting issues.<\/p>\n

It totally depends on the job nature and the projects you choose to work on.<\/p>\n

However, it is very important for DevOps\/SRE folks to have a strong understanding of system troubleshooting because we usually work with servers.<\/p>\n

Syscall is a foundational concept in this regard.<\/p>\n

When you appear for DevOps\/SRE interviews, you can expect questions related to syscalls<\/p>\n

To get started, we need to be clear on a few basics.<\/p>\n

Kernel Space<\/h2>\n

This is where the core of the operating system, the kernel, operates.<\/p>\n

As per Wikipedia,<\/p>\n

A kernel<\/strong> is a computer program at the core of a computer’s operating system that constantly has complete control over everything in the system (Wikipedia).<\/p><\/blockquote>\n

The kernel controls everything: memory, processes, hardware, drivers, security, and more.<\/strong><\/p>\n

Also, it <\/strong>directly interacts with the CPU, RAM, disk, and other hardware and has unrestricted access to all system resources.<\/p>\n

Userspace<\/h2>\n

This is the environment where user facing applications run<\/strong> (Web servers, Chrome, Text editors, command utilities etc).<\/p>\n

It is like a restricted zone<\/strong> because it can\u2019t directly access hardware or manage system resources.<\/p>\n

That is why usually if an application crashes, it doesn\u2019t crash the whole OS.<\/p>\n

Syscall (System Calls)<\/h2>\n

The programs in Userspace<\/strong> need Kernel Space<\/strong> to access system resources.<\/p>\n

This communication is handled via System Calls (Syscalls).<\/p>\n

In this communication the Kernel acts as a middleman<\/strong>, making sure userspace programs don\u2019t mess up the system.<\/strong><\/p>\n

\"\"<\/figure>\n
\n
\ud83d\udca1<\/div>\n
System calls are part of the kernel<\/strong><\/b>. They are implemented as functions in the kernel space<\/strong><\/b>, and user programs can access them using specific instructions or libraries (like the C library, glibc<\/code>).<\/div>\n<\/div>\n

Practical Example: The ls Command<\/h2>\n

To better understand the interaction between user space and kernel space, let’s consider a real-world example using the simple Linux ls<\/code> command.<\/p>\n

ls<\/code> is a userspace utility that lists directory contents.<\/p>\n

Every time you type ls<\/code> to list files, your system is secretly making dozens of syscalls<\/strong> to communicate with the Kernel.<\/p>\n

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

\"\"<\/figure>\n

Types of System Calls<\/h2>\n

Now, let’s look at the types of system calls.<\/p>\n

\n
\ud83d\udca1<\/div>\n
The system call functions given below are C library functions<\/strong><\/b>, but they are wrappers around system calls<\/strong><\/b> provided by the operating system<\/p>\n

These functions internally invoke Linux system calls<\/strong><\/b> to interact with the kernel.<\/div>\n<\/div>\n

1. Process Control<\/h4>\n

To manage processes (creation, termination, execution).<\/p>\n

    \n
  1. fork()<\/code>: Create a new process.<\/li>\n
  2. exec()<\/code>: Replace the current process with a new program.<\/li>\n
  3. exit()<\/code>: Terminate a process.<\/li>\n
  4. wait()<\/code>: Pause until a child process finishes.<\/li>\n
  5. kill()<\/code>: Send signals to processes (e.g., terminate or pause).<\/li>\n<\/ol>\n
    \n
    fork()<\/code> vs exec()<\/code> system call is one of the popular interview questions.<\/div>\n<\/div>\n

    2. File Management<\/h3>\n

    To handle file operations (read, write, modify metadata).<\/p>\n

      \n
    • open()<\/code>: Open a file for reading\/writing.<\/li>\n
    • close()<\/code>: Release access to a file.<\/li>\n
    • read()<\/code>: Read data from a file.<\/li>\n
    • write()<\/code>: Write data to a file.<\/li>\n
    • unlink()<\/code>: Delete a file.<\/li>\n
    • chmod()<\/code>: Change file permissions.<\/li>\n<\/ul>\n

      3. Device Management<\/h3>\n

      To control hardware devices (treated as files in Unix-like systems).<\/p>\n

        \n
      • ioctl()<\/code>: Configure device-specific operations.<\/li>\n
      • read()<\/code>: Read data from a device.<\/li>\n
      • write()<\/code>: Write data to a device.<\/li>\n<\/ul>\n

        4. Information Maintenance<\/h3>\n

        To get or set system\/process data.<\/p>\n

          \n
        • getpid()<\/code>: Retrieve the current process ID.<\/li>\n
        • time()<\/code>: Fetch system time.<\/li>\n
        • sysinfo()<\/code>: Check system resource usage.<\/li>\n
        • setpriority()<\/code>: Adjust process scheduling priority.<\/li>\n<\/ul>\n

          5. Communication (IPC)<\/h3>\n

          To enable inter-process communication (IPC) or networking.<\/p>\n

            \n
          • pipe()<\/code>: Create a unidirectional data channel.<\/li>\n
          • shmget()<\/code>: Allocate shared memory.<\/li>\n
          • socket()<\/code>: Establish network communication.<\/li>\n
          • send()<\/code>: Transfer data over a network.<\/li>\n
          • recv()<\/code>: Receive data over a network.<\/li>\n<\/ul>\n

            Conclusion<\/h2>\n

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

            However, understanding syscalls can be helpful to in roles like DevOps, SRE, and backend engineering<\/strong> when troubleshooting performance issues, debugging applications, etc.<\/p>\n

            If you have any doubts about this blog, drop it on the comment!<\/p>\n

            Want to Stay Ahead in DevOps & Cloud? Join the Free Newsletter Below.<\/p>\n


            \n