Strace linux как пользоваться

strace -c[df] [-In] [-bexecve] [-eexpr]. [-Ooverhead] [-Ssortby] -ppid. / [-D] [-Evar[=val]]. [-uusername] command [args]

DESCRIPTION

In the simplest case strace runs the specified command until it exits. It intercepts and records the system calls which are called by a process and the signals which are received by a process. The name of each system call, its arguments and its return value are printed on standard error or to the file specified with the -o option.

strace is a useful diagnostic, instructional, and debugging tool. System administrators, diagnosticians and trouble-shooters will find it invaluable for solving problems with programs for which the source is not readily available since they do not need to be recompiled in order to trace them. Students, hackers and the overly-curious will find that a great deal can be learned about a system and its system calls by tracing even ordinary programs. And programmers will find that since system calls and signals are events that happen at the user/kernel interface, a close examination of this boundary is very useful for bug isolation, sanity checking and attempting to capture race conditions.

Each line in the trace contains the system call name, followed by its arguments in parentheses and its return value. An example from stracing the command «cat /dev/null» is:

Errors (typically a return value of -1) have the errno symbol and error string appended.

Signals are printed as signal symbol and decoded siginfo structure. An excerpt from stracing and interrupting the command «sleep 666» is:

If a system call is being executed and meanwhile another one is being called from a different thread/process then strace will try to preserve the order of those events and mark the ongoing call as being unfinished. When the call returns it will be marked as resumed.

Interruption of a (restartable) system call by a signal delivery is processed differently as kernel terminates the system call and also arranges its immediate reexecution after the signal handler completes.

Arguments are printed in symbolic form with a passion. This example shows the shell performing «>>xyzzy» output redirection:

Here the third argument of open is decoded by breaking down the flag argument into its three bitwise-OR constituents and printing the mode value in octal by tradition. Where traditional or native usage differs from ANSI or POSIX, the latter forms are preferred. In some cases, strace output has proven to be more readable than the source.

Structure pointers are dereferenced and the members are displayed as appropriate. In all cases arguments are formatted in the most C-like fashion possible. For example, the essence of the command «ls -l /dev/null» is captured as:

Notice how the ‘struct stat’ argument is dereferenced and how each member is displayed symbolically. In particular, observe how the st_mode member is carefully decoded into a bitwise-OR of symbolic and numeric values. Also notice in this example that the first argument to lstat is an input to the system call and the second argument is an output. Since output arguments are not modified if the system call fails, arguments may not always be dereferenced. For example, retrying the «ls -l» example with a non-existent file produces the following line:

In this case the porch light is on but nobody is home.

Character pointers are dereferenced and printed as C strings. Non-printing characters in strings are normally represented by ordinary C escape codes. Only the first strsize (32 by default) bytes of strings are printed; longer strings have an ellipsis appended following the closing quote. Here is a line from «ls -l» where the getpwuid library routine is reading the password file:

While structures are annotated using curly braces, simple pointers and arrays are printed using square brackets with commas separating elements. Here is an example from the command «id» on a system with supplementary group ids:

On the other hand, bit-sets are also shown using square brackets but set elements are separated only by a space. Here is the shell preparing to execute an external command:

Here the second argument is a bit-set of two signals, SIGCHLD and SIGTTOU. In some cases the bit-set is so full that printing out the unset elements is more valuable. In that case, the bit-set is prefixed by a tilde like this:

Here the second argument represents the full set of all signals.

OPTIONS

DIAGNOSTICS

When using -p, the exit status of strace is zero unless there was an unexpected error in doing the tracing.

SETUID INSTALLATION

NOTES

It is instructive to think about system call inputs and outputs as data-flow across the user/kernel boundary. Because user-space and kernel-space are separate and address-protected, it is sometimes possible to make deductive inferences about process behavior using inputs and outputs as propositions.

In some cases, a system call will differ from the documented behavior or have a different name. For example, on System V-derived systems the true time(2) system call does not take an argument and the stat function is called xstat and takes an extra leading argument. These discrepancies are normal but idiosyncratic characteristics of the system call interface and are accounted for by C library wrapper functions.

Some system calls have different names in different architectures and personalities. In these cases, system call filtering and printing uses the names that match corresponding __NR_* kernel macros of the tracee’s architecture and personality. There are two exceptions from this general rule: arm_fadvise64_64(2) ARM syscall and xtensa_fadvise64_64(2) Xtensa syscall are filtered and printed as fadvise64_64(2).

On some platforms a process that is attached to with the -p option may observe a spurious EINTR return from the current system call that is not restartable. (Ideally, all system calls should be restarted on strace attach, making the attach invisible to the traced process, but a few system calls aren’t. Arguably, every instance of such behavior is a kernel bug.) This may have an unpredictable effect on the process if the process takes no action to restart the system call.

A traced process runs slowly.

Traced processes which are descended from command may be left running after an interrupt signal ( CTRL -C).

[OS] Наблюдение за процессами при помощи strace

Привет, %username% ! Поговорим о такой болезни как вуайеризм. Подглядывать мы будем за процессами в Linux, а использовать для столь интимного дела мы будем утилиту strace .

Что это и чем его едят#

strace — это утилита, присутствующая во многих дистрибутивах Linux по умолчанию, которая может использоваться в диагностических, учебных или отладочных целях. При помощи strace вы иной раз можете избавить себя от лишней головной боли, когда необходимо отыскать причину возникающего сбоя, при этом не имея доступа к исходным кодам. Помимо этого, strace может использоваться при отправке багрепортов разработчикам. Используя этот инструмент вы сможете воочию увидеть, что делает программа.

strace — это бесплатная утилита, распространяемая под BSD-лицензией. Изначально она была написана Paul Kranenburg для SunOS и называлась trace . Затем усилиями Branko Lankester она была портирована на Linux, включая поддержку специфики Linux-ядра. Затем, в 1993 году, версии strace для SunOS и Linux были объединены в одну, был добавлен некоторый функционал truss из SVR4 . В итоге получившийся винегрет назвали strace , который теперь работает на многих UNIX-платформах. Сегодня разработкой утилиты занимаются Wichert Akkerman и Roland McGrath .

В самом простом варианте strace запускает переданную команду с её аргументами и выводит в стандартный поток ошибок все системные вызовы команды. Давайте разберём опции утилиты, с помощью которых можно управлять её поведением:

-i — выводить указатель на инструкцию во время выполнения системного вызова;
-k — выводить стек вызовов для отслеживаемого процесса после каждого системного вызова;
-o — выводить всю информацию о системных вызовах не в стандартный поток ошибок, а в файл;
-q — не выводить сообщения о подключении о отключении от процесса;
-qq — не выводить сообщения о завершении работы процесса;
-r — выводить временную метку для каждого системного вызова;
-s — указать максимальный размер выводимой строки, по умолчанию 32;
-t — выводить время суток для каждого вызова;
-tt — добавить микросекунды;
-ttt — добавить микросекунды и количество секунд после начала эпохи Unix;
-T — выводить длительность выполнения системного вызова;
-x — выводить все не ASCI-строки в шестнадцатеричном виде;
-xx — выводить все строки в шестнадцатеричном виде;
-y — выводить пути для файловых дескрипторов;
-yy — выводить информацию о протоколе для файловых дескрипторов;
-c — подсчитывать количество ошибок, вызовов и время выполнения для каждого системного вызова;
-O — добавить определённое количество микросекунд к счетчику времени для каждого вызова;
-S — сортировать информацию выводимую при опции -c . Доступны поля time , calls , name и nothing . По умолчанию используется time ;
-w — суммировать время между началом и завершением системного вызова;
-e — позволяет отфильтровать только нужные системные вызовы или события;
-P — отслеживать только системные вызовы, которые касаются указанного пути;
-v — позволяет выводить дополнительную информацию, такую как версии окружения, статистику и так далее;
-b — если указанный системный вызов обнаружен, трассировка прекращается;
-f — отслеживать также дочерние процессы, если они будут созданы;
-ff — если задана опция -o , то для каждого дочернего процесса будет создан отдельный файл с именем имя_файла.pid .
-I — позволяет блокировать реакцию на нажатия Ctrl+C и Ctrl+Z ;
-E — добавляет переменную окружения для запускаемой программы;
-p — указывает pid процесса, к которому следует подключиться;
-u — запустить программу, от имени указанного пользователя.

Вы знаете основные опции strace , но чтобы полноценно ею пользоваться, нужно ещё разобраться с системными вызовами, которые используются чаще всего. Мы не будем рассматривать все, а только основные. Многие из них вы уже и так знаете, потому что они называются так же, как и команды в терминале:

fork — создание нового дочернего процесса;
read — попытка читать из файлового дескриптора;
write — попытка записи в файловый дескриптор;
open — открыть файл для чтения или записи;
close — закрыть файл после чтения или записи;
chdir — изменить текущую директорию;
execve — выполнить исполняемый файл;
stat — получить информацию о файле;
mknod — создать специальный файл, например, файл устройства или сокет;

А теперь разберём примеры strace Linux.

Запуск#

Системный вызов — это своего рода «обращение» программы к ядру ОС с просьбой выполнить то или иное действие. Необходимость в таких вызовах обусловлена тем, что процессы не могут напрямую взаимодействовать с системой (представьте, что было бы, если бы каждая программа, например, выделяла себе сколько угодно памяти или могла читать и писать какие угодно файлы!).

Работа strace заключается в отслеживании того, какие системные вызовы делает указанный процесс, а также какие сигналы он получает. Вообще, возможна ситуация, когда процесс не делает ни одного системного вызова. В этом случае, естественно, strace вам ничего не “отследит”.

В общем случае запуск strace выглядит так:

Утилита запустит программу program_name и будет выводить в поток стандартного вывода сообщения о выполняемых системных вызовах. Зачастую засорение стандартного вывода сообщениями трассировки нежелательно, поскольку в нём будет трудно отыскать то, что выводит сам процесс, поэтому лучше перенаправить вывод strace в отдельный файл, который потом анализировать:

Некоторые текстовые редакторы, например Vim , имеют цветовую подсветку вывода strace , что значительно помогает при анализе больших файлов с текстами трассировки.

Ещё, как вариант, можно запускать strace для трассировки уже запущенного процесса. Для этого необходимо знать PID нужного процесса и передать его в качестве параметра опции -p утилиты:

Анализ вывода#

Предлагаю попробовать запустить что-нибудь и поглазеть, как strace ведёт себя в реальной жизни. Возьмём одну из наиболее часто используемых программ и посмотрим, что же она делает “за кулисами”.

Вывод файла достаточно велик, поэтому здесь не выкладываю. Думаю, кому интересно, сами попробуют на своей системе. Рассмотрим лишь несколько строк в качестве примера.

Структура каждой строки вывода strace следующая. Первым идёт имя системного вызова. Затем в круглых скобках выводится список параметров, переданных вызову. И последним, после знака равенства, отображается код завершения системного вызова. Подробную документацию по каждому системному вызову в случае необходимости можно найти на соответствующих man-страницах второго раздела.

Резюме#

strace может оказаться (и оказывается!) весьма полезной утилитой как для программистов, так и для системных администраторов, помогая отыскать причины “падений” или некорректной работы программ с закрытыми или недоступными исходными кодами.

Если у тебя есть вопросы, комментарии и/или замечания – заходи в чат, а так же подписывайся на канал.

DESCRIPTION

Each line in the trace contains the system call name, followed by its arguments in parentheses and its return value. An example from stracing the command "cat /dev/null" is:

Errors (typically a return value of -1) have the errno symbol and error string appended.

Signals are printed as signal symbol and decoded siginfo structure. An excerpt from stracing and interrupting the command "sleep 666" is:

Arguments are printed in symbolic form with passion. This example shows the shell performing ">>xyzzy" output redirection:

Here, the second and the third argument of open(2) are decoded by breaking down the flag argument into its three bitwise-OR constituents and printing the mode value in octal by tradition. Where the traditional or native usage differs from ANSI or POSIX, the latter forms are preferred. In some cases, strace output is proven to be more readable than the source.

Structure pointers are dereferenced and the members are displayed as appropriate. In most cases, arguments are formatted in the most C-like fashion possible. For example, the essence of the command "ls -l /dev/null" is captured as:

Notice how the ‘struct stat’ argument is dereferenced and how each member is displayed symbolically. In particular, observe how the st_mode member is carefully decoded into a bitwise-OR of symbolic and numeric values. Also notice in this example that the first argument to lstat(2) is an input to the system call and the second argument is an output. Since output arguments are not modified if the system call fails, arguments may not always be dereferenced. For example, retrying the "ls -l" example with a non-existent file produces the following line:

In this case the porch light is on but nobody is home.

Syscalls unknown to strace are printed raw, with the unknown system call number printed in hexadecimal form and prefixed with "syscall_":

Character pointers are dereferenced and printed as C strings. Non-printing characters in strings are normally represented by ordinary C escape codes. Only the first strsize (32 by default) bytes of strings are printed; longer strings have an ellipsis appended following the closing quote. Here is a line from "ls -l" where the getpwuid(3) library routine is reading the password file:

While structures are annotated using curly braces, pointers to basic types and arrays are printed using square brackets with commas separating the elements. Here is an example from the command id(1) on a system with supplementary group ids:

On the other hand, bit-sets are also shown using square brackets, but set elements are separated only by a space. Here is the shell, preparing to execute an external command:

Here, the second argument is a bit-set of two signals, SIGCHLD and SIGTTOU. In some cases, the bit-set is so full that printing out the unset elements is more valuable. In that case, the bit-set is prefixed by a tilde like this:

Here, the second argument represents the full set of all signals.

OPTIONS

General

Startup

Tracing

Filtering

set can include the following elements:

Output format

Statistics

Tampering

Miscellaneous

Time specification format description

Time values can be specified as a decimal floating point number (in a format accepted by strtod(3)), optionally followed by one of the following suffices that specify the unit of time: s (seconds), ms (milliseconds), us (microseconds), or ns (nanoseconds). If no suffix is specified, the value is interpreted as microseconds.

The described format is used for -O, -e inject=delay_enter, and -e inject=delay_exit options.

DIAGNOSTICS

When command exits, strace exits with the same exit status. If command is terminated by a signal, strace terminates itself with the same signal, so that strace can be used as a wrapper process transparent to the invoking parent process. Note that parent-child relationship (signal stop notifications, getppid(2) value, etc) between traced process and its parent are not preserved unless -D is used.

When using -p without a command, the exit status of strace is zero unless no processes has been attached or there was an unexpected error in doing the tracing.

SETUID INSTALLATION

If strace is installed setuid to root then the invoking user will be able to attach to and trace processes owned by any user. In addition setuid and setgid programs will be executed and traced with the correct effective privileges. Since only users trusted with full root privileges should be allowed to do these things, it only makes sense to install strace as setuid to root when the users who can execute it are restricted to those users who have this trust. For example, it makes sense to install a special version of strace with mode ‘rwsr-xr—‘, user root and group trace, where members of the trace group are trusted users. If you do use this feature, please remember to install a regular non-setuid version of strace for ordinary users to use.

MULTIPLE PERSONALITIES SUPPORT

On some architectures, strace supports decoding of syscalls for processes that use different ABI rather than the one strace uses. Specifically, in addition to decoding native ABI, strace can decode the following ABIs on the following architectures:

Architecture	ABIs supported
x86_64	i386, x32 [1]; i386 [2]
AArch64	ARM 32-bit EABI
PowerPC 64-bit [3]	PowerPC 32-bit
s390x	s390
SPARC 64-bit	SPARC 32-bit
TILE 64-bit	TILE 32-bit

This support is optional and relies on ability to generate and parse structure definitions during the build time. Please refer to the output of the strace -V command in order to figure out what support is available in your strace build ("non-native" refers to an ABI that differs from the ABI strace has):

m32-mpers strace can trace and properly decode non-native 32-bit binaries. no-m32-mpers strace can trace, but cannot properly decode non-native 32-bit binaries. mx32-mpers strace can trace and properly decode non-native 32-on-64-bit binaries. no-mx32-mpers strace can trace, but cannot properly decode non-native 32-on-64-bit binaries.

If the output contains neither m32-mpers nor no-m32-mpers, then decoding of non-native 32-bit binaries is not implemented at all or not applicable.

Likewise, if the output contains neither mx32-mpers nor no-mx32-mpers, then decoding of non-native 32-on-64-bit binaries is not implemented at all or not applicable.

NOTES

It is a pity that so much tracing clutter is produced by systems employing shared libraries.

In some cases, a system call will differ from the documented behavior or have a different name. For example, the faccessat(2) system call does not have flags argument, and the setrlimit(2) library function uses prlimit64(2) system call on modern (2.6.38+) kernels. These discrepancies are normal but idiosyncratic characteristics of the system call interface and are accounted for by C library wrapper functions.

Some system calls have different names in different architectures and personalities. In these cases, system call filtering and printing uses the names that match corresponding __NR_* kernel macros of the tracee’s architecture and personality. There are two exceptions from this general rule: arm_fadvise64_64(2) ARM syscall and xtensa_fadvise64_64(2) Xtensa syscall are filtered and printed as fadvise64_64(2).

On x32, syscalls that are intended to be used by 64-bit processes and not x32 ones (for example, readv(2), that has syscall number 19 on x86_64, with its x32 counterpart has syscall number 515), but called with __X32_SYSCALL_BIT flag being set, are designated with #64 suffix.

On some platforms a process that is attached to with the -p option may observe a spurious EINTR return from the current system call that is not restartable. (Ideally, all system calls should be restarted on strace attach, making the attach invisible to the traced process, but a few system calls aren’t. Arguably, every instance of such behavior is a kernel bug.) This may have an unpredictable effect on the process if the process takes no action to restart the system call.

As strace executes the specified command directly and does not employ a shell for that, scripts without shebang that usually run just fine when invoked by shell fail to execute with ENOEXEC error. It is advisable to manually supply a shell as a command with the script as its argument.

Programs that use the setuid bit do not have effective user ID privileges while being traced.

A traced process runs slowly (but check out the —seccomp-bpf option).

Traced processes which are descended from command may be left running after an interrupt signal (CTRL-C).

HISTORY

The original strace was written by Paul Kranenburg for SunOS and was inspired by its trace utility. The SunOS version of strace was ported to Linux and enhanced by Branko Lankester, who also wrote the Linux kernel support. Even though Paul released strace 2.5 in 1992, Branko’s work was based on Paul’s strace 1.5 release from 1991. In 1993, Rick Sladkey merged strace 2.5 for SunOS and the second release of strace for Linux, added many of the features of truss(1) from SVR4, and produced an strace that worked on both platforms. In 1994 Rick ported strace to SVR4 and Solaris and wrote the automatic configuration support. In 1995 he ported strace to Irix and became tired of writing about himself in the third person.

Beginning with 1996, strace was maintained by Wichert Akkerman. During his tenure, strace development migrated to CVS; ports to FreeBSD and many architectures on Linux (including ARM, IA-64, MIPS, PA-RISC, PowerPC, s390, SPARC) were introduced. In 2002, the burden of strace maintainership was transferred to Roland McGrath. Since then, strace gained support for several new Linux architectures (AMD64, s390x, SuperH), bi-architecture support for some of them, and received numerous additions and improvements in syscalls decoders on Linux; strace development migrated to Git during that period. Since 2009, strace is actively maintained by Dmitry Levin. strace gained support for AArch64, ARC, AVR32, Blackfin, Meta, Nios II, OpenRISC 1000, RISC-V, Tile/TileGx, Xtensa architectures since that time. In 2012, unmaintained and apparently broken support for non-Linux operating systems was removed. Also, in 2012 strace gained support for path tracing and file descriptor path decoding. In 2014, support for stack traces printing was added. In 2016, syscall fault injection was implemented.

For the additional information, please refer to the NEWS file and strace repository commit log.

REPORTING BUGS

Problems with strace should be reported to the strace mailing list.

AUTHORS

The complete list of strace contributors can be found in the CREDITS file.

2022-10-16

strace 6.2

Package name: extra/strace Version: 6.2-1 Upstream: https://strace.io/ Licenses: BSD Manuals: /listing/extra/strace/ Table of contents

The website is available under the terms of the GPL-3.0 license, except for the contents of the manual pages, which have their own license specified in the corresponding Arch Linux package.

10 Strace Commands for Troubleshooting and Debugging Linux Processes

strace is a powerful command line tool for debugging and trouble shooting programs in Unix-like operating systems such as Linux. It captures and records all system calls made by a process and the signals received by the process.

It displays the name of each system call together with its arguments enclosed in a parenthesis and its return value to standard error; you can optionally redirect it to a file as well.

In this article, we will explain 10 strace command examples for troubleshooting and debugging programs and processes in a Linux system.

How to Install Strace Process Monitoring Tool in Linux

If strace is not pre-installed on your Linux system, run the appropriate command below for your distribution, to install it.

In case a program crashes or behaves in a way not expected, you can go through its systems calls to get a clue of what exactly happened during its execution. As we will see later on, system calls can be categorized under different events: those relating to process management, those that take a file as an argument, those that involve networking, memory mapping, signals, IPC and also file descriptor related system calls.

You can either run a program/command with strace or pass a PID to it using the -p option as in the following examples.

1. Trace Linux Command System Calls

You can simply run a command with strace like this, here we are tracing of all system calls made by the df command.

>P\t». 832) = 832 fstat(3, ) = 0 mmap(NULL, 3971488, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0x7f82f7310000 .

From the output above, you can see various types of system calls made by df command, for example.

open – is the type of system call
(“/etc/ld.so.cache”, O_RDONLY|O_CLOEXEC) – system call argument
3 – system call return value

Below is an sample output showing the write system calls, that displays df command output on the screen.

2. Trace Linux Process PID

If a process is already running, you can trace it by simply passing its PID as follows; this will fill your screen with continues output that shows system calls being made by the process, to end it, press [Ctrl + C] .

%», 4096>], msg_controllen=0, msg_flags=0>, 0) = 32 recvmsg(4, 0x7ffee4dbf870, 0) = -1 EAGAIN (Resource temporarily unavailable) recvmsg(4, 0x7ffee4dbf850, 0) = -1 EAGAIN (Resource temporarily unavailable) poll([, , , , , ], 6, -1) = 1 ([]) read(31, «2», 1) = 1 recvmsg(4, 0x7ffee4dbf850, 0) = -1 EAGAIN (Resource temporarily unavailable) poll([, , , , , ], 6, 0) = 1 ([]) read(31, «2», 1) = 1 recvmsg(4, 0x7ffee4dbf850, 0) = -1 EAGAIN (Resource temporarily unavailable) poll([, , , , , ], 6, 0) = 0 (Timeout) mprotect(0x207faa20000, 8192, PROT_READ|PROT_WRITE) = 0 mprotect(0x207faa20000, 8192, PROT_READ|PROT_EXEC) = 0 mprotect(0x207faa21000, 4096, PROT_READ|PROT_WRITE) = 0 mprotect(0x207faa21000, 4096, PROT_READ|PROT_EXEC) = 0 .

3. Get Summary of Linux Process

Using the -c flag, you can generate a report of total time, calls, and errors for each system call, as follows.

4. Print Instruction Pointer During System Call

The -i option displays the instruction pointer at the time of each system call made by the program.

>P\t». 832) = 832 [00007faf9cafb2b4] fstat(3, ) = 0 [00007faf9cafb47a] mmap(NULL, 3971488, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0x7faf9c716000 [00007faf9cafb517] mprotect(0x7faf9c8d6000, 2097152, PROT_NONE) = 0 .

5. Show Time of Day For Each Trace Output Line

You can also print the time of day for each line in the trace output, by passing the -t flag.

>P\t». 832) = 832 15:19:25 fstat(3, ) = 0 15:19:25 mmap(NULL, 3971488, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0x7f8c7ebec000 15:19:25 mprotect(0x7f8c7edac000, 2097152, PROT_NONE) = 0 .

6. Print Command Time Spent in System Calls

To shows the time difference between the starting and the end of each system call made by a program, use the -T option.

7. Trace Only Specific System Calls

In the command below, trace=write is known as a qualifying expression, where trace is a qualifier (others include signal, abbrev, verbose, raw, read, or write). Here, write is the value of the qualifier.

The following command actually shows the system calls to print df output on standard output.

Here are some additional commands about trace qualifier.

8. Trace System Calls Based on a Certain Condition

Let’s look at how to trace system calls relating to a given class of events. This command can be used to trace all system calls involving process management.

Next, to trace all system calls that take a filename as an argument, run this command.

To trace all system calls involving memory mapping, type.

You can trace all network and signals related system calls.

9. Redirect Trace Output to File

To write the trace messages sent to standard error to a file, use the -o option. This means that only the command output is printed on the screen as shown below.

To look through the file, use cat command.

10. Show Some Debugging Output of Strace

To show debugging information for strace tool, use the -d flag.

For additional information, see the strace man page.

Also read these useful related articles:

In conclusion, strace is a remarkable tool for diagnosing cause(s) of program failure: it is a powerful debugging and trouble shooting. It is practically useful to experienced system administrators, programmers and hackers. To share any thoughts concerning this article, use the feedback form below.

Tutorial Feedback.

If You Appreciate What We Do Here On TecMint, You Should Consider:

TecMint is the fastest growing and most trusted community site for any kind of Linux Articles, Guides and Books on the web. Millions of people visit TecMint! to search or browse the thousands of published articles available FREELY to all.

If you like what you are reading, please consider buying us a coffee ( or 2 ) as a token of appreciation.

Strace linux как пользоваться