Сбоивядре Linux приводятквозникновениючрезвычайноразнообразныхсимптомов. Некоторыеавторыдаютследующуюнеполнуюклассификациюпроблем, скоторымиможетстолкнутьсяпользователь:
Ксчастью, ядрообладаетнекимнаборомсредствпервичнойсамодиагностики, пригоднымдляпостановкипримерногодиагноза. Согласно, видимовсеобщей, философскойпарадигме, наиболееустойчивымиинадежнымиявляютсянаиболеепростыеподсистемы, поэтомусообщенияядраимеетсмыслискатьвтекстовойипоследовательнойконсолях. Конечно, придостаточномуровневезениянужноесообщениебудетсброшено syslog-демону, записанонадиск, отправленопосетинаудаленный syslog-демонипрочее, нопринедостаточномвезениимонитор (ифотоаппаратнателефоне), клавиатураи COM-портявляютсяпоследнейнадеждой.
Однимизмеханизмовобщенияядрасвнешниммиромявляется printk. Принеправильнойнастройкесообщениескореевсегобудетпростопотерянокакнеобладающеезначимостью. Длянастройкииспользуется/proc/sys/kernel/printk, соответствующийемупараметр sysctl, утилитаklogconsole, SysRq-клавишаит.п. Ядрообладаетвосемьюуровнямиважностисообщений, поэтомуустановкауровняв 8 заведомонапечатаетвсенаконсоль.
Магическаякнопкавключаетсяв/proc/sys/kernel/sysrqилисоответствующимемупараметром sysctl. Предлагаетсяпростозаписатьтуда 1, несмотрянато, чтоновыеядрапозволяютизысканныйконтрольнадфункционалом. Вданнойситуациинезачемсебяограничивать, хотядлянормальнойработыразумноограничитьфункционалнаслучайслучайныхнажатий. Еслиосталасьрабочаятерминальнаясессия (напримерудаленнаясессияпо ssh), можноиспользоватькакальтернативу, например, echo b > /proc/sysrq-trigger; споследовательнойконсолиповедениеактивируетсякнопкой 'break'.
Важнопомнить, что SysRq-w, например, выдаетсообщениесуровнемKERN_INFO, тоестьвыдача printk должнабытьнастроенаправильно, чтобыможнобылочто-тоувидеть. Полныйсписоккоманд SysRq.
Параметрядраsoftlockup_panicилипараметрkernel.softlockup_panicдля sysctl включаютпаникуядраприобнаружении soft lockup. Описаниевнутреннегоустройства. Включениепаникипозволитостановитьвыполнениесистемыипроанализироватьвыдачу, снабженнуютрассировкой, хотяконтрольблокировкиисполняетсяпостоянно. Существуетаналогичныймеханизмотслеживания hard lockup длямногопроцессорныхсистем (еслиосталисьживыепроцессоры—естьшансчтосработает), ссоответствующимпараметромhardlockup_panic. Времясрабатыванияобычновпределаходнойминуты.
Механизмотслеживанияпроцессов, надолгозастрявшихвсостоянии TASK_UNINTERRUPTIBLE, параметрынастраиваютсячерез sysctl и/proc:
- kernel oops —проблемапривыполнениикодавядре, напримеркто-нибудьпопыталсяразыменоватьнулевойуказатель. Скемизпрограммистовна C такогонеслучалось?
- kernel panic —кто-топопыталсяразыменоватьнулевойуказательвобработчикепрерываний. Послечегоядроуходитвполнуюнесознанкуиначинаетмигать caps-lock-ом.
- soft lockup —что-тозаблокировалось (вероятнонаткнувшисьнанеосвобожденнуюблокировку), несмотрянаэтопрерыванияпродолжаютобрабатываться. Хорошееупражнение—попинговатьмашинуилипопытатьсязажечь numlock.
- hard lockup —компьютержужжитвентиляторамиининачтонереагирует. Провестикакую-тодиагностикувэтомслучаеособенносложно. Проблемаможетбытьвызванакаквышедшимизстрояжелезом, такинеаккуратнойобработкойпрерываний.
- hung —индуцированноенеправильнойблокировкойпоследовательноепопаданиевсехилибольшинствапроцессовсистемывсостояние TASK_UNINTERRUPTIBLE (известноготак-жекак D-состояние, пообозначениювtopилиps). СогласнокнигеР.Лаватакой«наводящийужас»процесснельзяубить, завершить, ивообщечто-тоснимсделать. Приэтомсточкизренияпространствапользователяпрограммапростозаблокировананакаком-тосистемномвызове (напримерввода-вывода). Припопаданиивподобноесостояниевсехкритическихпроцессовсистемыможнополучитьсимптомпохожийна soft lockup.
Ксчастью, ядрообладаетнекимнаборомсредствпервичнойсамодиагностики, пригоднымдляпостановкипримерногодиагноза. Согласно, видимовсеобщей, философскойпарадигме, наиболееустойчивымиинадежнымиявляютсянаиболеепростыеподсистемы, поэтомусообщенияядраимеетсмыслискатьвтекстовойипоследовательнойконсолях. Конечно, придостаточномуровневезениянужноесообщениебудетсброшено syslog-демону, записанонадиск, отправленопосетинаудаленный syslog-демонипрочее, нопринедостаточномвезениимонитор (ифотоаппаратнателефоне), клавиатураи COM-портявляютсяпоследнейнадеждой.
printk
Однимизмеханизмовобщенияядрасвнешниммиромявляется printk. Принеправильнойнастройкесообщениескореевсегобудетпростопотерянокакнеобладающеезначимостью. Длянастройкииспользуется/proc/sys/kernel/printk, соответствующийемупараметр sysctl, утилитаklogconsole, SysRq-клавишаит.п. Ядрообладаетвосемьюуровнямиважностисообщений, поэтомуустановкауровняв 8 заведомонапечатаетвсенаконсоль.
sysrq
Магическаякнопкавключаетсяв/proc/sys/kernel/sysrqилисоответствующимемупараметром sysctl. Предлагаетсяпростозаписатьтуда 1, несмотрянато, чтоновыеядрапозволяютизысканныйконтрольнадфункционалом. Вданнойситуациинезачемсебяограничивать, хотядлянормальнойработыразумноограничитьфункционалнаслучайслучайныхнажатий. Еслиосталасьрабочаятерминальнаясессия (напримерудаленнаясессияпо ssh), можноиспользоватькакальтернативу, например, echo b > /proc/sysrq-trigger; споследовательнойконсолиповедениеактивируетсякнопкой 'break'.
Важнопомнить, что SysRq-w, например, выдаетсообщениесуровнемKERN_INFO, тоестьвыдача printk должнабытьнастроенаправильно, чтобыможнобылочто-тоувидеть. Полныйсписоккоманд SysRq.
softlockup_panic
Параметрядраsoftlockup_panicилипараметрkernel.softlockup_panicдля sysctl включаютпаникуядраприобнаружении soft lockup. Описаниевнутреннегоустройства. Включениепаникипозволитостановитьвыполнениесистемыипроанализироватьвыдачу, снабженнуютрассировкой, хотяконтрольблокировкиисполняетсяпостоянно. Существуетаналогичныймеханизмотслеживания hard lockup длямногопроцессорныхсистем (еслиосталисьживыепроцессоры—естьшансчтосработает), ссоответствующимпараметромhardlockup_panic. Времясрабатыванияобычновпределаходнойминуты.
hung_task_timeout_sec
Механизмотслеживанияпроцессов, надолгозастрявшихвсостоянии TASK_UNINTERRUPTIBLE, параметрынастраиваютсячерез sysctl и/proc:
- kernel.hung_task_panic —включает/отключаетпаникуприобнаружениинепрерываемогопроцесса;
- kernel.hung_task_warnings —счетчиксообщений. Инымисловами, еслипаникаотключена, будетсообщеноотакомколичествезависшихпроцессов;
- kernel.hung_task_timeout_secs —сколькосекундпроцессдолженнепрерывнопробытьв TASK_UNINTERRUPTIBLE, чтобывызватьсообщение. Поумолчаниюбываетлибовыключено (0), либооченьбольшоечислопорядка 10 минут.