как я могу распечатать значения из файла dcn после определенного шаблона, найденного в Linux

1. Предположения

1.1 )По умолчанию ядро ​​Linux имеет код, сообщающий о различных типах сбоев или зависаний.

Все они могут показывать непосредственную проблему и печатать цепочку вызовов на "локальной консоли". Он может не показать основную причину, и этот код никогда не может быть на 100% надежным. Но обычно вы что-то получаете, и это намного лучше, чем ничего.

Таким образом, вы должны дважды -проверить, видите ли вы эти сообщения журнала ядра на консоли! Подробности в следующем разделе.

1.2 )Так как само ядро ​​по-прежнему отвечает на нажатия клавиш -и сетевые пакеты, я действительно ожидаю, что здесь сработает детектор зависших задач.

Похоже, что потоки ядра и прерывания все еще работают, но процессы пользовательского пространства зависают. Симптомы похожи на зависание, когда процессы пытаются получить доступ к физической файловой системе. Когда процесс зависает на несколько минут, ядро ​​выводит сообщение о зависании задачи и цепочку вызовов.

1.3 )В качестве альтернативы, пользовательские процессы могут быть не полностью зависшими, но они очень медленные, и вы не ждете "достаточно долго", чтобы увидеть их прогресс.

Возможно, вы знакомы с этой историей, если у вас есть опыт использования ПК с Linux с механическим жестким диском :-). Но так как это не ПК на вашем столе, вы не заметите сильного шума жесткого диска или постоянно горящего индикатора активности диска :-).

У меня нет опыта управления серверами. Но я думаю, что вы должны использовать программное обеспечение для мониторинга, чтобы попытаться обнаружить подобные проблемы. В идеале еще до того, как они создадут пользователю -видимые проблемы :-).

В качестве примера, если вы отслеживаете использование системной памяти,это может показать, есть ли у вас постепенная «утечка памяти», и система начинает менять себя до смерти. Я ожидаю, что у вас нет этой проблемы. Например. если бы loginбыл заменен, то вход в консоль был бы медленным, чтобы даже запрашивать ваш пароль.

Возможно, вы могли бы обнаружить увеличение дискового ввода-вывода за несколько секунд до наблюдаемого сбоя, если бы у вас был достаточно детальный -детальный мониторинг.

2. Инструкции

2.1 )Записывается ли "локальная консоль" в журнал или, по крайней мере, постоянна, чтобы вы заметили, если бы на ней был напечатан сбой ядра? Так и должно быть, но я не знаю, как будет работать vSphere и т. д., если вы используете эмулированную последовательную консоль. Если вы просто используете эмулированный видеодисплей, то он уже будет постоянным.

Эта статья VMWare , по-видимому, основывается на том же предположении.

2.2 )Убедитесь, что вы не отключили ведение журнала консоли. Запустите эту команду:

sudo sh -c "echo '<3>test' >/dev/kmsg"

На консоли должно отображаться слово «тест». См. также ниже, где я говорю о трассировке стека.

Если это эмулированный видеодисплей, часть сообщения о сбое может прокручиваться за пределы верхней части экрана. И если ядро ​​разбилось , то вы не можете использовать shift+PageUp для прокрутки вверх. В принципе, может быть полезнее иметь эмулированную последовательную консоль, реализующую прокрутку.

При сбоях ядра есть несколько других советов по аварийному дампу в приведенной выше ссылке на VMWare.

2.3 )Зависание после ввода пароля звучит так, будто диск перестал -отвечать. Я думаю, что Linux SCSI через некоторое время прекратит операции по тайм-ауту, и тайм-ауты будут зарегистрированы как ошибки ядра, поэтому Linux выведет их на консоль. Ваши файловые системы смонтированы по протоколу SCSI или как-то иначе?

2.4 )Также по умолчанию ядро ​​обнаруживает зависшие задачи и выводит сообщение:task bash:999 blocked for more than 120 seconds.За ним следует цепочка вызовов («трассировка стека» ). Хотя я думаю, что часть цепочки вызовов регистрируется с использованием «уровня журнала по умолчанию» ядра, что чаще всего означает предупреждение уровня 4 ().

Если вы хотите увидеть часть цепочки вызовов сообщения о зависшей задаче, вам, вероятно, потребуется увеличить уровень журнала консоли выше уровня 4, например. dmesg -n 5.

Чтобы убедиться, что вы не отключили сообщения о зависших задачах,:cat /proc/sys/kernel/hung_task_timeout_secsдолжно показывать положительное число, например. 120.

Сообщения о зависших задачах не печатаются для зависаний сетевой файловой системы . Они печатаются только тогда, когда зависшая задача одновременно является «непрерываемой» и «неубиваемой». Процессы, зависшие в NFS, можно убить . Если бы вы использовали сетевую файловую систему, которая могла вызвать это зависание, вы, вероятно, уже подумали бы об этом. (А так же тестирование подключения к серверу NFS каким-то образом, не просто тестирование зависшей ВМ с ping, а потом вы бы все это упомянули в вопросе :-). Если сервер NFS отвечает другим виртуальным машинам, но вы не видите сообщения о зависшей задаче на этой виртуальной машине, я думаю, вы можете попытаться выяснить это, используя sysrq+T (, см. ниже ).

Сообщения о зависших задачах включены по умолчанию в сборках Debian Linux. (По какой-то причине ядро ​​Fedora Linux собрано без включения детектора зависших задач. Несмотря на то, что он включен в ядра RHEL и SLES. ИСПРАВЛЕНИЕ ).

Когда я искал сообщения о зависших задачах, я заметил, что зависшие серверы и сообщения об ошибках ввода-вывода, похоже, являются общей темой :-).

Существует также Linux sysrq. Если у вас есть последовательная консоль, но вы можете записывать выходные данные только после подключения к ней, вы можете, например. попробуйте найти зависшие задачи с помощью sysrq+T . Это выводит информацию о каждой задаче в системе, поэтому он генерирует партию вывода на консоль.Так что это может быть не так полезно, когда ваша консоль представляет собой видеодисплей. И вы не должны тестировать это на работающей производственной системе! Некоторые дистрибутивы отключают sysrqпо умолчанию из соображений физической безопасности. Debian оставляет sysrqвключенным. Конечно, вы могли использовать контрольный список безопасности, в котором было сказано отключить sysrq.

2.4 )В первоначальном вопросе не упоминался количественный мониторинг «отзывчивости» ни непосредственно перед наблюдаемым сбоем, ни для демонстрации того, что система не часто перегружается (это может быть просто окончательным расширением ).

Примите во внимание значение количественного мониторинга «отзывчивости» службы, для различных служб -это может включать в себя вход на сервер ssh. Также уровни загрузки системы, задержки и количество сетевых пакетов в секунду.

П.С. оба disk busy% и "CPU iowait" могут быть прокляты. Я хотел бы также отслеживать текущие задержки диска и IOPS. (Текущие ядра Debian 9.x должны быть относительно разумны в отношении % занятости диска ).

Приведенный выше ответ и ссылка на VMware описывают некоторые стандартные инструменты, о которых вам следует узнать или, по крайней мере, знать об их существовании.

3. Тупой хак (, предполагающий, что ваши задачи зависают от доступа к файловой системе/диску)

Подробности ниже — тупой хак. Иногда тупой хак — это то, что вам нужно. Я просто говорю, что если вам придется прибегнуть к этому, это может указывать на некоторые недостатки в вашем способе работы, которые вам нужно устранить :-P.

Если у вас есть тесты оболочки, которые вы хотели бы запустить, когда система «почти -не отвечает», вы можете попробовать запустить mlock ()'ed busyboxоболочку. Например. запустите не статически связанный busybox, используя этот LD _PRELOAD mlock hack . Затем запустите команды busybox, используя, например. (exec -a ls /proc/self/exe /).Наверное, безопаснее всего:

# prevent you running any normal program by mistake!
OLDPATH="$PATH"
PATH=

# run a busybox builtin
b() (
  local command="$1"
  shift
  exec -a "$command" /proc/self/exe "$@"
)

# run normal program in the background, in case it hangs
p() {
  local PATH="$OLDPATH"
  exec "$@" &
}

Это должно позволить вам запустить b dmesgбез необходимости чтения какого-либо некешированного файла :-).

(Это не работает, если кто-то 1 )ухитрился смонтировать зависшую файловую систему 2 )смонтировал ее поверх /или /proc, так что вы даже не можете получить доступ к /procбез зависания. Я думаю, что это маловероятно, и было бы еще труднее защищаться от этого.)

b ps -o stat,pid,argsпокажет состояния процесса; Dозначает "непрерывный сон" -обычное ожидание дисковой или сетевой файловой системы. Затем b cat /proc/999/stackпокажет, где в ядре находится PID 999.

cd /sys/class/block/ && b grep -H. */inflightпокажет количество операций чтения и записи на лету для каждого диска.