Comments
Классная статья, спасибо! В тестировании тоже периодически приходится использовать strace.
Может быть удобно использовать флаг -ff, который вместе с -o распределяет весь вывод по файлам с постфиксом ".%PID%"
Также стоит упомянуть и про -s — иначе все строки обрезаются до 32 символов, а иногда хочется иметь весь вывод, чтобы что-нибудь погрепать в нём.

Точно, спасибо! :-) Про -ff не знал, да, удобно.


А вот про -s знал, но всего и не напишешь. В большей степени я эту статью задумывал ради демонстрации новых возможностей: инъекций ошибок и отображения стека в момент вызова.

strace иногда незаменим, особенно когда запущенный процесс никуда не пишет, но и не функционирует. Очень часто выручает. Спасибо за статью!

точно, на этот случай приходится процентов 80 из всех моих запусков strace. :-)

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

Я не евангелист DTrace, это была больше шутка про несколько существующих портов и клонов под Линуксами.


Но при чем здесь eBPF? :-) Dtrace — полный комплект для трассировки и программирования поведения ядра, включающий как пользовательские утилиты, так и изменения в ядре ОС. eBPF же — достаточно низкоуровневая штука, сама по себе пользователям ничего не дающая.

Я понимаю референс и шутку, многие годы dtrace был неким философским камнем в мире трейсинга Linux, нюанс скорее в том, что вокруг eBPF уже выстроен тулинг, дающий намного больше возможностей чем strace и даже dtrace — например bpftrace или sysdig. Последний например у нас развернут по всей инфре и очень часто выручает.

Да уж, воистину eBPF — отдельная вселенная прораммируемых ядер :-)

Ещё это порой используется для интеграции с определенными приложениями. Можно довешивать своего рода plug-ins к сторонним программам, расширяя их функциональность независимо от наличия исходного кода и использования конкретного языка программирования.

Именно strace? Или системный вызов ptrace? Мне кажется, что есть более эффективные способы.

Интересно, поделитесь более эффективными способами помимо подмены so и вызова ptrace на старых ядрах (это если хочется и можется в C). Были ситуации, когда быстро допиливалось приложение на java или python, просто читающее из stdout strace с настроенными фильтрами и далее расширялось в зависимости от требований.

Гм. Все зависит от целей подмены.


Я вот сейчас обнаружил команду PTRACE_SYSEMU в man 2 ptrace и, пожалуй, в этом варианте оно неплохо будет работать, с единственным прыжком в код ядра.


Если же хочется как-то хитрее фильтровать всякое, то можно использовать продвинутые инструменты на базе BPF (тот же bpftrace).


Но вообще вы правы, лишь бы работало :-)

Иногда не столько подмена, сколько перехват и реакция. PTRACE_SYSEMU не доступен ранее 2.6 и только в 32-битах, с BPF тоже надо что-то свежее, а порой приходится копошиться/поддерживать/расширять разное. Ситуация похожа на сишную: есть много других хороших альтернатив, но по универсальности применения в разных условиях сложно найти конкурента.

Вот уж воистину всякое приходится ковырять, да :-) Но, согласитесь, версии < 2.6 это вот прям действительно давно.

Да, давно. Благо, все реже и реже встречается настолько старое. Скажем так: есть компании с очень консервативным подходом к апгрейду того, что и так работает, пока совсем не прижмет.

Да, я в курсе. Есть еще военные с их раритетами, и для них тоже куча всего разрабатывается.


В конце концов, принцип "работает — не трогай" никто не отменял. Хотя мало удовольствия в работе с такими законсервированными машинам.


Но мне как-то все равно было бы страшновато вокруг strace скриптом на Питоне работать :-)

«Когда б вы знали, из какого сора Растут стихи, не ведая стыда».
На питоне иногда надо быстро собрать, чтобы показать MVP заказчику на его системе, погонять в пилотных условиях и получить полноценное финансирование для дальнейшего допиливания, используя более надежные/серьезные средства.

Но ведь как раз с Python все очень просто, и не нужны никакие strace. Просто залезаем в нужный исходник и правим. Сколько раз меня это спасало (знаю, есть люди, которые кинут в меня тапком за такое варварство).


Также Python позволяет элементарно манкипатчить любой код. Можно в точке вызова добавить код, который в нужном модуле заменит код функции или метода или класса.


К сожалению, с распространением docker делать это стало намного сложнее.

Речь не о том, чтобы менять приложение на Питоне, а о том, чтобы Питоном вылавливать поток вывода strace и делать всякое в момент прихода искомого системного вызова.

Да, как уже ответил VIK, идея в том, чтобы в простейшем случае грубо говоря подсоединить свои python скрипты к событиям генерируемым любым приложением реализованным на любом языке.

Джон (если вы про John Lions) это автор сборника комментариев к исходномому коду шестой версии Unix. Эта книга у меня есть. Там параллельно, собственно, коду идут пояснения принципов работы Unix. Он использовал эту неофициальную книгу в качестве учебника. Сам код Unix Лайонс не писал совершенно точно, к Bell Labs отношение имел только косвенное.


Историю же знаменитого комментария в изложении самого Ричи можно посмотреть, например, по следующей ссылке: http://orkinos.cmpe.boun.edu.tr/~kosar/odd.html

Only those users with full accounts are able to leave comments. Log in, please.