Что * точно * становится ошибочным, когда я убиваю -9 или отключаю питание?


13

Настроить

Я был программистом в течение довольно долгого времени, но я все еще немного размыт о глубоких, внутренних вещах.

Сейчас. Я хорошо знаю, что это тоже не очень хорошая идея:

  1. убить -9 процесс (плохо)
  2. самопроизвольно отсоединяйте шнур питания на работающем компьютере или сервере (что еще хуже)

Тем не менее, иногда вы просто должны. Иногда процесс просто не отвечает, независимо от того, что вы делаете, а иногда компьютер просто не отвечает, независимо от того, что вы делаете.

Давайте предположим, что система работает под управлением Apache 2, MySQL 5, PHP 5 и Python 2.6.5 через mod_wsgi.

Примечание: меня больше всего интересует Mac OS X здесь, но ответ, который относится к любой системе UNIX, помог бы мне.

Моя забота

Каждый раз, когда мне приходится делать что-то одно, особенно второе, я очень переживаю, что что-то сломалось. Какой-то файл может быть поврежден - кто знает, какой файл? На компьютере более 1 000 000 файлов.

Я часто использую OS X, поэтому я запускаю операцию «Проверка диска» через Дисковую утилиту. Это не сообщит о проблемах, но я все еще обеспокоен этим.

Что, если какой-то файл конфигурации где-то облажался. Или еще хуже, что если бинарный файл где-то поврежден. Или файл сценария где-то поврежден сейчас. Что если какое-то оборудование повреждено?

Что если я не узнаю об этом до следующего месяца, в критическом сценарии, когда коррупция или ущерб приведут к катастрофе?

Или что, если ценные данные уже потеряны?

Я надеюсь

Я надеюсь, что эти проблемы и заботы беспочвенны. В конце концов, после того, как мы проделали это много раз, ничего по-настоящему плохого еще не произошло. Хуже всего то, что мне пришлось восстанавливать некоторые таблицы MySQL, но я не потерял никаких данных.

Но если мои опасения не беспочвенны, и реальный ущерб может произойти в любой ситуации 1 или 2, то я надеюсь, что есть способ обнаружить это и предотвратить против него.

Мои вопросы)

Может ли это быть из-за того, что современные операционные системы предназначены для того, чтобы в этих сценариях ничего не терялось? Может ли это быть потому, что современное программное обеспечение разработано так, чтобы ничего не потеряно? А как насчет современного аппаратного дизайна? Какие меры принимаются, когда вы вытягиваете вилку из розетки?

Мой вопрос заключается в том, что для обоих этих сценариев, что именно может пойти не так, и какие шаги необходимо предпринять, чтобы это исправить?

У меня сложилось впечатление, что одна вещь, которая может пойти не так, это то, что некоторые программы могли не сбрасывать свои данные на диск, поэтому любые последние данные, которые должны были быть записаны на диск (скажем, за несколько секунд до отключения питания) может быть потеряно Но как насчет этого? И может ли эта проблема потери данных за 5 секунд испортить систему?

Как насчет повреждения случайных файлов, скрывающихся где-то в огромном лесу файлов на моих жестких дисках?

Как насчет повреждения оборудования?

Что бы мне больше всего помогло

  1. Подробное описание того, что происходит внутри, когда вы либо убиваете -9 процесс, либо отключаете питание всей системы. (кажется мгновенным, но кто-то может замедлить это для меня?)

  2. Объяснения всех вещей, которые могут пойти не так в этих сценариях, наряду с (грубо конечно) вероятностями (то есть, это очень маловероятно, но это вероятно) ...

  3. Описание мер, применяемых в современном оборудовании, операционных системах и программном обеспечении, для предотвращения повреждения или повреждения в случае возникновения таких сценариев. (чтобы успокоить меня)

  4. Инструкции о том, что делать после kill -9 или выключения питания, помимо «проверки диска», чтобы действительно убедиться, что ничто не повреждено или повреждено где-то на диске.

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

  6. Некоторая информация о двоичных файлах - не правда ли, что двоичный файл apache или какая-либо библиотека могут иметь случайный байт или два поврежденных посередине, которые не появятся и не вызовут проблему позже? Как я могу убедить себя, что это не произошло в результате отключения власти или убийства?

Спасибо!


Какие процессы вы отправляете kill -9? Вы упоминаете «Apache 2, MySQL 5, PHP 5 и Python 2.6.5 через mod_wsgi». Ты убиваешь некоторых из них? Знание того, что вы убиваете, позволит более целенаправленно реагировать на последствия этого. Кроме того, что на самом деле происходит, чтобы заставить вас хотеть убить процессы. Знайте это и, возможно, сможете определить коренные причины вашей проблемы, а не просто понять значение метода грубой силы, чтобы решить ее. Кстати, на MacOS X для современных машин нажатие кнопки питания в течение 10 секунд, а не просто отключение питания, является менее жестоким.
Грэм Дамплтон

Я не знаю, что такое kill -9, но если у вас нет какого-либо резервного источника питания, я думаю, можно с уверенностью сказать, что ВСЕ убивается, когда вы отключаете питание.
Джон Гарденье

Ответы:


9

Вытягивание силы заставляет все остановиться в полете, без предупреждения. kill -9 имеет тот же эффект на один процесс, принудительно завершая его SIGKILL .

Если процесс убит ядром или отключением питания, он не выполняет никакой очистки. Это означает, что вы можете иметь наполовину записанные файлы, несовместимые состояния или потерянные кэши. Обычно вам не нужно беспокоиться об этом из-за журналирования, состояния выхода и резервной батареи.

Временные файлы в / tmp будут автоматически удалены, если они находятся в tmpfs, но у вас все еще могут быть файлы блокировки приложений, которые можно удалить, например, lock и .parentlock для firefox.

Большая часть программного обеспечения достаточно умна, чтобы повторить транзакцию, если она не записывает статус успешного завершения. Хорошим примером этого является типичная почтовая система. Если сообщение доставляется, но прерывается посередине, отправитель повторяет попытку позже, пока не получит успех.

Ваша файловая система, вероятно, занесена в журнал. Если вы перемещаете или пишете файл, и он умирает в середине потока, журнализированная файловая система все равно будет ссылаться на оригинал. Журнализированная файловая система будет вносить изменения неразрушающим образом, оставляя старую копию, а затем ссылаться на новую копию только в качестве последнего шага, прежде чем освободить место, которое старые копии занимали на диске.

Теперь, если у вас есть RAID-массив, он имеет все виды буферов памяти для повышения производительности и обеспечения надежности при сбое питания. Скорее всего, ваша файловая система не будет знать о кэшах в устройстве и их состоянии, поэтому она думает, что изменение было зафиксировано на диске, но оно все еще находится где-то в кеше RAID. Так что же происходит, когда власть умирает? Надеюсь, у вас есть функциональная батарея в корпусе RAID, и вы следите за ней. В противном случае у вас есть испорченная файловая система для fsck.

Да, несколько бит могут быть повреждены в двоичном файле, но я бы не стал беспокоиться об этом на современном оборудовании. Если вы действительно параноик, вы можете следить за состоянием ваших дисков и RAID с помощью соответствующих инструментов, но вы все равно должны это делать. Регулярно делайте резервные копии и получайте источники бесперебойного питания.


5

При неожиданном завершении работы единственные файлы, которые должны быть повреждены, - это файлы, которые открыты для записи. В большинстве систем в любой момент времени вы, вероятно, не записываете в файл. Наверное.

1 убийство -9

это POSIX SIGKILL и зависит от реализации. Процесс, который получает этот сигнал, не будет иметь возможности обработать его.

1 выключение

зависит от оборудования. Автопарковка головок при импульсе накопителя и все в вашем кэше записи теряет обновление DRAM и в течение нескольких секунд приводит к необратимому повреждению. То же самое происходит с вашей системной памятью, кэшем процессора, регистрами и т. Д.

От wdc.com (google: site: wdc.com Защитная головка парковки)

Питание потеряно: жесткий диск сброшен. Головка припаркована в зоне посадки, используя энергию шпинделя. Двигатель шпинделя остановлен.

2 - что может пойти не так

открытые файлы записаны не полностью. Если файл открыт для записи, произойдет повреждение данных. Запись файлов на современном оборудовании выполняется быстро, и современные компьютеры обычно не испытывают стресс при вводе-выводе. Это как ходить с завязанными глазами по тихой проселочной дороге. Большую часть времени вы будете в порядке.

3 - контрмеры

см. выше для того, что делают диски.

Посмотрите журнальные файловые системы, теперь они нормальные: http://en.wikipedia.org/wiki/Journaling_file_system

Программное обеспечение, такое как MS Word или vi, будет записывать во временный файл, а не в исходный. Цель состоит в том, чтобы никогда не оставлять систему в состоянии, когда на диске нет единой копии.

Windows хранит копии реестра (это слишком важно). Википедия: «Windows 2000 хранит альтернативную копию кустов реестра (.ALT) и пытается переключиться на нее при обнаружении повреждения» (с тех пор я не оказывал техническую поддержку Win2k, так что я не уверен, каковы новые механизмы MS)

4 - что делать

В порядке сложности (легко-трудно)

  • Храните резервные копии
  • Проверьте, над чем вы в последний раз работали
  • Загрузитесь с отдельного диска и найдите последние измененные даты / время, чтобы выяснить, что система могла делать во время сбоя
  • Загрузитесь с отдельного диска и сравните md5sums всех ваших файлов с автономной копией.

Хранить резервные копии - наиболее подходящий ответ, хорошие резервные копии должны позволить вам вернуться к ранее измененной версии.

5

Избыточная мощность? Обучение конечных пользователей? положить ленту и картон поверх кнопки питания?

6

Если не считать аппаратных сбоев, поврежденных драйверов дисков, сломанного ядра ОС, отсутствия контрольных сумм или сбоев во время обновлений, двоичные файлы и библиотеки не открываются для чтения-записи, поэтому они не повреждаются. Такое бывает, но это редко.


+1 за точку № 6
Bigbio2002

4

Что касается kill -9, это посылает процессу сигнал «умереть» прямо на месте. Процесс умирает (если он не находится в непрерывном сне, и в этом случае он становится зомби). Файлы не закрываются, данные не записываются, и программа не может перехватить этот сигнал и сделать что-то еще. Нет очистки, нет ничего: он просто умирает.

Файловые системы сегодня очень надежны; такие вещи, как XFS, JFS, ext3 и ext4, все имеют журналы и другие вещи, чтобы сохранить метаданные файловой системы нетронутыми.

Двоичные файлы, такие как сам Apache и другие, вряд ли повредятся из-за внезапной потери питания или из-за системного сбоя, так как они находятся в памяти или читаются; если они читаются из (например, Apache HTTP запускается), возможно, что скачок напряжения может повредить двоичный файл, но это кажется маловероятным.

У меня есть Mac Mini, люди, кажется, любят отключаться от холода (независимо от того, сколько раз я им говорю…), и он просто продолжается.

По большей части, до тех пор, пока вы не полагаетесь на kill -9 или регулярное отключение питания, я бы не слишком волновался. В прошлом все было намного хуже; Я бы больше беспокоился о (например) Solaris 2.6, чем о Solaris 10 (и так далее).



3

«Kill -9» не синхронизирует ожидающую операцию ввода-вывода. Это часто не проблема, но если система находится под большой нагрузкой ввода-вывода, вы можете потерять данные.

Это большая проблема с серверами, где контроллер RAID (без кэша с резервным питанием от батареи) может кэшировать записи и потерять ваши данные.

Редактировать : еще одна вещь ... если вы зависите от сетевых дисков и у вас есть открытые дескрипторы файлов, вы, скорее всего, оставите файл несогласованным или поврежденным. В Windows классический пример этого, где вы видите это, когда пользователи монтируют файлы Outlook PST в общий ресурс и теряют питание или подключение к сети.

Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.