Linux programs ask the kernel to do some things for them. the strace The command reveals these system calls. You can use them to understand how programs work and why, sometimes, They do not do it.
The kernel and system calls
No matter how smart they are, computer programs cannot do everything by themselves. They need to make requests for certain functions to be performed. These requests go to the Linux kernel. As usual, there is a library or other software interface that the program calls, and then the library makes the appropriate request, call system call, al kernel.
Being able to see the system calls a program has made and what the responses were can help you understand the inner workings of programs that interest you or that you have written.. This is that strace does it. Can help fix problems and find bottlenecks.
This is not the same as debug an application with a tool like gdb . A debugging program enables you to investigate the inner workings of a program while it is running. Enables you to step through your program logic and inspect memory and variable values. Compared, that strace what it does is capture the information of the system call while the program is running. When the tracked program ends, strace lists the system call information in the terminal window.
System calls provide all kinds of low-level functions, as read and write actions on files, process elimination, etc. There is a list of hundreds of system calls in the syscalls man page.
RELATED: Debugging with GDB: introduction
Strace installation
And strace not installed on your computer yet, you can install it very easily.
In Ubuntu, use this command:
sudo apt install strace
In Fedora, write this command:
sudo dnf install strace
In Manjaro, the command is:
sudo pacman -Sy strace
First steps with strace
We will use a small program to demonstrate strace. Not a long time ago: open a file and write a line of text to it, and you don't have any error when checking it. It's just a quick trick so we have something to use with. 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 save this in a file called “file-io.c” and we compile it with gcc in an executable named stex, appointed to “S trace exbroad.”
gcc -o stex file-io.c
Call strace from the command line and pass it the name of our new executable as the procedure we want to trace. We could easily trace any of the Linux commands or any other binary executable. We are using our little program for two reasons.
The first reason is that strace it is verbose. There can be many results. That is great when you are using strace pissed off, but it can be overwhelming at first. There are limited strace departure for our little program. The second reason is that our program has limited functionality and the source code is short and simple.. This makes it easier to identify which sections of the output refer to different parts of the internal workings of the program..
strace ./stex
We can clearly see the write system call sending the text “Write this to the file” to our open archive and the exit_group system call. This terminates all threads in the application and sends a return value to the shell.
Filter the output
Even with our simple demo program, there is enough exit. We can use the -e Option (expression). We will pass the name of the system call that we want to see.
strace -e write ./stex
You can report multiple system calls by adding them as a comma separated list. Do not include any blank space in 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 of filtering the output. You see what you asked to see, but you don't see anything else. And some of those other results may be more useful to you than the things you've asked to see..
Sometimes, it is more convenient to capture everything and search and scroll through the entire result set. That way, won't accidentally exclude anything important. the -o The option (Exit) enables you to send output from a strace session to a text file.
strace -o trace-output.txt ./stex
Then, you can use the less command to scroll through the list and find system calls, or any other thing, by name.
less trace-output.txt
You can now use all lesssearch capabilities to investigate the exit.
RELATED: How to use the less command in Linux
Add timestamps
You can add several different timestamps to the output. the -r The option (relative timestamps) adds timestamps showing the time difference between the start of each successive system call. Note that these time values will include the time spent on the previous system call and whatever else the program was doing before the next system call..
strace -r ./stex
Timestamps are displayed at the beginning of each start line.
To see the amount of time spent on each system call, use el -T (syscall-times) option. This shows the length of time elapsed within each system call.
strace -T ./stex
Time durations are displayed at the end of each system call appearance.
To see the time each system call was called, Use the -tt (absolute timestamps). This shows the time of the “wall clock”, with microseconds resolution.
strace -tt ./stex
Times are shown at the beginning of each line.
Follow-up of a running procedure
If the procedure you want to trace is already running, can still attach strace it. To do it, you need to know the procedure ID. You can use ps with grep to find this. We have Firefox running. To find out the ID of the firefox process, we can use ps and channel it through grep.
ps -e | grep firefox
We can see that the procedure ID is 8483. We will use the -p (Procedure ID) option to say strace which procedure to attach to. Please note that you will need to use sudo :
sudo strace -p 8483
You will see a notification that strace has been attached to the procedure, and then the system trace calls will show up in the terminal window as usual.
Create a report
the -c (just summary) option causes strace to print a report. Generates a table to get information about the system calls made by the tracked program.
strace -c ./stex
The columns are:
- % weather: The percentage of execution time that was spent on each system call.
- seconds: The total time in seconds and microseconds for each system call.
- usecs / call: The average time in microseconds spent on each system call.
- calls: The number of times each system call was executed.
- mistakes: The number of failures for each system call.
- syscall: The name of the system call.
These values will show zeros for trivial programs that run and terminate quickly. Real world values are displayed for programs that do something more meaningful than our demo application.
Deep insights, easily
the strace The output can show you what system calls are being made, which ones are done repeatedly and how much execution time is being spent inside the kernel-side code. That's great information. Often, when you try to understand what is going on inside your code, it's easy to forget that your binary is interacting almost non-stop with the kernel to perform many of its functions.
Through use strace, you see the whole picture.
