Назад | Перейти на главную страницу

Как защитить сценарий оболочки от выхода из-под контроля?

Недавно у меня был опыт написания сценария оболочки, который приводил к сбою сервера (и повреждению раздела), потребляя все ресурсы. Он был подключен к заданию cron, и, похоже, его выполнение заняло больше времени, чем интервал между выполнениями, со временем выходя из-под контроля.

С тех пор я изменил его, чтобы записывать его рабочее состояние и не запускать более одного раза одновременно. Мой вопрос: есть ли другие простые способы защитить сценарий от причинения вреда? Есть ли стандартный список того, что должен делать скрипт, чтобы вести себя должным образом, не потреблять слишком много ресурсов, корректно выходить из строя, предупреждать нужных людей и т. Д.?

В основном: каких еще подводных камней мне следует избегать?

Компьютеры делают именно то, что им говорят. Единственный способ гарантировать, что сценарий «ведет себя должным образом» - это написать его так, чтобы он работал правильно во всех сценариях.

Несколько основных советов:

Внедрите какую-то систему мониторинга.
Тот факт, что ваша система взорвалась без вашего ведома, говорит мне, что у вас либо нет системы мониторинга, либо ваша текущая система недостаточно хороша.
Потратьте некоторое время на то, чтобы убедиться, что ваши серверы сообщают вам о проблеме перед они падают.
Включите соответствующие меры безопасности в скрипты, запускаемые из cron.
Ваш сценарий наступил себе на хвост. Этого не должно быть.
Вы на собственном горьком опыте узнали, что вам нужно защищаться от подобных вещей (и пусть система уведомит вас, если это произойдет).
Проектируйте и тестируйте более тщательно.
Тщательно оцените каждый сценарий, который вы собираетесь развернуть, чтобы убедиться, что он не вызовет нежелательных побочных эффектов. Если вы можете представить себе сценарий отказа, проверьте его (и обработайте его правильно!).
Найдите время, чтобы смоделировать сбои (либо жестко закодировав условие как истинное в сценарии, либо создав обстоятельства для проверки вашей логики обнаружения.

В конце концов, мы запускаем скрипт внутри виртуальной машины. Это значительно ограничивает размер ущерба, который может быть нанесен.

В Linux пугает (по крайней мере, для меня) то, что незначительные опечатки или ошибки могут иметь разрушительные последствия. Даже что-то вроде запуска команды с $ {VARIABLE} может иметь совершенно другое (и деструктивное) значение, если эта переменная пуста или содержит пробел.

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

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