4 дня из жизни unix-инженера, хроника разработки скрипта

[lockedpid]

И всё это лишь для того, чтобы не тратить 5 минут на установку node_exporter + Prometheus + Grafana?

[idler000]

Очевидно человек решает совсем другую задачу ( там же сказано что уже есть и grafana и zabbix) Не мониторинг, а локальное логирование, нечто наподобие SAR и Ораклового OSWatcher

[Fattakh]

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

[onix74]

Есть пара замечаний-вопросов...
1. По-моему, 'rm -f ${LOCKFILE}' лучше обрабатывать под TRAP. Например, так:

trap "{ rm -f ${LOCKFILE} ; exit 255; }" EXIT TERM
2. Всё-таки "блоК кода", а не "блоГ кода" (как минимум в двух местах встретил).
3. Не понял манипуляций с dir. Чем не устроила такая конструкция?
dir="RSS PAGE CPU1 CPU2 CPU3 SWAP IOTOP"

[Fattakh]

1. Можете наглядно продемонстрировать чем лучше? С удовольствием бы взял на вооружение.
2. Спасибо. Поправил.
3. Нет такого что чем-то не устраивает. Xargs принимает команды со стандартного ввода, разделенные пробелом или переводом строки. Поэтому допустимы оба варианта к использованию.

[dxp]

лучше хотя бы тем, что если скрипт упадет с ошибкой lockfile все равно удалится и не придется его чистить руками. exit 255 правда не к месту в случае нормального завершения ))

[onix74]

"exit 255" — для примера (хотя, да, немного странно :-) ). Можно возвращать любой удобный код.

[Fattakh]

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

[onix74]

п.1 — Вы, вроде, за производительность, однако в случае с cat:
real    0m0,005s
user    0m0,004s
sys     0m0,001s

в случае с константой:
real    0m0,002s
user    0m0,002s
sys     0m0,000s

Тест синтетический, типа такого:
#!/bin/bash

dir=$(cat <<EOF
RSS
PAGE
CPU1
CPU2
CPU3
SWAP
IOTOP
EOF
)

echo
echo ${dir}
и

#!/bin/bash

dir="RSS PAGE CPU1 CPU2 CPU3 SWAP IOTOP"

echo
echo ${dir}

[Fattakh]

Спасибо.
Вот тоже по Вашему примеру решил попробовать "синтетикой" поймать разницу между подачей аргументов на вход xargs с пробелом в качестве разделителя и с переносом строки.

# cat line.sh
#!/bin/bash
dir="RSS PAGE CPU1 CPU2 CPU3 SWAP IOTOP"
echo "$dir" | xargs -n 1 -P 4

# cat column.sh
#!/bin/bash
dir=$(cat <<EOF
RSS
PAGE
CPU1
CPU2
CPU3
SWAP
IOTOP
EOF
)
echo "$dir" | xargs -n 1 -P 4

Получились следующие результаты:

# time ./line.sh
RSS
PAGE
CPU1
CPU2
CPU3
SWAP
IOTOP

real    0m0.015s
user    0m0.008s
sys     0m0.008s

# time ./column.sh
RSS
PAGE
CPU1
CPU2
CPU3
SWAP
IOTOP

real    0m0.014s
user    0m0.006s
sys     0m0.010s

Плюс:

# time ./line.sh
RSS
PAGE
CPU1
CPU2
CPU3
SWAP
IOTOP

real    0m0.015s
user    0m0.008s
sys     0m0.008s

# time ./column.sh
RSS
PAGE
CPU1
CPU2
CPU3
SWAP
IOTOP

real    0m0.017s
user    0m0.005s
sys     0m0.013s

Какого-то существенного преимущества по времени не увидел.

[dab1818]

есть же http://manpages.org/dotlockfile

#локфайл на основе имени скрипта
LOCKFILE=${TMPDIR:-/tmp}/${0//\//_}.lock
#пытаемся залочить
if ! dotlockfile -p -l "$LOCKFILE" ; then
 echo "Program is already running: $LOCKFILE exists" >&2
 exit 1
fi

#тут ченить делаем

#снимаем блокировку
dotlockfile -p -u "$LOCKFILE"

[ViperRU]

Вот как он выглядит современный devops, пара десяток строчек скрипта десятком человек за почти неделю рабочего времени. Выше совет дали правильный, любой bash-скрипт должен начинаться c

#/bin/bash

set -euo pipefail

А особенно когда есть rm с переменной.

[Fattakh]

Не все так однозначно выглядит с включением опции pipefail при использовании set -e не смотря на тучу рекомендаций в сети использовать такую конструкцию для повышения безопасности использования shell-скриптов в Bash.
Обратимся к документации:

"The exit status of a pipeline is the exit status of the last command in the pipeline, unless the pipefail option is enabled (see The Set Builtin). If pipefail is enabled, the pipeline’s return status is the value of the last (rightmost) command to exit with a non-zero status, or zero if all commands exit successfully."

Получается, что в случае если команда, находящаяся где то в середине или начале конвеера завершится с ошибкой, то она останется незамеченной, а при использовании set -e просто не приведет к аварийному завершению скрипта.
Как предложенная защита поможет в случае с
echo "$dir" | xargs -n 1 -P 4 bash -c можете показать наглядно?