Внутреннее устройство Linux - Уорд Брайан - Страница 58

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

8.3.1. Команда strace

Вспомните о том, что системный вызов является привилегированной операцией, которую процесс из пространства пользователя просит у ядра выполнить (например, открытие файла и чтение данных из него). Утилита strace выводит список всех системных вызовов, которые осуществляет процесс. Чтобы увидеть это в действии, запустите такую команду:

$ strace cat /dev/null

Из главы 1 вы узнали о том, что, когда процесс собирается запустить другой процесс, он задействует системный вызов fork(), чтобы создать ответвленную копию, которая затем использует один из системных вызовов семейства exec(), чтобы запустить новую команду. Команда strace начинает работать с новым процессом (копией исходного процесса) сразу после вызова fork(). Следовательно, первые строки вывода данной команды должны показать команду execve() в действии, за которой следует вызов инициализации памяти, brk(), как приведено ниже:

execve("/bin/cat", ["cat", "/dev/null"], [/* 58 vars */]) = 0

brk(0)                                  = 0x9b65000

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

access("/etc/ld.so.nohwcap", F_OK)    = -1 ENOENT (No such file or directory)

mmap2(NULL, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb77b5000

access("/etc/ld.so.preload", R_OK)    = -1 ENOENT (No such file or directory)

open("/etc/ld.so.cache", O_RDONLY|O_CLOEXEC) = 3

—snip—

open("/lib/libc.so.6", O_RDONLY)       = 3

read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0\200^\1"..., 1024)= 1024

Кроме того, пропустите вывод до команды mmap включительно, пока не встретите строки, подобные следующим:

fstat64(1, {st_mode=S_IFCHR|0620, st_rdev=makedev(136, 6), ...}) = 0

open("/dev/null", O_RDONLY|O_LARGEFILE) = 3

fstat64(3, {st_mode=S_IFCHR|0666, st_rdev=makedev(1, 3), ...}) = 0

fadvise64_64(3, 0, 0, POSIX_FADV_SEQUENTIAL)= 0

read(3,"", 32768)                      = 0

close(3)                               = 0

close(1)                               = 0

close(2)                               = 0

exit_group(0)                          = ?

Эта часть вывода показывает команду в действии. Сначала посмотрите на вызов open(), который открывает файл. Число 3 — результат, означающий успешное завершение (это файловый дескриптор, который ядро возвращает после открытия файла). Под ним вы видите, где команда cat выполняет чтение из устройства /dev/null (вызов read(), который также обладает файловым дескриптором 3). Считывать больше нечего, поэтому команда закрывает файловый дескриптор и выходит с помощью вызова exit_group().

Что происходит, если возникает ошибка? Попробуйте запустить команду strace cat not_a_file и посмотрите на системный вызов open() в результатах вывода:

open("not_a_file", O_RDONLY|O_LARGEFILE) = -1 ENOENT (No such file or directory)

Поскольку команде open() не удалось открыть файл, она возвратила значение -1, чтобы сообщить об ошибке. Видно, что команда strace выводит название ошибки и дает ее краткое описание.

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

$ strace -o crummyd_strace -ff crummyd

В данном примере параметр -o команды strace заносит в журнал действия любого дочернего процесса, который демон crummy породил в crummyd_strace.pid, где pid — это идентификатор дочернего процесса.

8.3.2. Команда ltrace

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

примечание

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

8.4. Потоки

В Linux некоторые процессы разделены на части, называемые потоками. Поток очень похож на процесс: у него есть идентификатор (TID, или ID потока), и ядро планирует запуск потоков и запускает их так же, как и процессы. Однако в отличие от отдельных процессов, которые обычно не используют совместно с другими процессами такие системные ресурсы, как оперативная память и подключение к вводу/выводу, все потоки внутри какого-либо процесса совместно задействуют ресурсы системы и некоторую часть памяти.

8.4.1. Однопоточные и многопоточные процессы

Многие процессы обладают только одним потоком. Процесс с одним потоком является однопоточным, а процесс с несколькими потоками — многопоточным. Все процессы запускаются как однопоточные. Этот стартовый поток обычно называется главным потоком. Затем главный поток может запустить новые потоки, чтобы процесс стал многопоточным, подобно тому как процесс может вызвать команду fork() для запуска нового процесса.

примечание

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

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

Некоторые команды применяют потоки, чтобы обойти проблемы при управлении несколькими ресурсами ввода/вывода. Традиционно процесс использовал бы что-либо вроде команды fork(), чтобы запустить новый подпроцесс для работы с новым потоком ввода или вывода. Потоки предлагают похожий механизм без излишнего запуска нового процесса.

8.4.2. Просмотр потоков

По умолчанию в выводе команд ps и top отображаются только процессы. Чтобы показать информацию о потоке в команде ps, добавьте параметр m (пример 8.1).

Пример 8.1. Просмотр потоков с помощью команды ps m

$ ps m

  PID TTY      STAT  TIME COMMAND

3587 pts/3   –    0:00 bash

   –-        Ss    0:00 -

3592 pts/4   –    0:00 bash

   –-        Ss    0:00 -

12287 pts/8   –    0:54 /usr/bin/python /usr/bin/gm-notify