Linux programs ask the kernel to do some things for them. the strace Command reveals these system calls. You can use them to understand how programs work and why sometimes they don’t.

The kernel and system calls

As smart as they may be, computer programs cannot do everything for themselves. They have to make requests to have certain functions performed for them. These requests go to the Linux kernel. Usually there is a library or other software interface that calls the program, and the library then makes the appropriate request – called a system call – to the kernel.

Being able to see a program’s system calls and the responses can help you understand the ins and outs of programs that interest you or that you have written. That is What strace does. It can help troubleshoot problems and check for bottlenecks.

It’s not the same as debug an application with a tool like gdb . You can use a debugging program to examine the internal operation of a program while it is running. You can walk through the logic of your program and check memory and variable values. For comparison, what? strace Collects system call information while the program is running. When the tracked program is terminated, strace lists the system call information in the terminal window.

System calls provide all kinds of low-level functions such as reading and writing to files, killing processes, etc. There is a list of hundreds of system calls on the syscalls man page.

Debugging with GDB: Getting Started

install strace

if strace is not already installed on your computer, you can easily install it.

On Ubuntu, use this command:

sudo apt install strace

on Fedora, enter this command:

sudo dnf install strace

On Manjaro the order is:

sudo pacman -Sy strace

First steps with strace

We’re going to use a small program to demonstrate strace. It doesn’t do much: it opens a file and writes a line of text into it, and it has no error checking in it. It’s just a quick hack so we can use something strace.

#include <stdio.h>

int main(int argc, char argv[]) { 

  // file handle 
  FILE *fileGeek;

  // open a file called "strace_demo.txt", or create it 
  fileGeek = fopen("strace_demo.txt", "w");

  // write some text to the file 
  fprintf(fileGeek, "Write this to the file" );

  // close the file 
  fclose(fileGeek);

  // exit from program 
  return (0); 

} // end of main

We have saved this in a file called “file-io.c” and with. compiled gcc into an executable called stex, named after “NSrun Explenty. “

gcc -o stex file-io.c

We call strace from the command line and pass the name of our new executable as the process we want to track. We could just as easily trace any of the Linux commands or any other binary executable file. We use our little program for two reasons.

The first reason is that strace is detailed. Much can be spent. This is great if you are using strace with anger, but it can be overwhelming at first. It’s limited strace Edition for our little program. The second reason is that our program has limited functionality and the source code is short and straightforward. This makes it easier to see which sections of the output relate to the different parts of the internal workings of the program.

strace ./stex

We can see that clearly write System call sends the text “Write this to the file” to our open file and the exit_group System call. This terminates all threads in the application and sends a return value back to the shell.

Filter the output

Even with our simple demonstration program, there is a lot of output. We can use that -e (Expression) option. We pass in the name of the system call that we want to see.

strace -e write ./stex

You can report on multiple system calls by adding them as a comma-separated list. Do not add spaces to the list of system calls.

strace -e close,write ./stex

Send the output to a file

The benefit of filtering the output is also the problem with filtering the output. You see what you want to see, but you don’t see anything else. And some of those other expenses might be more useful to you than the things you want to see.

Sometimes it’s more convenient to grab everything and browse and scroll through all of the results. This way you don’t accidentally exclude anything important. the -o With the option (Output) you can choose the output of a. send strace Session to a text file.

strace -o trace-output.txt ./stex

You can then use the less Command to scroll through the list and look for system calls – or something else – by name.

less trace-output.txt

You can now use them all lessthe search functions of to examine the output.

How to use the less command on Linux

Adding timestamps

You can add several different timestamps to the output. the -r (Relative Timestamps) option adds timestamps showing the time difference between the start of each successive system call. Note that these time values ​​include the time spent on the previous system call and everything else the program did before the next system call.

strace -r ./stex

The time stamps are displayed at the beginning of each output line.

To see the time spent on each system call, use the -T (System call times) option. This indicates the amount of time that was spent within each system call.

strace -T ./stex

The durations are displayed at the end of each system call line.

To see the time each system call was called, use the -tt (absolute timestamp) option. This shows the time of the “wall clock” with a resolution of microseconds.

strace -tt ./stex

The times are shown at the beginning of each line.

Keeping track of an ongoing process

If the process you want to follow is already running, you can still attach it strace to. To do this, you need to know the process ID. You can use ps with grep to find this. We have Firefox To run. To get the ID of the. to find out firefox Process we can use ps and pipe it through grep.

ps -e | grep firefox

We see that the process ID is 8483. We use that -p (Process id) option to say strace which process should be attached to. Note that you need to use sudo :

sudo strace -p 8483

You will see a notification that strace has attached itself to the process, the system trace calls are displayed as usual in the terminal window.

Create a report

the -c (summary only) Option Causes strace to print a report. It generates a table with information about the system calls made by the tracked program.

strace -c ./stex

The columns are:

• % Time: The percentage of execution time spent on each system call.
• Seconds: The total time in seconds and microseconds that was spent on each system call.
• usecs / call: The average time in microseconds for each system call.
• Calls: The number of times each system call was made.
• failure: The number of errors for each system call.
• System call: The name of the system call.

These values ​​show zeros for trivial programs that run and exit quickly. For programs that do something more useful than our demonstration application, real values ​​are displayed.

Deep insights, very easy

the strace Output can show you which system calls are being made, which are being executed repeatedly, and how much execution time is being spent within the kernel-side code. That’s great information. Often times, when you’re trying to understand what’s going on in your code, you forget that your binary is interacting almost continuously with the kernel to perform many of its functions.

By using strace, you can see the complete picture.

Best Linux Laptops for Developers and Enthusiasts