BashTex | Linux

flock: защита от повторного запуска скрипта

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

Например, cron запускает задачу каждые 5 минут, но одна из прошлых итераций ещё не завершилась.

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

▪️Типичная ошибка

Допустим, скрипт выполняется 10 минут, а cron запускает его каждые 5:

*/5 * * * * /opt/backup.sh



Через некоторое время одновременно будут работать сразу несколько экземпляров.

▪️Решение через flock
Самый простой вариант - добавить блокировку:

flock -n /tmp/backup.lock /opt/backup.sh



Если lock-файл уже занят другим процессом, новая копия просто не запустится.

Ключ -n означает “не ждать освобождения блокировки”.

▪️Использование внутри скрипта

Можно защитить сам скрипт независимо от способа запуска:

exec 200>/var/run/myjob.lock

flock -n 200 || {
  echo "Already running"
  exit 1
}



Теперь второй экземпляр завершится сразу после старта.

▪️Чем лучше PID-файлов
Многие делают так:

echo $$ > /tmp/script.pid



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

▪️Где особенно полезно
Бэкапы, синхронизация файлов, обработка очередей, обновление данных, cron-задачи и любые скрипты, которые нельзя запускать параллельно.

BashTex 📱 #scripts #flock

systemd.path: запуск действия при изменении файла

Многие задачи автоматизации до сих пор решают через бесконечные циклы:

while true; do
  if [ -f /tmp/reload ]; then
    systemctl restart myapp
    rm /tmp/reload
  fi
  sleep 5
done



Работает, но процесс постоянно висит в памяти и каждые несколько секунд проверяет состояние файловой системы.

▪️ Что есть лучше

В systemd существует специальный тип юнитов — .path.

Он использует inotify и реагирует на реальные изменения файлов или директорий, а не занимается постоянным опросом.

Пример: нужно перезапускать сервис после изменения конфигурации.

Создаем path-юнит:

[Path]
PathModified=/etc/myapp/config.yml

[Install]
WantedBy=multi-user.target

И связанный сервис:

[Service]
Type=oneshot
ExecStart=/bin/systemctl restart myapp.service

Активируем:

systemctl daemon-reload
systemctl enable --now myapp.path



Теперь изменение файла автоматически вызовет запуск сервиса.

▪️ Что умеет отслеживать

Не только изменение файла:

PathExists=/tmp/file
PathChanged=/var/log/app.log
DirectoryNotEmpty=/var/spool/tasks



Например, можно запускать обработчик сразу после появления нового файла в директории или при заполнении очереди задач.

▪️ Почему это удобно
Вместо собственных демонов, cron и циклов с sleep получаем событийную модель: пока ничего не происходит - не расходуются ресурсы. Как только происходит нужное событие - systemd запускает действие.

BashTex 📱 #bash

🔥

BashTex 📱 #юмор

Скрипт проверки зависших mount

Иногда сервер начинает странно тормозить: команда df -h зависает, ls не отвечает, а проблема оказывается в примонтированной NFS/SMB/сетевой ФС. Причина простая: mount есть, но I/O к нему не отвечает.

Проверить это можно через связку: timeout + stat. Можно выполнить stat для точки монтирования, но ограничить время ожидания.

▪️ Пример ручной проверки

timeout 3 stat /mnt/backup

Если ФС отвечает - увидим информацию о каталоге. Если команда зависла и была остановлена по таймауту - mount подозрительный.

🛠 Скрипт проверки всех mount

#!/usr/bin/env bash

TIMEOUT=3

findmnt -rn -o TARGET | while read -r mountpoint; do
    if timeout "$TIMEOUT" stat "$mountpoint" >/dev/null 2>&1; then
        echo "OK: $mountpoint"
    else
        echo "HANG: $mountpoint"
    fi
done

Сохраняем:

nano check-mounts.sh

Делаем исполняемым:

chmod +x check-mounts.sh

Запускаем:

sudo ./check-mounts.sh

Пример вывода

OK: /
OK: /boot
OK: /home
HANG: /mnt/backup
HANG: /mnt/nfs-share

🛠 Также можно проверять только сетевые ФС

#!/usr/bin/env bash

TIMEOUT=3

findmnt -rn -t nfs,nfs4,cifs,smb3 -o TARGET | while read -r mountpoint; do
    if timeout "$TIMEOUT" stat "$mountpoint" >/dev/null 2>&1; then
        echo "OK: $mountpoint"
    else
        echo "HANG: $mountpoint"
    fi
done

Такой вариант удобнее для серверов, где много локальных mount.

⚠️ stat может зависнуть, если ядро ждет ответ от удаленного хранилища. Поэтому мы оборачиваем его в timeout. Без timeout ваш скрипт сам может зависнуть на проблемной точке монтирования.

▪️ Быстрая проверка одной строкой

findmnt -rn -o TARGET | while read -r mp; do
  timeout 3 stat "$mp" >/dev/null 2>&1 \
    && echo "OK: $mp" \
    || echo "HANG: $mp"
done

BashTex 📱 #mount #script

Как найти процессы, которые активно пишут на диск

1️⃣ iotop - самый быстрый способ

sudo iotop -o

Ключ -o показывает только процессы с активным I/O.

Для вывода без интерактивного режима:

sudo iotop -o -b -n 5

-b - batch mode
-n 5 - 5 обновлений и выход

Смотрите на колонки: DISK WRITE и COMMAND

2️⃣ pidstat - запись по процессам

pidstat -d 1

Показывает дисковую активность процессов каждую секунду. Главная колонка: kB_wr/s. Она показывает скорость записи на диск. Пример:

PID     kB_rd/s   kB_wr/s   Command
1245       0.00    820.00   rsyslogd
2178       0.00   4096.00   mysqld

3️⃣ Проверка через /proc. У каждого процесса есть файл:

/proc/<PID>/io

Посмотреть статистику:

sudo cat /proc/<PID>/io

Ищем строку: write_bytes: Она показывает, сколько байт процесс записал с момента запуска.

Быстрый топ процессов по записи:

for pid in /proc/[0-9]*; do
  [[ -r "$pid/io" ]] || continue
  wb=$(awk '/write_bytes/ {print $2}' "$pid/io" 2>/dev/null)
  cmd=$(cat "$pid/comm" 2>/dev/null)
  [[ "$wb" -gt 0 ]] && echo "$wb PID=${pid##*/} $cmd"
done | sort -nr | head

4️⃣ Какие файлы пишет процесс

sudo lsof -p <PID>

Например:

sudo lsof -p 2178

Так можно понять, какие файлы открыты у подозрительного процесса.

5️⃣ Небольшая итоговая шпаргалка

sudo iotop -o

Кто пишет на диск прямо сейчас.

pidstat -d 1

Скорость чтения/записи по процессам.

sudo cat /proc/<PID>/io

I/O-статистика процесса.

sudo lsof -p <PID>

Какие файлы открыл процесс.

BashTex 📱 #storage

Почему while read ломается в пайпах

Классическая ловушка Bash:

count=0

cat file.txt | while read -r line; do
  ((count++))
done

echo "$count"

Ожидание: увидим количество строк.
Реальность: 0.

▪️ Что произошло

Когда while read стоит справа от пайпа, цикл часто выполняется в subshell - дочернем процессе. То есть переменная count меняется не в текущем shell, а в его копии. После окончания цикла изменения исчезают.

▪️ Как делать правильно. Вариант 1: редирект файла вместо pipe

count=0

while IFS= read -r line; do
  ((count++))
done < file.txt

echo "$count"

Теперь цикл работает в текущем shell, и count сохраняется.

Вариант 2: process substitution. Если источник - команда, а не файл:

count=0

while IFS= read -r line; do
  ((count++))
done < <(grep ERROR app.log)

echo "$count"

<(...) подставляет вывод команды как файл, без subshell-проблемы в самом цикле.

▪️ Почему это важно

Ломаются не только счетчики. Точно так же исчезают:, массивы, флаги, накопленные строки и любые переменные, измененные внутри цикла

BashTex 📱 #bash

Файлы удалены, а место не освободилось

Классическая ситуация: удалили большой лог, df все еще показывает, что диск забит.
Ответ: файл удален из файловой системы, но процесс всё ещё держит его открытым.

▪️ Почему так происходит

В linux файл удаляется не сразу. Если процесс держит дескриптор: файл исчезает из каталога, но данные остаются на диске пока процесс не закроет файл


▪️ Как найти такие файлы

lsof | grep deleted

Пример вывода:

nginx   1234 user  10w  REG  ... /var/log/nginx/access.log (deleted)

Это значит: файл удален, но процесс nginx все еще его держит

▪️ Найти самые тяжелые

lsof -nP | grep deleted | sort -k7 -nr | head

Так можно быстро увидеть, кто реально съедает место.

▪️ Что делать

Вариант 1 - перезапустить сервис

systemctl restart nginx

Процесс закроет файл и место освободится.

Вариант 2 - убить процесс

kill 1234

(если можно безопасно остановить)

Вариант 3 - обнулить файл через

/proc
: > /proc/1234/fd/10

Где:

1234 - PID
10 - дескриптор из lsof

Это освободит место без перезапуска процесса.

BashTex 📱 #storage

Когда переменные пропадают

Одна из частых ловушек в bash - переменная изменилась… но снаружи осталась прежней. Причина почти всегда одна - subshell.

▪️ Что такое subshell. Subshell - это дочерний процесс bash. Он получает копию переменных, но изменения не возвращаются назад. Создается, например, здесь:

( command )

или в пайпах:

command | while read ...

▪️ Классическая проблема

count=0

echo -e "a\nb\nc" | while read -r line; do
  ((count++))
done

echo "$count"

Результат: 0

Почему? Цикл while выполняется в subshell.

▪️ Правильный вариант

count=0

while read -r line; do
  ((count++))
done < <(echo -e "a\nb\nc")

echo "$count"

Результат: 3

Теперь цикл работает в текущем shell.

▪️ Ещё пример

x=1

( x=5 )

echo "$x"

Результат: 1
Изменение потерялось.

▪️ Когда это полезно. Subshell - это не баг, а инструмент. Например:

( cd /tmp && ls )

внутри меняем каталог, а снаружи остаемся там же

BashTex 📱 #scripts

Вы бы знали, чего это стоило..

BashTex 📱 #юмор

Работа с сигналами: SIGTERM, SIGINT, SIGHUP

Любой процесс в linux можно остановить сигналом. Если скрипт их не обрабатывает - он просто умирает, иногда оставляя: временные файлы, lock-файлы или незавершённые операции

▪️ Основные сигналы

SIGINT - (2) - Ctrl+C
Остановка пользователем

SIGTERM (15) - вежливое завершение - systemctl stop / kill
Дает процессу шанс корректно завершиться.

SIGHUP (1) - перечитай конфиг
часто используется для reload

▪️ Обработка сигналов через trap

trap 'echo "Получен SIGINT"; cleanup; exit 1' INT
trap 'echo "Получен SIGTERM"; cleanup; exit 0' TERM

Теперь скрипт не просто падает, а выполняет cleanup.

▪️ Пример cleanup

cleanup() {
  echo "Чистка..."
  rm -f /tmp/my.lock
}

▪️ Полный пример

#!/usr/bin/env bash

LOCK=/tmp/job.lock
touch "$LOCK"

cleanup() {
  echo "Удаляю lock"
  rm -f "$LOCK"
}

trap cleanup EXIT
trap 'echo "SIGINT"; exit 1' INT
trap 'echo "SIGTERM"; exit 0' TERM

while true; do
  echo "Работаю..."
  sleep 2
done

Теперь:

Ctrl+C - корректное завершение
kill - cleanup выполняется
скрипт не оставляет мусор

Не все сигналы можно перехватить. Нельзя поймать: SIGKILL (9)
Если прилетит kill -9 - все, без cleanup.

BashTex 📱 #scripts #utils

Контроль роста логов systemd по сервисам

Когда /var/log начинает раздуваться, виноват почти всегда один-два шумных сервиса. Но в journald нет привычных файлов - значит нужно считать по-другому. Значит будем брать сервис, считать объем его логов и сравниваем во времени.

1️⃣ Сколько логов пишет сервис. Пример для nginx:

journalctl -u nginx --since "1 hour ago" | wc -c

Получаем объем логов за час (в байтах).

2️⃣ Быстрый топ шумных сервисов

systemctl list-units --type=service --no-legend | awk '{print $1}' |
while read -r svc; do
  size=$(journalctl -u "$svc" --since "1 hour ago" 2>/dev/null | wc -c)
  echo "$size $svc"
done | sort -nr | head

Результат:

12345678 docker.service
 9876543 nginx.service
 1234567 ssh.service

Сразу видно, кто генерирует больше всего логов.

3️⃣ Контроль роста. Сохраняем текущее состояние:

journalctl -u nginx --since "1 hour ago" | wc -c > /tmp/nginx.size

Через время:

old=$(cat /tmp/nginx.size)
new=$(journalctl -u nginx --since "1 hour ago" | wc -c)

echo "Рост: $((new - old)) байт"

4️⃣ Скрипт

#!/usr/bin/env bash

SINCE="10 min ago"
THRESHOLD=1000000  # 1 MB

systemctl list-units --type=service --no-legend | awk '{print $1}' |
while read -r svc; do
  size=$(journalctl -u "$svc" --since "$SINCE" 2>/dev/null | wc -c)
  
  if (( size > THRESHOLD )); then
    echo "ALERT: $svc → $size bytes за $SINCE"
  fi
done

BashTex 📱 #systemd #logs

Как правильно обрабатывать stdin в скриптах

Хороший CLI-скрипт должен уметь принимать данные: из файла, из pipe (|) и из stdin. И делать это предсказуемо.

▪️ Проверка: есть ли stdin

if [ -t 0 ]; then
  echo "stdin пуст (ввод с терминала)"
else
  echo "данные пришли через pipe"
fi

-t 0 - stdin подключен к терминалу
иначе - есть входной поток

▪️ Базовый шаблон

#!/usr/bin/env bash

if [ -t 0 ]; then
  echo "Usage: command < file | pipe"
  exit 1
fi

while IFS= read -r line; do
  echo ">> $line"
done

Теперь скрипт работает так:

cat file.txt | script.sh

▪️ Универсальный вариант (stdin + файл)

input="${1:-/dev/stdin}"

while IFS= read -r line; do
  echo "$line"
done < "$input"
Теперь можно:
script.sh file.txt
cat file.txt | script.sh

🤩 Частая ошибка

for line in $(cat file.txt); do
  echo "$line"
done

Она ломает: пробелы, табы и пустые строки

🤩 Правильно

while IFS= read -r line; do
  echo "$line"
done < file.txt

BashTex 📱 #scripts #stdin

Группировка команд {} против () - в чем реальная разница

В Bash есть два способа сгруппировать команды:
{ cmd1; cmd2; } и ( cmd1; cmd2 )

Снаружи выглядят почти одинаково. На практике - это разное поведение.

▪️ Главное отличие

Конструкция, где выполняется

{} - в текущем shell
() - в subshell (дочернем процессе)

▪️ Пример с переменными

count=0

{ count=5; }
echo "$count"

Результат: 5. Теперь с ():

count=0

( count=5 )
echo "$count"

Результат: 0. Переменная изменилась в subshell и пропала.

▪️ Практика: перенаправления. {} удобно для группового редиректа:

{
  echo "line1"
  echo "line2"
} > file.txt

Обе команды попадут в один файл.

▪️ Изоляция через (). Subshell полезен, когда нужно временно изменить окружение:

( cd /tmp && ls )

После выполнения ты останешься в текущем каталоге.

▪️ Типичный кейс

cd /tmp
do_something
cd -

Можно заменить:

( cd /tmp && do_something )

Без риска забыть вернуться обратно.

BashTex 📱 #bash

Проверка доступности файловых систем (read/write test)

▪️ Базовая проверка записи

touch /mnt/data/.test && rm /mnt/data/.test

Если команда зависает или падает - есть проблемы с файловой системой.

▪️Проверка с таймаутом

timeout 3 bash -c 'touch /mnt/data/.test && rm /mnt/data/.test'

Теперь: если FS зависла - команда завершится по таймауту, скрипт не повиснет

▪️ Измерение latency. Можно измерить время операции:

start=$(date +%s%N)

touch /mnt/data/.test && rm /mnt/data/.test

end=$(date +%s%N)
echo $(( (end - start)/1000000 )) ms

Если операция занимает:

<10 ms - нормально
100–500 ms - уже подозрительно
секунды - проблема

🛠 Готовый скрипт

#!/usr/bin/env bash

MOUNT="/mnt/data"
TIMEOUT=3

start=$(date +%s%N)

if timeout "$TIMEOUT" bash -c "touch $MOUNT/.test && rm $MOUNT/.test"; then
    end=$(date +%s%N)
    latency=$(( (end - start)/1000000 ))
    echo "OK ($latency ms)"
else
    echo "FAIL: FS недоступна или зависла"
fi

▪️ Проверка нескольких точек

for m in /data /backup /nfs; do
  echo -n "$m: "
  timeout 3 bash -c "touch $m/.test && rm $m/.test" \
    && echo "OK" || echo "FAIL"
done

BashTex 📱 #scripts #filesystem

И да, ему все еще не нужен ИИ

BashTex 📱 #юмор

Работа с exit codes: как правильно строить логику ошибок

В Bash каждая команда возвращает код завершения: 1 - успех, ≠0 - ошибка. И вся логика скрипта строится именно на этом.

▪️ Базовый принцип

command
echo $?

Но руками $? почти не используют, есть удобнее способы.

▪️ && - выполняй, если успешно

mkdir dir && cd dir

cd выполнится только если mkdir прошел успешно.

▪️ || - выполняй при ошибке

command || echo "Ошибка"

Полезно для fallback-логики.

▪️ Комбинируем

command && echo "OK" || echo "FAIL"

Но тут есть нюанс:

Если echo "OK" упадет (редко, но возможно), сработает || и ты получишь ложный FAIL.

Поэтому для критичной логики лучше:

if command; then
  echo "OK"
else
  echo "FAIL"
fi

▪️ set -e - автоматический выход при ошибке

set -e

Теперь скрипт завершится при любой ошибке. Но есть подводные камни:

set -e

grep "foo" file.txt
echo "done"

Если grep ничего не найдёт - exit code = 1 и скрипт завершится. Иногда это нормальное поведение, а не ошибка.

▪️ Правильное использование set -e. Обычно пишут так:

set -euo pipefail

Но при этом явно обрабатывают исключения:

grep "foo" file.txt || true

Или:

if grep -q "foo" file.txt; then
  echo "Found"
fi

▪️ pipefail - важно для пайпов

set -o pipefail

Без него:

false | true
echo $?   # → 0

С pipefail:

false | true
echo $?   # → ошибка

▪️ Общие правила:

&& - для цепочек успеха
|| - для fallback
if - для сложной логики
set -e - осторожно
pipefail - почти всегда включать

BashTex 📱 #bash

tee + process substitution: один поток и несколько получателей

Иногда нужно одновременно: увидеть вывод команды в терминале, записать его в файл и передать на обработку другой программе Если делать это по очереди - потеряется поток данных. Здесь помогает связка tee + process substitution.

▪️ Что делает tee. tee дублирует поток:

command | tee file.log

вывод остается в терминале и одновременно пишется в file.log

▪️ Несколько получателей. tee может писать сразу в несколько файлов:

command | tee out1.log out2.log

Но иногда нужно не просто файл, а другую команду.

▪️ Process substitution. Bash позволяет подставить вывод команды как файл:

>(command)

Это называется process substitution.

▪️ Комбинируем

command | tee >(grep ERROR > errors.log)

command генерирует поток
tee дублирует его

Одна копия идет в терминал, а другая в grep. Если найден ERROR, запись попадет в errors.log.

▪️ Более реальный пример. Допустим, идет сбор логов:

journalctl -f | tee >(grep ERROR >> errors.log)

Теперь: полный поток остается в терминале, ошибки автоматически сохраняются

▪️ Можно делать несколько обработчиков

journalctl -f | tee \
  >(grep ERROR >> errors.log) \
  >(grep WARN >> warn.log)

Один поток и сразу несколько фильтров.

BashTex 📱 #bash #utils

Где остаются следы SSH-подключений

Когда вы подключаетесь к серверу по SSH, система оставляет несколько артефактов. Это полезно знать не только с точки зрения безопасности, но и для диагностики и аудита.

Разберем основные места, где фиксируются подключения.

1️⃣ /var/log/auth.log - основной лог SSH. Каждое подключение к SSH фиксируется здесь. Быстро посмотреть успешные входы:

grep 'Accepted' /var/log/auth.log

Если система использует journald, записи можно посмотреть так:

journalctl -u ssh -r

-r покажет события в обратном порядке (сначала последние).

2️⃣ /var/log/wtmp - история логинов. Это бинарный лог, где хранится информация о: входах пользователей, IP-адресах, перезагрузках и выключениях системы. Смотреть его можно командой:

last

Полезный вариант с расширенной информацией:

last -Faiwx

3️⃣ /var/log/lastlog - последний вход каждого пользователя. Файл хранит последнюю дату входа для каждого системного пользователя. Посмотреть:

lastlog

Можно быстро увидеть: кто вообще заходил, когда был последний логин и с какого IP.

4️⃣ /var/run/utmp - текущие активные сессии. Пока пользователь подключен, информация о сессии хранится здесь. Посмотреть активные подключения:

who
#или
w

5️⃣ /var/log/btmp - неудачные попытки входа. Если кто-то ошибся с логином или паролем, запись попадет сюда. Посмотреть:

lastb

Полезно для поиска: ошибок авторизации или сканирования SSH.

6️⃣ ~/.bash_history - история команд. Все команды пользователя обычно сохраняются в файл:

~/.bash_history

Если не хотите записывать историю в файл (например, во время диагностики), можно временно отключить:

export HISTFILE=/dev/null

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

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

Поэтому в инфраструктурах часто используют: центральный syslog-сервер, systemd-journal-remote и централизованный сбор логов. Это позволяет видеть историю подключений даже если локальные логи были очищены.

BashTex 📱 #security

Проверка, какие сервисы работают без restart-policy и почему это риск

В systemd у каждого сервиса есть параметр: Restart=

Он определяет, будет ли сервис автоматически перезапущен, если процесс упал. Если политика не задана (Restart=no), сервис может просто умереть и никто его не поднимет. На продакшене это часто означает: API внезапно недоступен, очередь сообщений остановилась или воркер перестал обрабатывать задачи. И система жива, но функционально мертва.

▪️ Быстрая проверка одного сервиса

systemctl show nginx -p Restart

Пример:

Restart=always

или

Restart=no

▪️ Проверка всех сервисов. Можно быстро найти юниты без restart-policy:

systemctl list-units --type=service --no-legend | awk '{print $1}' |
while read -r svc; do
  policy=$(systemctl show "$svc" -p Restart --value)
  [[ "$policy" == "no" ]] && echo "$svc"
done

Скрипт выведет сервисы, которые не перезапускаются автоматически.

▪️ Хорошие варианты restart-policy. Чаще всего используют:

Restart=on-failure

или

Restart=always

Разница:

on-failure - перезапуск при ошибке
always - перезапуск всегда

▪️ Пример настройки. В unit-файле:

[Service]
Restart=on-failure
RestartSec=5

RestartSec добавляет паузу перед перезапуском. После изменения:

systemctl daemon-reload
systemctl restart myservice

BashTex 📱 #systemd

Ты ждал знак? Держи!

BashTex 📱 #юмор