Проверка настроек до прогона: короткий чек-скрипт

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

#!/usr/bin/env bash
set -u
ADR=$(curl -s --max-time 10 https://api.ipify.org) || ADR=пусто
echo "внешний адрес: $ADR"
KOD=$(curl -s -o /dev/null -w "%{http_code}" --max-time 15 https://example.org/catalog/1)
echo "код цели: $KOD"
MB=$(df -Pm . | awk 'NR==2{print $4}')
echo "свободно мегабайт: $MB"
echo "переменные: ${HTTPS_PROXY:-нет}"
wc -l < spisok.txt

Что сюда добавить, чтобы закрыть остальные грабли? Интересует живой опыт.

Часы добавьте. Расхождение на пару минут ломает сессии и подписи, а в логе вы увидите обычный отказ доступа и полезете искать вину в скрипте.

timedatectl show -p NTPSynchronized --value

Ответ no означает, что прогон запускать рано.

И код возврата поставьте, иначе проверка превращается в красивую печать в консоль. У меня скрипт заканчивается выходом с единицей, а запуск прогона идёт следующей строкой через двойной амперсанд. Не прошло, дальше просто ничего не случилось.

Виноват, ровно так и было. Переделал: каждая проверка пишет строку и копит счётчик, в конце exit по счётчику.

а по списку адресов какой порог ставить? если два из десяти молчат, это уже стоп или норм

Женя, десяти мало для вывода. Берите выборку штук на двадцать, случайную, и смотрите долю. Ниже восьмидесяти процентов живых имеет смысл притормозить и разобраться. Одиночное молчание чаще означает занятый узел на той стороне, к следующей попытке он отвечает.

И проверяйте полным запросом к своей цели. Открытие сокета проходит почти всегда, толку от такой проверки мало.

Важная мелочь, про которую забывают: проверку надо гонять тем же путём, что и прогон. Тот же пользователь, тот же рабочий каталог, тот же набор переменных. Я месяц наблюдала картину, где чек из-под себя зелёный, а служба из-под своего пользователя падает на первом запросе, потому что переменные ей приходили из другого файла.

Настя, в точку. Повесил чек как ExecStartPre в том же юните, где и сам прогон. Разом отпало три вопроса.

Раз тема живая, поделюсь тем, к чему пришёл за несколько сотен ночных прогонов.

Проверок у меня две, и они разные по весу. Быстрая идёт перед каждым стартом, укладывается в десять секунд и трогает только то, что ломается часто: доступность цели, внешний адрес, часы, место на диске, свежесть списка. Медленная гоняется раз в сутки, там уже выборка адресов, замер отклика по медиане, разбор одной карточки с проверкой заполненности полей и запись результата в историю.

История важнее самого факта проверки. Каждый запуск дописывает строку с датой, откликом и долей живых. Через неделю видно движение: отклик пополз вверх задолго до того, как прогон начал спотыкаться. Без истории вы каждый раз смотрите на один снимок и понятия не имеете, норма это или уже беда.

Второе правило: проверка мягче прогона. Если чек требует девяносто пять процентов живых, а прогон спокойно работает на семидесяти, вы будете сидеть с красным чеком при исправной системе и через месяц перестанете на него смотреть.

Третье: сообщение об отказе пишите словами. Фразой вида «часы разошлись, синхронизация выключена». Код возврата и имя функции в четыре утра читаются плохо.

Про мягкость подпишусь двумя руками. У меня чек полгода стоял строже прогона, кончилось тем, что все привыкли запускать с ключом обхода проверки.

записал, спасибо. попробую сегодня же

Итог для тех, кто найдёт тему поиском. Добавил часы, код возврата, историю в одну строку и повесил всё как ExecStartPre. За две недели чек трижды остановил старт: дважды разъехались часы после переезда машины, один раз кончилось место под сырьё. Оба случая раньше стоили бы мне ночи.