Аварія сервера з символами ascii NUL в syslog (^ @ ^ @ ^ @…)


21

У мене є якийсь виділений сервер, розміщений OVH (французький постачальник послуг). ОС: Ubuntu 12.04 x64

Кілька місяців тому один з мого сервера розбився. Єдиним дивним явищем були деякі символи "ASCII NUL" в системі:

^ @ ^ @ ^ @ ^ @ ^ @ ^ @ ^ @ ^ @ ^ @ ^ @ ^ @ ^ @ ^ @ ^ @ ^ @ ^ @ ^ @ ^ @ ^ @ ^ @ ^ @ ^ @ ^ @ ^ @ @ ^ @ ^ @ ^ @ ^ @ ^ @ ^ @ ^ @ ^ @ ^ @ ^ @ ^ @ ^ @ ^ @ ^ @ ^ @ ^ @ ^ @ ^ @ ^ @ ^ @ ^ @ ^ @ ^ @ ^ @ @ ^ @ ^ @ ^ @ ^ @ ^ @ ^ @ ^ @ ^ @ ^ @ ^ @ ^ @ ^ @ ^ @ ^ @ ^ @ ^ @ ^ @ ^ @ ^ @ ^ @ ^ @ ^ @ ^ @ ^ @ @ ^ @ ^ @ ^ @ ^ @ ^ @ ^ @ ^ @ ^ @ ^ @ ^ @ ^ @ ^ @ ^ @ ^ @ ^ @ ^ @ ^ @ ^ @ ^ @ ^ @ ^ @ ^ @ ^ @ ^ @ @ ^ @ ^ @ ^ @ ^ @ ^ @ ^ @ ^ @ ^ @ ^ @ ^ @ ^ @ ^ @ ^ @ ^ @ ^ @ ^ @ ^ @ ^ @ ^ @ ^ @ ^ @ ^ @ ^ @ ^ @ @ ^ @ ^ @ ^ @ ^ @ ^ @ ^ @ ^ @ ^ @ ^ @ ^ @ ^ @ ^ @ ^ @ ^ @ ^ @ ^ @ ^ @ ^ @ ^ @ ^ @ ^ @ ^ @ ^ @ ^ @ @ ^ @ ^ @ ^ @ ^ @ ^ @ ^ @ ^ @ ^ @ ^ @ ^ @ ^ @ ^ @ ^ @ @ @ @

За допомогою мого постачальника послуг ми перевірили:

  • ОЗУ
  • Процесор
  • ДИСКИ

Все було нормально, тому мій постачальник послуг рекомендував змінити материнську плату сервера та оновити ядро ​​(що ми і зробили). Але з цього часу цей сервер вийшов з ладу ще два рази, з тими ж характеристиками в системі.

Не маючи більше пояснень, ми вирішили змінити цей сервер (це планується через кілька тижнів).

Але проблема полягає в тому, що цієї ночі це сталося з іншим сервером. Той самий збій, ті ж характеристики в системі, ніяких пояснень.

Чи є в когось поняття, що ми повинні перевірити? Це апаратне чи програмне забезпечення?


3
Ви знайшли рішення для цієї проблеми? В даний час я страждаю тим же питанням ...
BurninLeo

2
@BurninLeo: те саме тут
WoJ

Власне, я не знайшов рішення (на віртуальному сервері). Через деякий час і деякі (регулярні) оновлення стабільних випусків проблема зникла ...
BurninLeo

5
Байти NUL в системному журналі - це загальний ефект аварії, який заважав системі чітко синхронізувати та відключити файлову систему. Вони не вказують, що насправді спричинило аварію.
n.st

Відповіді:


8

Я поділюсь ширше чудовою відповіддю, яку дав @ n-st:

Байти NUL в системному журналі - це загальний ефект аварії, який заважав системі чітко синхронізувати та відключити файлову систему. Вони не вказують, що насправді спричинило аварію.

Дійсно, я часто бачив таку поведінку після збоїв на сервері: ці символи є NULL( \0) символами, які можуть являти собою відновлений блок, який був заповнений нулями деяким процесом відновлення.

Що стосується причини аварії, це зовсім інше питання - ви повинні надати спосіб більше інформації для діагностики , щоб навіть почати. Я б рекомендував відкрити інше питання з цього приводу, якщо у вас все ще є проблема.


-1

Якщо ви використовуєте текстовий редактор для перегляду файлів журналу, це може бути причиною;

  • ^@символи " " можуть вказувати на те, що рядок занадто довгий (наприклад: vimувімкнути обгортку )
  • Кодування є незбіжним; або використовувати інший текстовий редактор для перегляду файлу, або змінити використовуване кодування syslog.

4
У мене схожа проблема. Ні довгий рядок, ні кодування не пояснюють символи NUL в кінці syslog (скопіювали файл на зовнішній диск і відкрили його за допомогою кодування SciTE, UTF-8).
BurninLeo

Здається, ви можете відкрити закодований файл UTF-8 у редакторі, який не дуже добре розуміє UTF-8. Однак це може бути проблема CRLF (команди dos2unix та unix2dos можуть бути корисними)
Signal15

3
Байти NUL в системному журналі - це загальний ефект аварії, який заважав системі чітко синхронізувати та відключити файлову систему. Вони не вказують, що насправді спричинило аварію.
n.st

1
@ n.st Яка чудова відповідь! :) Ви повинні поставити це як "відповідь"
Signal15
Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.