Анализ катастрофического отказа Ubuntu 12.04 - странные двоичные данные по всем открытым файлам во время катастрофического отказа
Несколько часов назад мы получили системный катастрофический отказ на Ubuntu 12.04. Мы проверили все файлы журнала и нет ничего подозрительного для обвинения к.
Последний материал, который был зарегистрирован, был некоторым действием голубятни. Нет никаких сообщений паники ядра.Ничего.
Это - новый сервер (новые аппаратные средства), мы тестируем перед производством. И потому что это новое твердый, я подозрителен, что проблема может произойти из-за некоторого неисправного оборудования.
Мы уже выполняем memtester без обнаруженной проблемы. Я буду рад получить известие от других аппаратных инструментов тестирования (машина имеет SSD).
Так или иначе вещью, я хотел спросить Вас, является другая. Странная вещь находится на каждом открытом файле во время катастрофического отказа, мы нашли, что следующая последовательность символов была записана в них: "^ @^ @^ @^ @^ @^...".
Например, на файле журнала системного журнала мы добрались:
Apr 16 15:53:56 odyssey dovecot: pop3-login: Aborted login (auth failed, 1 attempts): user=<info>, method=PLAIN, rip=46.29.255.73, lip=5.9.58.177
^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^ [these continues for about 1000 chars...] ^@^@^@^@Apr 16 15:55:12 odyssey kernel: imklog 5.8.6, log source = /proc/kmsg started.
Мы получили все эти символы во всех открытых файлах. Они включают: системный журнал, mail.log, kern.log... Но также и на некоторых журналах, которые производятся сценариями PHP, выполненными в КРОНАХ от учетных записей пользователей (не корень).
Так, какая-либо идея, почему все открытые файлы записали эти символы во время катастрофического отказа? Это довольно плохо, так как катастрофический отказ повредил много файлов (мы даже не знаем, который другие могут быть затронуты). Мы подозрительны, что все открытые файлы (в режиме записи, возможно) во время катастрофического отказа получили все эти вставленные символы. Почему это?
BTW [в случае, если это помогает], система, автоматически перезагруженная после катастрофического отказа, но Apache не запускался. Не было трассировок в/var/apache2 / *log, почему апач не запустил. После выполнения "сервиса запускаются apache2", оно запустилось без проблем. Кроме того, мы перезагрузили машину вручную и Apache, также запущенный на перезагрузке. Но это не запускалось после того, как о катастрофическом отказе и никаких ошибках сообщили.
Спасибо, ребята!
Те ^ @ почти наверняка двоичные нули. То есть xxd коррумпированный файл | tail -3 , вероятно, выдаст что-то вроде:
#######0: 0000 0000 0000 0000 0000 0000 0000 0000 ................
#######0: 0000 0000 0000 0000 0000 0000 0000 0000 ................
#######0: 0000 0000 0000 0000 0000 0000 0000 0000 ................
Ядру поступил сигнал о записи, но содержимое не было сброшено на диск. Таким образом, файл был расширен в ожидании записи, поэтому файл был непреднамеренно разреженным.
Это особенно вероятно, если вы не используете журналируемую файловую систему, поскольку журнал должен вызывать запись для отката, если он не был завершен должным образом (а это не так из-за сбоя).