Files
resume/stack/linux-bash/CASE.md

7.0 KiB
Raw Permalink Blame History

Кейс: Linux (Astra/CentOS) и Bash — диагностика и внутренности

Связь с легендой: ../../legend/LEGEND.md — Astra Linux (АО ТНИИС) как базовая ОС серверного парка, CentOS (ОКБ СУХОЙ) как ОС тестовых стендов, Bash — повседневная автоматизация в обеих ролях.

Что нужно реально сделать

Практикум на Linux-контейнере/WSL: живые bash-скрипты для обслуживания и прогон диагностических сценариев, которые реально спрашивали на собеседованиях («сервер тормозит — с чего начнёшь», «упал сервер — что делать»).

1. Реальные bash-скрипты для обслуживания

Ротация и архивация логов:

#!/usr/bin/env bash
set -euo pipefail

LOG_DIR="/var/log/myapp"
ARCHIVE_DIR="/var/log/myapp/archive"
DAYS_TO_KEEP=7

mkdir -p "$ARCHIVE_DIR"
find "$LOG_DIR" -maxdepth 1 -name "*.log" -mtime +1 -exec gzip {} \;
find "$LOG_DIR" -maxdepth 1 -name "*.log.gz" -exec mv {} "$ARCHIVE_DIR" \;
find "$ARCHIVE_DIR" -name "*.log.gz" -mtime +"$DAYS_TO_KEEP" -delete

Проверка места на диске с алертом в лог:

#!/usr/bin/env bash
set -euo pipefail

THRESHOLD=85
USAGE=$(df -h / | awk 'NR==2 {gsub("%","",$5); print $5}')

if [ "$USAGE" -ge "$THRESHOLD" ]; then
    echo "$(date '+%Y-%m-%d %H:%M:%S') WARNING: disk usage ${USAGE}% >= ${THRESHOLD}%" >> /var/log/disk-check.log
    exit 1
fi

Обвязка перезапуска стенда из ../monitoring/CASE.md:

#!/usr/bin/env bash
set -euo pipefail

cd "$(dirname "$0")"
docker compose down
docker compose up -d
sleep 5
docker compose ps --filter "status=running" | grep -q prometheus || {
    echo "prometheus не поднялся" >&2
    exit 1
}

2. Systemd: unit-файл + таймер вместо cron

# /etc/systemd/system/disk-check.service
[Unit]
Description=Проверка места на диске

[Service]
Type=oneshot
ExecStart=/usr/local/bin/disk-check.sh
# /etc/systemd/system/disk-check.timer
[Unit]
Description=Запуск disk-check каждые 15 минут

[Timer]
OnBootSec=5min
OnUnitActiveSec=15min

[Install]
WantedBy=timers.target
systemctl daemon-reload
systemctl enable --now disk-check.timer
systemctl list-timers | grep disk-check
journalctl -u disk-check.service

3. Диагностический сценарий «сервер тормозит — первые 35 команд»

Порядок, который реально прогонял на своих стендах:

  1. uptime — load average за 1/5/15 минут, первое ощущение масштаба проблемы.
  2. top (или htop) — какой процесс ест CPU/память прямо сейчас.
  3. free -h — сколько реально свободной памяти (available, а не free, см. QUESTIONS.md).
  4. df -h — не закончилось ли место на диске (частая причина зависаний записи).
  5. iostat -x 1 / vmstat 1 — I/O-нагрузка на диск, если top не показал явного виновника по CPU.

4. Диагностический сценарий «df показывает, что место закончилось, а du — что всё в порядке»

Воспроизвести самому:

# терминал 1: занимаем место большим файлом внутри работающего процесса
dd if=/dev/zero of=/tmp/bigfile bs=1M count=2000 &
PID=$!
sleep 1
rm /tmp/bigfile        # удаляем файл, пока процесс его ещё держит открытым

df -h /tmp              # место всё ещё занято
du -sh /tmp              # du не видит файл — его уже нет в дереве каталогов

ls -l /proc/$PID/fd | grep bigfile   # но дескриптор в /proc/<pid>/fd всё ещё жив
wait $PID
df -h /tmp                # только теперь место освобождается

Причина: du считает по дереву каталогов (файла там уже нет — он удалён), а df считает по факту занятых блоков на файловой системе, которые освобождаются только когда закрывается последний файловый дескриптор, ссылающийся на inode. Пока процесс держит файл открытым, место физически занято, хотя ссылки на файл в каталоге уже нет.

5. Права, владение, поиск в логах

chmod 755 /usr/local/bin/disk-check.sh
chown appuser:appgroup /var/log/myapp

# поиск всех строк с ошибкой в большом логе
grep -c "connection timeout" /var/log/myapp/app.log
awk '/connection timeout/ {print $0}' /var/log/myapp/app.log | tail -20

6. Сигналы и процессы

ps aux | grep myapp
kill -15 <pid>     # SIGTERM — вежливая просьба завершиться
kill -9 <pid>      # SIGKILL — принудительное убийство, процесс не может его перехватить/игнорировать
pkill -f myapp     # найти и убить по имени/паттерну команды

Что это даёт в разговоре с интервьюером

  • Реальные, лично написанные и прогнанные bash-скрипты для обслуживания, а не абстрактные примеры.
  • Практический опыт systemd unit + timer как альтернативы cron.
  • Воспроизведённый вживую «фокус» df vs du — конкретный, запоминающийся ответ вместо зазубренной теории.
  • Уверенная диагностическая последовательность на вопрос «сервер тормозит».

Как это ложится в легенду

Linux и Bash — сквозной инструмент в обеих ролях (тестировщик на CentOS, инженер сопровождения на Astra). Скрипты и диагностика в этом кейсе — обобщённая практика повседневного обслуживания серверов, характерная для роли инженера сопровождения, без привязки к вымышленным деталям конкретных внутренних систем компаний.