Зависання FreeBSD, як траблежартувати

У незрозумілий час фря зависає. Hа пінги відповідає, але більше нічого не працює. Hа натискання Power вперше нічого не відбувається, повторні натискання:

acpi: suspend request ignored (no ready yet) acpi: request to enter state S5 failed (err 6) acpi: suspend request ignored (no ready yet) acpi: request to enter state S5 failed ( err 6) acpi: suspend request ignored (no ready yet) acpi: request для вводу часу S5 failed (err 6)

Що б таке зробити, щоб зрозуміти в чому причина?

17 вер 2009, четвер, о 10:26 KRAT, Alex Bakhtin написав(ла):

AB> У незрозумілий час фря зависає. Hа пінги відповідає, але AB> більше нічого не працює.

AB> Що б таке зробити, щоб зрозуміти, у чому причина?

Читати Handbook про налагодження ядра? :-) Потім Ctrl-Alt-ESC, trace etc.

17 вер 2009, четвер, о 16:13 KRAT, Andriy Gapon написав(ла):

AB>> У незрозумілий час фря зависає. Hа пінги відповідає, але AB> більше нічого не працює. AB>> Що б таке зробити, щоб зрозуміти в чому причина?

AG> SW_WATCHDOG також може стати в нагоді (якщо ядро з дебагом).

Забув ще згадати INVARIANTS товариші, вони часто конвертують зависання в kernel panic зі виразним крешдампом і автоматичним відновленням через ребут ;-)

AB> У незрозумілий час фря зависає. Hа пінги відповідає, але AB> більше нічого не працює. AB> Що б таке зробити, щоб зрозуміти в чому причина?

AG> SW_WATCHDOG також може стати в нагоді (якщо ядро з дебагом).

EG> Забув ще згадати про товариші INVARIANTS, вони часто конвертують EG> зависання в kernel panic зі виразним крешдампом та автоматичним EG> відновленням черезребут ;-)

MG> Можна було, щоб система не чекала у налагоджувачі при паніці, за допомогою ddb script MG> (ddb(8), textdump(4)) виставити команди відладчику, щоб зняв бекртейс, MG> стан процесорів, ps, локи, здампил і перевантажив систему. + зняти MG> бектрейс за допомогою kgdb (або просто запустити crashinfo) та запостити MG> куди-небудь у хакерс або стейбл :-). Або б баг полагодили.

MG> Можна було, щоб система не чекала у налагоджувачі при паніці, за допомогою ddb MG> script (ddb(8), textdump(4)) виставити команди відладчику, щоб зняв MG> бекртейс, стан процесорів, ps, локи, здампил і перевантажив систему. + MG> зняти MG> бектрейс за допомогою kgdb (або просто запустити crashinfo) та запостити MG> куди-небудь у хакерс або стейбл :-). Або б баг полагодили.

а зроби сюди будь ласка докладну покрокову інструкцію?

1) Включаємо дамп девайс:

dumpdev="AUTO" в /etc/rc.conf та /etc/rc.d/dumpon start

2) завантажуємо скрипт в ddb, який виконуватиметься при паніці:

/sbin/ddb script 'kdb.enter.panic=capture on; show pcpu; show allpcpu; bt; ps; \ show locks; show alllocks; show lockedvnods; alltrace; call doadump; reset'

(Включити логування виведення ddb в буфер, вивести різноманітну інформацію, скинути Дамп і перевантажити комп'ютер).

3) збільшити розмір capture буфера. За умовчанням дуже маленьке значення, весь висновок не міститься (нещодавно були розмови збільшити значення за замовчанням, так що в CURRENT може вже й не так).

sysyctl -w debug.ddb.capture.bufsize=5242880# це із запасом

Чекаємо на паніку. Після паніки

4) запускаємо crashinfo. Це створить файл /var/crash/core.txt.X з купою корисної інформації, починаючи від бектрейсу і закінчуючи виведенням утиліт, які вміють працювати з крашдампами.

5) витягуємо вміст capture буфера:

ddb capture -M /var/crash/vmcore.X print > ddb.out

Наприкінці файлу, заповнена частина буфера буде як рядок PPPP. Її можна видалити :-)

До речі, якщо з якихось причин не хочеться створювати звичайний дамп ядра (наприклад свап розділ маленький) можна налаштувати систему, щоб скидала textdump. Або в скрипті ddb додаємо textdump set:

/sbin/ddb script 'kdb.enter.panic=textdump set; capture on; show pcpu; show allpcpu; bt; ps; \ show locks; show alllocks; show lockedvnods; alltrace; call doadump; reset'

або sysctl -w debug.ddb.textdump.pending=1.

Після паніки замість звичайного vmcore.X savecore створить textdump.tar.X що містить висновок capture буфера, конфіг ядра, версію, dmesg, рядок паніки.

24 Sep 09, Mikolaj Golub пишеться до Slawa Olhovchenkov:

MG> Чекаємо на паніку. Після паніки

MG> 4) запускаємо crashinfo. Це створить файл /var/crash/core.txt.X з купою MG> корисної інформації, починаючи від бектрейсу і закінчуючи висновком утиліт які MG> вміють працювати із крашдампами.

MG> 5) витягуємо вміст capture буфера:

MG> ddb capture -M /var/crash/vmcore.X print > ddb.out

MG> Наприкінці файлу, заповнена частина буфера буде як рядок PPPP. Її MG> можна MG> видалити :-)

це все краще робити підправивши /etc/rc.d/savecore?

а ніхто стандартний хук там для цього зробити не хоче? замість зі скриптом і відправкою результатів на пошту coreteam?

. Я прийшов до тебе з дискетою - розповісти, що мережа впала

Тут потрібно ще врахувати, що це все працює тільки при вкомпілованій підтримці ddb, а GENERIC мобується без ddb. Тому робити "для всіх" особливого сенсу немає.

Пропонувалося як Summer of Code проекту щось подібне але здається ніхто не спонукався.

Kernel Projects DDB/gdb scripting Suggested Summer of Code 2009 project idea

Technical contact: Kris Kennaway

Принципом слід розробити scripts, що автоматично керують стандартним рівнем з використанням усунення повідомлень в DDB під час panic and save in textdump. Might be too short on its own, so could be combined with project to write gdb macro equivalents of the DDB command set, extending the macros John Baldwin has. New DDB commands and macros could also be implemented, e.g. for inspecting інші common data structures.

Мене витягування з vmcore лога ddb якось не напружує, а ось про те, що непогано було б зробити можливість включення ddb скриптів стандартно через rc.conf думав. Менше метушні - менше ймовірність що промахнешся в цьому місці і отримаєш хост висить в дебургері.

MG> Тут потрібно ще врахувати, що це все працює тільки при вкомпілованій MG> підтримка ddb, а GENERIC мобується без ddb. Тому робити "для всіх" MG> особливого сенсу нема.

який генерик? на current? і чому б не включати до штатного генерика підтримку ddb?

MG> Пропонувалося як Summer of Code проекту щось подібне до MG> Здається ніхто не спонукався.

а це не надто дрібно на Summer of Code? Судячи з твоїх слів - справ на піввечора.

потім з мантейнерами боротися можна тиждень треба буде

MG> Мене витягування зvmcore лога ddb якось не напружує, а ось про те що MG> непогано було б зробити можливість включення скриптів ddb стандартно MG> через MG> rc.conf думав. Менше метушні - менше ймовірність що схибнеш у цьому MG> місці і отримаєш хост, що висить у дебургері.

. Хто заважає тобі вигадати порох непромокальним?

Виявляється, і так вже є :-). Минулого разу коли дивився, не помітив якось (може і не було просто тоді ще).

У rc.conf ddb_enable="YES" та й можна виправити /etc/ddb.conf.

По змочуванню /etc/ddb.conf включається textdump. Тому, виставивши в /etc/rc.conf:

Отримаємо автоматичне перезавантаження після паніки із збереженням текстудump. Якщо хочеться мати звичайний dump (чого я всім раджу :-), то з /etc/ddb.conf потрібно прибрати "textdump set;". Тоді вміст capture буфера дістаємо коммадою:

ddb capture -M /var/crash/vmcore.X print > ddb.out

Цей крок здається поки що не автоматизований через rc скрипти.

23 Вер 2009, середа, о 22:50 KRAT, Alex Bakhtin написав(ла):

AG>> SW_WATCHDOG також може стати в нагоді (якщо ядро з дебагом).

Це ж не для продакшну, максимум для своєї робочої станції. Для продакшну це максимум на один раз, причому налаштування має бути таким, що при паніці воно повинне само ребутитися (а зовсім не в відладчик вилітати) і при ребуті писати крешдамп. Після чого на крешдамп треба подивитися, трейс з нього зняти і буде він осудний (стек не рознесений), послати PR. Ядро повернути робітник.

EG> Це ж не для продакшну, максимум для своєї робочоїстанції.

Але висне вона в мене в продакшені:)

EG> Для продакшну це максимум на один раз, причому налаштування має бути EG> такий, що при паніці воно має само ребутіться (а зовсім не в отладчик EG> вилітати) і при ребуті писати крешдамп. Після цього на крешдамп треба EG> подивитися, трейс з нього зняти і буде він осудний (стек не рознесений), EG> надіслати PR. Ядро повернути робітник.

Розумієш, у чому справа. Передбачалося, що ми ловимо зависання, яке раз на кілька місяців :) А там інших косяків повно, як з'ясувалося. Я погляну на ddb script.

24 вер 2009, четвер, о 10:13 KRAT, Alex Bakhtin написав(ла):

EG>> Для продакшна це максимум на один раз, причому налаштування має бути EG> такий, що при паніці воно має саме ребутіться (а зовсім не в відладчик EG>> вилітати) і при ребуті писати крешдамп. Після цього на крешдамп треба EG>> подивитися, трейс з нього зняти і буде він осудний (стек не рознесений), EG>> надіслати PR. Ядро повернути робоче. AB> Розумієш, у чому справа. Передбачалося, що ми ловимо зависання, яке AB> раз на кілька місяців:) А там інших косяків повно, як з'ясувалося. Я AB> подивлюся на script ddb.

Авторебут і запис крешдампа працюють без будь-якого ddb script, опція ядра зі словом UNATTENDED в імені.

AB> У незрозумілий час фря зависає. Hа пінги відповідає, але AB> більше нічого не працює.

AB> Що б таке зробити, щоб зрозуміти, у чому причина?

EG> Читати Handbook про налагодження ядра? :-)

Hу, це цікава думка:) Девелоперс хендбук.

EG> Потім Ctrl-Alt-ESC, trace, etc.

Доступ тільки через Serial Console з найближчої кішки. Машинка в кількох тисячахкілометрів від мене. Ага, знайшов. options BREAK_TO_DEBUGGER.

Зібрав. Ппц. Неюзабельно. Відразу після монтування відповідної FS. Так, я розумію, що у мене gmirror накладений на geli. Але це не привід для паніки.

panic: bio_caller1 використовувався як провідник світла/encpublic cpuid = 1 KDB: enter: panic [thread pid 2365 tid 100090] ) db> bt Tracing pid 2365 tid 100090 td 0xffffff000161f720 kdb_enter_why() at kdb_enter_why+0x3d panic() at panic+0x176 g_io_de rror_worker() at g_mirror_worker+ 0x127a fork_exit() at fork_exit+0x12a fork_trampoline() at fork_trampoline+0xe --- trap 0, rip = 0, rsp = 0xffffff803ea94d30, rbp =

Доведеться відкочувати на ядро без налагодження. Найгірше - я не знаю як утворити мій дідлок не в продакшені.