Исследование проблемных процессов
Когда вы пытаетесь сделать что-то переносимым, тестируйте функции, а не платформы:
if ls --help 2>&1 | grep -q -- --color
then
alias ls='ls --color=auto -F'
else
alias ls='ls -FG'
fi
Платформенные тесты ломаются, когда платформы меняются. Сегодня macOS поставляет сочетание инструментов пользовательского пространства BSD и GNU, но это сочетание со временем смещается в сторону большего преобладания инструментов BSD. Итак, тест на «macOS» сегодня может потерпеть неудачу завтра, когда Apple заменит инструмент GNU, от которого вы зависели, его ближайшим эквивалентом BSD, если вы полагаетесь на функцию, которую они реализуют по-разному. Функциональные тесты все чаще продолжают работать, несмотря на изменения.
В качестве бонуса иногда вы создаете поддержку для платформ, которые изначально не тестировались. Приведенный выше фрагмент сценария также должен работать правильно, например, в Solaris и FreeBSD.
(Это, кстати, философия GNU Autoconf, поэтому сценарий configure , написанный 10 лет назад, вероятно, до сих пор работает в совершенно новой системе.)
Измените псевдонимы на подходить. Я просто показываю значения, которые я использую в ближайших к вам системах macOS и Linux, когда пишу это.
Для этого можно использовать 2 низкоуровневых инструмента: strace и gdb . Доступность strace предполагает, что вы используете Linux или ОС, в которой он работает. Для других ОС у вас может быть truss или dtrace , но методика аналогична.
strace
Итак, strace проще в использовании, чем gdb , и обычно отлично отвечает на вопрос «что делает это приложение». Типичное использование (для меня) будет примерно таким:
strace -f -tt -s 200 -p $PID
Единственный реальный вариант, который вам нужен, - это -p $ PID . Другие параметры просто добавляют дополнительную информацию в строку вывода, но в действительности они не нужны.
Это показывает каждый системный вызов, выполняемый приложением. Единственный способ, которым приложение может что-то делать, а strace не показывает этого, - это чисто вычислительные операции. Имеется в виду хрустящие числа или что-то в этом роде. Такие вещи, как чтение / запись файла, отправка пакета, получение текущего времени и т. Д., Требуют системного вызова и будут отображаться.
gdb
gdb является более низким уровнем, чем strace . gdb покажет вам, какая строка кода на самом деле выполняется приложением.Однако здесь есть несколько подводных камней. Важным является то, что вам нужны отладочные символы для приложения. В пакетах, предоставляемых дистрибутивом, они обычно были удалены. Однако в таких дистрибутивах, как производные от RedHat, они часто предоставляются в виде pkgfoo-debuginfo-1.2.3.rpm . Вы можете просто установить этот пакет и вернуть символы.
Другое дело, что где strace покажет вам, что приложение делает с течением времени, gdb покажет вам, что приложение работает именно в этот момент, так как замораживает процесс, пока вы его проверяете.
Так или иначе, использование выглядит так:
gdb -p $PID
... что приведет вас к интерактивной оболочке, где вы можете запустить что-то вроде:
where
или
info threads
Я не буду вдаваться в подробности того, как использовать gdb , так как в зависимости от сложности вашего приложения это может быть сложно, и в Интернете есть множество руководств.
Когда вы закончите копаться в процессе и захотите, чтобы он продолжился, просто используйте quit или CTRL + D .
Вы можете запустить большинство процессов из окна терминала с подробным выводом, добавив флаг -v . Таким образом, вы увидите, что (и если что) происходит в окне терминала, когда оно зависает.
top и htop предоставляют полезную информацию о запущенных процессах, включая обновленную информацию об использовании памяти и процессора, а также некоторую очень полезную сводную информацию.
Вы также можете посмотреть документацию по командам ps с помощью man ps .