Trace file in linux

How to track and trace a Linux process

On this post we will show you how to track and trace a Linux process on the system with two tools, ps and strace command line tools. This system tools can help you to identify real system process and their origin.

On shared web hosting servers it is very common to face spam and malware issues. This issues can happen due to lot of reasons, and sometimes this outgoing spams or attacks are launched from system processes like perl scripts using lot of CPU resources.

On most of this cases, apparently it is “only” a perl process, but here come a few interesting questions: how do you know where is it coming from? How a Linux system process could mask its real name? What is the most easy and reliable way to find out where this Linux process was started?

Today we will try to answer all this questions with some quick and easy practical examples.

Trace a Linux process using ps command

Let’s see a real life example that happened days ago in a dedicated server I manage.

On one particular website there was an outgoing spam issue that was sending lot of emails, but no malware was found inside the public_html folder, also all email boxes passwords were changed, the same as the FTP/cPanel account password. Still, there was a way the attacker was using the Linux system to send outgoing emails.

The source of the emails was a process running under the “johndoe” user which was appearing to be malicious, and was not what it claimed to be:

As you see, the first thing to find out the process was to use the ps command, as you see below:

Replace “user” with your real system user.

After that, once you have the suspicious processes listed, use ll command to find out more information using its PID, as seen before:

As you see, the process claims to be “httpd” to hide itself (any process can change its own process-title), it is actually a perl process:

There was no script file associated with it, however. The script was most likely piped into the perl process to avoid putting anything on the filesystem where it would leave a trace.

I do not know how the script came to be running under this user, but this was a vulnerable WordPress installation with many outdated plugins and injected malware that could easily lead to this kind of issues.

Killing the rouge process was the best thing to do in this case:

Replace “59289” with the real process ID.

Strace: another easy way to trace a system process

strace is a very handy and useful tool used by system administrators for debugging and diagnostic system and process related problems where the source is not really clear and available when taking a quick and first look.

This debug tool allows programmers and system users to quickly find out how a program is interacting with the OS. It does this by monitoring system calls and signals.

As we will see in the next examples, strace outputs each line in the trace that includes the system call name, its arguments and the return value (inside the parentheses).

strace example

Let’s run strace against /bin/ls, and save the output into a file called ls.txt

To read the output, just run:

But that is just a basic strace example. The interesting part comes when you can strace the webserver process and find out what it is doing exactly. Let’s take a php-fpm process as example:

By pressing CTRL + C you will terminate the trace and it will be detached.

Fig 01. Screenshot from strace command example

You can also specify what you need to trace, for example, if you only need to trace the open and read system calls, you should specify that in the strace syntax, as you see below:

This quick strace example used a few command options, exaplained here:

Again, to read the output, just run:

Now you know how to trace a Linux process easily with two simple commands, with this information you can easily track a Linux process to find out what is doing exactly inside your server. strace takes a little bit more of time to understand from the manual, but it’s the definitive tool to trace a Linux process.

Источник

Trace file in linux

This section explains how to install Oracle Trace File Analyzer on different operating systems.

• Oracle Trace File Analyzer
  Oracle Trace File Analyzer helps you collect and analyze diagnostic data.
• Supported Environments
  You can use Oracle Trace File Analyzer with all supported versions of Oracle Database and Oracle Grid Infrastructure.
• Installing Oracle Trace File Analyzer on Linux or UNIX as root User in Daemon Mode
  To obtain the fullest capabilities of Oracle Trace File Analyzer, install it as root .
• Installing Oracle Trace File Analyzer on Linux or UNIX as Non-root User in Non-Daemon Mode
  If you are unable to install as root , then install Oracle Trace File Analyzer as the Oracle home owner.
• Installing Oracle Trace File Analyzer on Microsoft Windows
• Installing Oracle Trace File Analyzer on Microsoft Windows in Non-Daemon Mode
• Oracle Trace File Analyzer Key Directories
  Based on your installation type, the ora_home and the bin directories can differ.
• Oracle Trace File Analyzer Command Interfaces
  The tfactl tool functions as command-line interface, shell interface, and menu interface.
• Masking Sensitive Data
  Masking sensitive data is an optional feature that you can configure Oracle Trace File Analyzer to mask sensitive data in log files.
• Securing Access to Oracle Trace File Analyzer
  Running tfactl commands is restricted to authorized users.
• Uninstalling Oracle Trace File Analyzer

1.1 Oracle Trace File Analyzer

Oracle Trace File Analyzer helps you collect and analyze diagnostic data.

As a DBA, you are expected to do more work with fewer resources all the time. You are under pressure to keep the mission-critical applications up and running. When something goes wrong, everyone looks to you to understand what went wrong and how to fix it.

It is not always easy. You have to run the right tools at the right time. If you’re using Oracle Grid Infrastructure, then you also have to collect diagnostic data from all the database nodes. Collecting this data can require you to use tools that you rarely use. Needless to say, each tool has its own syntax.

The amount of data you collect can be huge. Only a fraction of the data that you collect is useful, but how can you know which part is relevant? You must collect it all, quickly, before the data is overwritten. In the meantime, you have still got a problem that costs your company time and money.

Oracle Trace File Analyzer enables you to collect diagnostic data. Collecting diagnostic data is a crucial step to resolving problems that occur with your Oracle Database.

Oracle Trace File Analyzer monitors your logs for significant problems that potentially impact your service. Oracle Trace File Analyzer also automatically collects relevant diagnostics when it detects any potential problems.

Oracle Trace File Analyzer can identify the relevant information in log files. It trims log files to just the parts that are necessary to resolve an issue. Oracle Trace File Analyzer also collects data across cluster nodes and consolidates everything in one place.

Using important database diagnostic tools is easy with Oracle Trace File Analyzer. Oracle Trace File Analyzer hides the complexity by providing a single interface and syntax for them all.

Источник

How to Trace Program Execution Using Linux Strace Command

The strace is a powerful command-line tool for process monitoring, diagnostic and troubleshooting programs in Linux. Generally, it is used to intercept and record the system calls and the signals received by a process. You can use strace to analyze how a program interacts with the system to debug any program.

This tool is very useful if the program continually crashes, or does not behave as expected. It provides deep insight into how the system operates. Any user may trace their own running processes.

In this tutorial, we will show you how to use the strace command-line tool on Linux.

Install Strace

By default, strace is available in the default repository of all Linux operating systems.

On Debian and Ubuntu operating systems, install the strace with the following command:

On RHEL and CentOS operating systems, install the strace with the following command:

After installing strace, you can verify the strace version using the following command:

You should get the following output:

You can print all options available with strace command with the following command:

1. Trace a System Calls

If you want to trace the system calls of the command ls, run the following command:

In the above output, you can see the system call and result of the call of ls command. You should also see that exit status is 0. That means there was no error.

One use of strace (Except debugging some problem) is that you can find out which configuration files are read by a program.

2. Filter Specific System Calls

Be default, strace displays all system calls for the given executable. If you want to display only a specific system call, you can use strace -e option.

For example, to displays only the write system call of the ls command run the following command:

To displays only the open system call of the ls command run the following command:

If you want to display files opened by a specific process like SSH, run the following command:

To trace network-related system calls, run the following command:

3. Attach to Already Running Process

If a process is already running, you can trace it using its PID as shown below:

This command will continuously showing system calls made by the process. You can press CTRL+C to stop it.

5315 is a process ID of the running process.

4. Redirect Trace Output to a File

You can use -o flag with strace command to save the strace output to specified file.

You can now display the content of the file file_out.txt with the following command:

5. Print Time Spent on System Calls

To print the relative timestamp of each call, use the -r flag as shown below.

To display the time difference between the starting and the end of each system call made by ls command, use the -T option.

To print the wall clock time of each system call, run the following command:

The -tt option displays timestamp followed by microsecond.

6. Display Instruction Pointer of System Call

You can use -i flag with strace command to print the instruction pointer at the time of each system call made by the command:

7. Generate a System Call Report

You can use the -c flag to get the useful statistical report for the execution trace.

In the above output, the «calls» column indicated how many times that particular system call was executed.

8. Print Debugging Output of strace

To print debugging information for strace command, use -d flag as shown below:

9. Trace System Calls Based on a Certain Condition

You can also trace the system calls based on the specific condition. For example, trace all the system calls related to memory management run the following command:

To trace the signal realted system calls, run the following command:

To trace the process realted system calls, run the following command:

Conclusion

In the above guide, you learned how to use the strace command with several examples. This tool is very useful for system administrators and programmers to debug and troubleshoot any program.

Источник

Трассировка ядра с ftrace

Проблемы трассировки и профилирования ядра мы уже затрагивали в предыдущих публикациях. Для анализа событий на уровне ядра существует много специализированных инструментов: SystemTap, Ktap, Sysdig, LTTNG и другие. Об этих инструментах опубликовано много подробных статей и обучающих материалов.

Гораздо меньше информации можно найти о «родных» механизмах Linux, с помощью которых можно отслеживать системные события, получать и анализировать отладочную информацию. Эту тему мы хотели бы рассмотреть в сегодняшней статье. Особое внимание мы уделим ftrace — первому и пока что единственному инструменту трассировки, добавленному в ядро. Начнём с определения основных понятий.

Профилирование и трассировка ядра

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

«Узкие места» очень часто возникают при определённых условиях, которые при профилировании выявить невозможно. Чтобы понять, почему произошло то или иное событие, требуется восстанавливать контекст. В свою очередь, для восстановления контекста требуется трассировка.

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

Программы-трассировщики могут одновременно отслеживать события как на уровне отдельных приложений, так и на уровне операционной системы. Полученная в ходе трассировки информация может оказаться полезной для диагностики и решения многих системных проблем.

Трассировку иногда сравнивают с логгированием. Сходство между этими двумя процедурами действительно есть, но есть и различия.

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

Как и логи, файлы с данными трассировки можно читать «с листа». Гораздо интереснее и полезнее, однако, извлекать из них информацию, которая относится к работе конкретных приложений. Соответствующие функции есть у всех программ-трассировщиков.

В ядре Linux существует три основных механизма, при помощи которых осуществляются процедуры трассировки и профилирования ядра:

• tracepoints — механизм, работающий через статическое инструментирование кода;
• kprobes — механизм динамической трассировки, с помощью которого можно прервать выполнение кода ядра в любом месте, вызвать собственный обработчик и по завершении всех необходимых операций вернуться обратно;
• perf_events — интерфейс доступа к PMU (Performance Monitoring Unit).

Подробно расписывать особенности всех этих механизмов не будем; заинтересованных читателей отсылаем к статье компании «НТЦ МетроТек», а также к блогу Брендана Грегга.

С помощью ftrace можно взаимодействовать с этими механизмами и получать отладочные данные, находясь в пользовательском пространстве. Более подробно об этом мы поговорим ниже. Все примеры команд приводятся для ОС Ubuntu 14.04, ядро версии 3.13.0-24.

Ftrace: общая информация

Название ftrace представляет собой сокращение от Function Trace — трассировка функций. Однако возможности этого инструмента гораздо шире: с его помощью можно отслеживать контекстные переключения, измерять время обработки прерываний, высчитывать время на активизацию заданий с высоким приоритетом и многое другое.

Ftrace был разработан Стивеном Ростедтом и добавлен в ядро в 2008 году, начиная с версии 2.6.27. Это — фреймворк, предоставляющий отладочный кольцевой буфер для записи данных. Собирают эти данные встроенные в ядро программы-трассировщики.

Работает ftrace на базе файловой системы debugfs, которая в большинстве современных дистрибутивов Linux смонтирована по умолчанию. Чтобы приступить к работе с ftrace, нужно просто перейти в директорию sys/kernel/debug/tracing (она доступна только для root-пользователя):

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

• available_tracers — доступные программы-трассировщики;
  current_tracer — программа-трассировщик, активная в текущий момент;
• tracing_on — служебный файл, отвечающий за включение и отключение записи данных в кольцевой буфер (чтобы включить запись, нужно записать в этот файл цифру 1, а чтобы отключить — 0);
• trace — файл, где хранятся данные трассировки в человекочитаемом формате.

Доступные трассировщики

Просмотреть список доступных трассировщиков можно с помощью команды

Приведём краткую характеристику для каждого трассировщика:

• function — трассировщик функций вызовов ядра без возможности получения аргументов;
• function_graph — трассировщик функций вызовов ядра с подвызовами;
• blk — трассировщик вызовов и событий, связанных с вводом-выводом на блочные устройства; именно он используется в утилите blktrace, о которой мы уже писали;
• mmiotrace — трассировщик операций ввода-вывода, отражаемых в память.
• nop — самый простой трассировщик, который, как и следует из названия, ничего не делает (однако в некоторых ситуациях и он может быть полезен, о чём ещё пойдёт речь ниже).

Трассировщик function

Знакомство с ftrace мы начнём с трассировщика function. Рассматривать его мы будем на материале вот такого тестового скрипта:

крипт очень простой и в целом понятный, однако в нём есть моменты, на которые стоит обратить внимание.
Команда sysctl ftrace.enabled=1 включает трассировку функций. Далее мы устанавливаем текущий трассировщик, записывая его имя в файл current_tracer.

После этого мы записываем 1 в файл tracing_on и тем самым активируем обновление кольцевого буфера. Важная особенность синтаксиса: между 1 и знаком > обязательно должен быть пробел: команда вида echo1> tracing_on не сработает. Буквально через одну строку мы его отключаем (обратите внимание: если в файл tracing_on записать 0, кольцевой буфер не будет очищен; не будет отключен и ftrace).

Зачем мы это делаем? Между двумя командами echo находится команда sleep 1. Мы включаем обновление буфера, выполняем эту команду и затем сразу же его отключаем. Благодаря этому в трассировку будет включена информация обо всех системных вызовах, которые имели место во время выполнения этой команды.

В последней строке скрипта мы даём команду вывести данные трассировки на консоль.

В результате выполнения этого скрипта мы увидим следующий вывод (приводим лишь небольшой фрагмент):

Вывод начинается с информации о количестве записей событий в буфере (entries in buffer) и общем количестве записанных событий (entries written). Разница между этими двумя цифрами — это количество событий, утерянных при заполнении буфера (в нашем случае никаких утерянных событий нет).

Далее идёт перечень функций, включающий следующую информацию:

• идентификатор процесса (PID);
• номер процессорного ядра, на котором выполняется трассировка(СPU#);
• метка времени (TIMESTAMP; указывает время, когда произошёл вход в функцию);
• имя трассируемой функции и имя родительской функции, которая её вызвала(FUNCTION); например, в самой первой строке приведённого нами вывода функцию mutex-unlock вызывает функция rb_simple_write.

Трассировщик function_graph

Трассировщик function_graph работает точно так же, как function, но отслеживает функции более подробно: для каждой функции он указывает точку входа и точку выхода. С помощью этого трассировщика можно отслеживать функции с подвызовами и измерять время выполнения для каждой функции.

Отредактируем использованный в предыдущем примере скрипт:

В результате выполнения этого скрипта мы получим следующий вывод:

В графе DURATION указывается время, затраченное на выполнение функции. Особое внимание следует обратить на пункты, отмеченные значками + и! Знак + означает, что выполнение функции заняло более 10 микросекунд, а восклицательный знак — более 100.

В графе FUNCTION_CALLS с информацией о вызовах функций.
Начало и конец выполнения каждой функции обозначаются в ней так, как это принято в языке C: фигурная скобка в начале функции и ещё одна — в конце. Функции, которые являются листьями графа и не вызывают никаких других функций, обозначаются точкой с запятой (;).

Фильтры для функций

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

Чтобы отключить фильтр, нужно записать в этот же файл пустую строку:

В результате выполнения команды

мы получим совершенно противоположный результат: в вывод будет попадать информация обо всех функциях, кроме kfree().

Ещё одна полезная опция — set_ftrace_pid. Она предназначена для трассировки функций, вызываемых во время выполнения указанного процесса.

Возможности фильтрации в ftrace гораздо шире; подробнее о них можно прочитать в статье Стивена Ростедта на LWN.net.

Трассировка событий

Выше мы уже упоминали о механизме tracepoints. Слово tracepoint в переводе означает «точка трассировки». Точка трассировки — это специальная вставка в код, регистрирующая определённые системные события. Точка трассировки могут быть активной (это значит, что за ней закреплена некоторая проверка) или неактивной (никакой проверки за ней не закреплено).

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

Когда точка трассировки активна, при выполнении соответствующего фрагмента кода вызывается трассировочная функция. Данные трассировки записываются в отладочный кольцевой буфер.

Точки трассировки могут быть вставлены в любое место в коде. Они уже присутствуют в коде многих ядерных функций. Рассмотрим, например, функцию kmem_cache_alloc (взято отсюда):

Обратите внимание на строку trace_kmem_cache_alloc — это как раз и есть точка трассировки. Количество подобных примеров можно умножить, обратившись к исходному коду других функций ядра.

В ядре Linux имеется специальный API, с помощью которого можно работать с точками трассировки из пользовательского пространства. В директории /sys/kernel/debug/tracing есть поддиректория events, в которой хранятся доступные для отслеживания системные события. Системное событие в данном контексте — не что иное, как включенные в ядро точки трассировки.

Их список можно просмотреть с помощью команды:

На консоль будет выведен длинный список, просматривать который довольно неудобно. Вывести этот же список в более структурированном формате можно так:

Прежде чем приступать к отслеживанию событий, проверим, включена ли запись событий в кольцевой буфер:

Если после выполнения этой команды на консоль будет выведена цифра 0, выполним:

В прошлой статье мы писали о системном вызове chroot() — вход в этом системный вызов мы и будем отслеживать. В качестве трассировщика мы выберем nop: function и function_graph записывают слишком много информации, в том числе и не имеющей отношения к интересующему нас событию.

Все события, связанные с системными вызовами, хранятся в директории syscalls. В ней, в свою очередь, хранятся директории для входа и выхода из различных системных вызовов. Активируем нужную нам точку трассировки, записав 1 в её enable-файл:

Затем создадим изолированную файловую систему с помощью команды chroot (подробности см. в предыдущем посте). После выполнения интересующих нас команд отключим трассировку, чтобы в вывод не попадала информация о лишних и не имеющих отношения к делу событиях:

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

Более подробно о настройках трассировки событий можно почитать здесь.

Заключение

В этой статье мы проделали общий обзор возможностей ftrace. Будем признательны за любые замечания и дополнения. Если вы хотите глубже погрузиться в тему, рекомендуем ознакомиться со следующими источниками:

Источник