klirichek 17 янв 2014 в 16:12

Изучаем внутреннюю кухню ядра Linux с помощью /proc для быстрой диагностики и решения проблем

13 мин

67K

Open source*

Перевод

+123

Комментарии 28

isapioff 17 янв 2014 в 16:31

Вы молодец! Спасибо за статью!

bondbig 17 янв 2014 в 16:46

Это перевод, но тем не менее, да, подробное описание, интересные инструменты. Хоть это и не общеприменимый гайд, а конкретный пример, все равно полезно.

pavelodintsov 17 янв 2014 в 17:18

Есть более удобный способ посмотреть WCHAN, не дергая ps сто раз: top, жмем «f», выбираем WCHAN, жмем пробел, чтобы выделить его и выходим по ESC.

И получаем в итоге:

Kukunin 17 янв 2014 в 17:53

Так что, процессы не зависают сами по себе, и у зависаний всегда есть причина!?

klirichek 17 янв 2014 в 18:14

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

amarao 18 янв 2014 в 00:12

Спасибо, статья хорошая. А вот что виновато nfs я понял сразу после того, как увидел 'D'. Подвисающий неубиваемый процесс, который ничем не занимается может заниматься только одним — тупить в ~~цветоче~~ в NFS. Все остальные сетевые файловые системы менее процессораздирающие.

Nastradamus 18 янв 2014 в 19:22

Ну не обязательно NFS. Может залипнуть и на любой другой FS из-за жесткого диска или бага FS. Сам я правда не сталкивался, от коллег слышал.

amarao 18 янв 2014 в 20:14

Залипания из-за глюков на диске обычно очень хорошо видны — страшный срач в dmesg'е. Другие сетевые fs тоже обычно имеют явные средства диагностики. Только nfs отличается молчаливым режимом «японского партизана, сражающегося 40 лет спустя после капитуляции страны».

ihormanchik 18 янв 2014 в 00:32

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

easyman 18 янв 2014 в 00:34

А с какой стороны копать, если приложение автоматически закрывается и в консоль печатается слово Killed?

Я купил NAS: Seagate Central
Внутри оказался Cavium Econa CNS3420 SoC
Есть доступ по SSH, root. Установлен Montavista Linux
Более опытные чем я люди с компилированием софта под этого зверя обломались
Я нашел там mono — проверил, программы на .net 2 нормально исполняются :)
Есть python… много чего есть. Но gcc нет :(

Диск интересно размечен:
Partition Table: gpt

Number Start End Size File system Name Flags
1 1049kB 22.0MB 21.0MB ext2 Kernel_1
2 22.0MB 43.0MB 21.0MB ext2 Kernel_2
3 43.0MB 1117MB 1074MB ext4 Root_File_System_1
4 1117MB 2190MB 1074MB ext4 Root_File_System_2
5 2190MB 3264MB 1074MB ext4 Config
6 3264MB 4338MB 1074MB linux-swap(v1) Swap
7 4338MB 5412MB 1074MB ext4 Update
8 5412MB 3001GB 2995GB Data lvm

И руководства, как пользоваться устройством «по назначению» пока нет.
Куда копать? Чего читать/качать/ставить/запускать?

KAndy 18 янв 2014 в 01:41

посмотрите в syslog
часто такое соощение выдается в случаи если память закончилась и oom killer грохает процесы

easyman 18 янв 2014 в 01:43

Да мне для начала что-нибудь скомпилить надо.
Я надеялся, что в природе есть способ скомпилировать что-нибудь и без особых проблем.

klirichek 18 янв 2014 в 09:06

Ищите тулчейн для вашей железки. Скорее всего где-нибудь на форумах поддержки нароете!
Посмотрите uname -a — очень часто в отпечатке ядра остаётся «автограф» от системы, где его собирали (вроде red hat, debian или ubuntu). А потом гуглите по сочетанию имени железки + найденного отпечатка + слов вроде «toolchain» или «cross toolchain».
Универсального рецепта нет!

jcmvbkbc 18 янв 2014 в 17:38

Попробуйте начать с того, чтобы запустить hello world собранный статически любым компилятором для arm linux.

klirichek 18 янв 2014 в 09:02

Dmesg можно для начала посмотреть. Ну и более общие логи, вроде /var/log/syslog или /var/log/messages.

amarao 18 янв 2014 в 20:15

Возможно, ошибка с выравниванием или неправильная архитектура бинарника. Я бы запустил приложение из gdb и посмотрел, где оно упадёт.

Sap_ru 18 янв 2014 в 01:11

У Вас что-то с примером про strace/pstack — оба вывода одинаковые. Может напутали что-то?

weirded 18 янв 2014 в 01:39

Хорошая статья, спасибо!

Можете подсказать, имеются ли готовые утилиты для лёгкого профилирования всего ядра Linux, а не конкретных модулей/процессов?
Интересуют решения, работающие в x86_64 архитектуре.

Пример, чего хотелось бы видеть в качестве output'а утилиты:

3032 conntrack_mt_origsrc
1053 pppoe_seq_next
560 pppox_sock
32 something_else
31 something_else2
10 __etc

Просто боюсь, что скоро без такой утилиты у встанет работа и придётся её писать самому. :)

jcmvbkbc 18 янв 2014 в 02:42

oprofile? perf?

kachini 18 янв 2014 в 12:22

C этим на linux проблема. Я работаю с HP-UX, там есть такая профилировка. По окончании каждого тайм слайса генерится per cpu эвент и в ring buffer скидывается чем занимался процессор (PID, функция ядра, стек !). Очень полезная функция для изучения чем занимаются процессоры. На Linux, насколько знаю, код в ядре для реализации есть, но с утилитами дефицит.

weirded 21 янв 2014 в 17:17

Везёт вам! Я вот всё не дойду до того чтобы perf посмотреть.
Походу придётся адовыми хаками на nmi_timer вешаться и через dmesg, через dmesg, да башем агрегировать. :)

Nastradamus 18 янв 2014 в 14:41

Похоже, сама команда strace тоже зависла!

Потому что strace'у нужно переключать контекст на трассируемую программу. Потому что в Linux нет трассировщика, который бы получал данные о syscall'ах напрямую из ядра. В *BSD есть ktrace для этих целей. Задачи из статьи им решаются очень быстро и без риска уронить процесс.

Однако, много интересного узнал о /proc. Надо будет сравнить с FreeBSD.