BashTex | Linux

Современный мониторинг ресурсов Если стандартный top кажется неудобным, а htop - уже привычным, стоит попробовать btop. Это современный мониторинг ресурсов с удобным интерфейсом и большим количеством полезных функций. ▪️ Что показывает btop. В одном окне можно увидеть: загрузку CPU по ядрам использование RAM и swap дисковую активность сетевой трафик список процессов с сортировкой Интерфейс обновляется в реальном времени и выглядит значительно понятнее, чем классические инструменты. ▪️ Установка

    
        
sudo apt install btop # Ubuntu / Debian
sudo dnf install btop # RHEL / CentOS / Fedora
sudo pacman -S btop # Arch{}
    

▪️ Запуск:

    
        
btop{}
    

🤩 Что делает его удобным Интерактивный список процессов Можно: сортировать по CPU / RAM убивать процессы фильтровать список ▪️ Клавиши: F9 - kill process F6 - сортировка F - поиск процесса ▪️ Мониторинг сети. btop показывает: входящий / исходящий трафик скорость сети активность интерфейсов Это удобно, когда нужно быстро понять куда уходит трафик. ▪️ Наглядная нагрузка CPU. В отличие от top, здесь видно: загрузку каждого ядра историю нагрузки spikes CPU Очень полезно при диагностике перегрузки сервера. ▪️ Полезные настройки Открыть настройки: ESC Можно изменить: тему интерфейса частоту обновления отображаемые графики сетевые интерфейсы Конфиг хранится в:

    
        
~/.config/btop/btop.conf{}
    

BashTex 📱 #linux #monitoring

Контроль превышения лимитов ulimit у сервисов Сервис падает без причины, но в логах странные ошибки:

Too many open files Resource temporarily unavailable fork: retry cannot allocate memory

Очень часто это не баг. Это лимиты ulimit. ▪️ Какие лимиты критичны 1️⃣ nofile - открытые файлы. Сколько файловых дескрипторов может открыть процесс. Проверка:

    
        
ulimit -n{}
    

Или для конкретного процесса:

    
        
cat /proc/<PID>/limits | grep "Max open files"{}
    

Если видишь 1024, то для прод-сервиса это почти всегда мало. 2️⃣ nproc - количество процессов. Ограничение на число процессов пользователя. Проверка:

    
        
ulimit -u

Или:


cat /proc/<PID>/limits | grep "Max processes"

Если приложение активно форкает воркеры - лимит может убить его.

{}
    

    
        🤩{}
    

    
         {}
    

    
        Почему это сложно заметить{}
    

    
        

сервис стартует нормально
падает только под нагрузкой
в логах нет прямого указания на лимит
systemd может перезапускать бесконечно

{}
    

    
        ▪️{}
    

    
         {}
    

    
        Проверка лимитов у systemd-сервиса{}
    

    
        


systemctl show myservice | grep -E 'LimitNOFILE|LimitNPROC'

Если пусто, то используются дефолтные значения системы.

{}
    

    
        ▪️{}
    

    
         Как исправить{}
    

    
        . Создать override:


systemctl edit myservice

Добавить:


[Service]
LimitNOFILE=65535
LimitNPROC=4096

Перезагрузить:


systemctl daemon-reload
systemctl restart myservice

{}
    

    
        ▪️{}
    

    
         Быстрая диагностика падений{}
    

    
        . Если сервис падает под нагрузкой:

Проверить {}
    

    
        /proc/<PID>/limits{}
    

    
        
Посмотреть количество открытых файлов:


ls /proc/<PID>/fd | wc -l

Проверить количество процессов пользователя:


ps -u username | wc -l{}
    

BashTex 📱 #bash #check

🖥️ Выбираешь сервер под ИИ? Сначала загляни сюда 23 апреля в 11:00 (МСК) — бесплатный вебинар от CNS: «Как выбрать сервер для ИИ в 2026 году: GPU, TCO и подводные камни» Если ты сейчас разбираешься, что брать под LLM, инференс или RAG — этот час сэкономит тебе кучу времени, нервов и, возможно, бюджета. Что разберём: 🔹 NVIDIA Hopper vs Blackwell — в чём реальная разница под задачи 2026 года, и не переплачиваешь ли ты за архитектуру 🔹 TCO без иллюзий — как считать полную стоимость владения, где прячутся скрытые расходы 🔹 Типичные ошибки при закупке GPU-серверов — скрытые ловушки и как грамотно сопоставить характеристики железа с реальными задачами нейросетей 🔹 Q&A-сессия — спрашивай, отвечаем честно Кому это полезно: — IT-директорам — Архитекторам и администраторам инфраструктуры — Всем, кто строит или планирует on-prem под ML/LLM/RAG 🗓 23 апреля, 11:00–12:00 МСК 📌 Регистрация: webinar.cns-corp.ru #реклама О рекламодателе

Работа с дескрипторами файлов В linux все - это файл. И каждый процесс работает с файловыми дескрипторами: 0 - stdin 1 - stdout 2 - stderr 3+ - любые дополнительные Понимание этого - ключ к нормальной автоматизации. ▪️ Базовые перенаправления

    
        
command >out.log        # stdout
command 2>err.log       # stderr
command >all.log 2>&1   # объединить{}
    

2>&1 значит: направь stderr туда же, куда сейчас смотрит stdout. ⚠️ Порядок важен: command 2>&1 >file - НЕ то же самое. ▪️ Dup (дублирование дескрипторов). Можно создать свой поток:

    
        
exec 3>debug.log
echo "debug" >&3{}
    

Теперь 3 пишет в debug.log. Это удобно, если нужно: отделить debug-лог от основного вывода не засорять stdout вести параллельный лог ▪️ Временное перенаправление

    
        
{
  echo "только в файл"
} >file.txt{}
    

Или:

    
        
exec >all_output.log 2>&1{}
    

Теперь весь скрипт пишет в лог. ▪️ Закрытие дескриптора. Иногда нужно закрыть поток:

    
        
exec 3>&-{}
    

Это освобождает дескриптор. Полезно при работе с сокетами, FIFO и временными логами. ▪️ Практический кейс. Раздельный лог и чистый stdout:

    
        
exec 3>debug.log
BASH_XTRACEFD=3
set -x{}
    

Трассировка уйдет в файл, а stdout останется чистым для пайплайна. BashTex 📱 #bash #utils

Спалили BashTex 📱 #юмор

Почему cron не сработал Каждый админ хотя бы раз слышал: Cron не отработал. Но, спойлер: в 90% случаев cron работает. Не работает: окружение, путь или логика скрипта. 1️⃣ Неправильный PATH. Cron запускается с минимальным окружением. То, что работает в shell:

    
        
myscript.sh{}
    

В cron может не найти: command not found Проверка:

    
        
echo $PATH{}
    

Решение:

    
        
PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin{}
    

Или использовать абсолютные пути:

    
        
/usr/bin/rsync
/usr/bin/docker{}
    

2️⃣ Не тот пользователь. Есть:

    
        
crontab -e{}
    

И есть:

    
        
sudo crontab -e{}
    

Это два разных crontab. Проверка:

    
        
crontab -l
sudo crontab -l{}
    

Иногда задача просто стоит не там. 3️⃣ Нет прав на файл. Скрипт есть. Но:

    
        
chmod +x script.sh{}
    

забыли. Или владелец не тот. 4️⃣ Неправильный shebang. Если в начале:

    
        
#!/bin/bash{}
    

А на системе bash лежит в:

    
        
/usr/bin/bash{}
    

Cron молча свалится. Проверка:

    
        
which bash{}
    

Лучший вариант:

    
        
#!/usr/bin/env bash{}
    

5️⃣ Нет логирования и кажется, не сработал Если вывод не перенаправлен, ты его не увидишь. Правильно:

    
        
0 3 * * * /path/script.sh >> /var/log/script.log 2>&1{}
    

Без этого ты гадаешь. 6️⃣ Разница окружения. Cron не знает: твоих alias твоих переменных твоего virtualenv твоего nvm Если работает вручную, но не в cron - почти всегда проблема в ENV. Debug-метод:

    
        
env > /tmp/cron_env.txt{}
    

7️⃣ Скрипт падает внутри. Cron сработал. Но внутри:

    
        
rm -rf "$DIR"{}
    

где $DIR пустой. Без:

    
        
set -euo pipefail{}
    

ошибка могла остаться незамеченной. 8️⃣ Cron вообще не запущен. Редко, но бывает. Проверка:

    
        
systemctl status cron
# или
systemctl status crond{}
    

BashTex 📱 #cron

Спалили BashTex 📱 #юмор

Sync tricks: инкременты, hard links и бэкапы Все знают про rsync, но не все используют его на 100%. Сегодня разберем три мощных приема: инкрементальные бэкапы, hard links для экономии места и атомарная схема снапшотов 1️⃣ Инкрементальный sync. База:

    
        
rsync -a --delete /data/ /backup/current/{}
    

Что происходит: -a - сохраняет права, владельца, время --delete - удаляет лишнее в приемнике Это зеркало. Но это не история. Каждый запуск перезаписывает прошлый бэкап. 2️⃣ Настоящие снапшоты через hard links. Допустим, структура такая:

    
        
/backup/
 ├── 2026-03-29/
 ├── 2026-03-30/
 └── 2026-03-31/{}
    

Команда:

    
        
TODAY=$(date +%F)
YESTERDAY=$(date -d "yesterday" +%F)

rsync -a --delete \
  --link-dest=/backup/$YESTERDAY \
  /data/ /backup/$TODAY/{}
    

Что происходит: изменённые файлы - копируются неизмененные - создаются как hard link места занимает почти как один бэкап Что тут необычного? Hard link - это не копия файла. Это второе имя для того же inode. Проверка:

    
        
ls -li file1 file2{}
    

Одинаковый inode - это один и тот же файл. Удаляешь снапшот 29-го числа и файл не удалится, если он есть в 30-м. Здесь же и начинается экономия места. Если данные почти не меняются: 30 снапшотов могут занимать +5–10% к объему, вместо ×30 бэкапов. Это почти как ZFS snapshots, но работает на обычном ext4. 3️⃣ Атомарная схема без битых бэкапов. Никогда не пиши прямо в конечную папку. Правильно:

    
        
rsync -a --delete \
  --link-dest=/backup/$YESTERDAY \
  /data/ /backup/.tmp-$TODAY/ &&
mv /backup/.tmp-$TODAY /backup/$TODAY{}
    

Теперь: если rsync упал - снапшот не появится всегда либо полный, либо отсутствует 4️⃣ Ротация снапшотов. Храним 14 дней:

    
        
find /backup -maxdepth 1 -type d -mtime +14 -exec rm -rf {} \;{}
    

(Осторожно с путями.) 🛠 Мини-скрипт

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

SRC="/data"
DST="/backup"
TODAY=$(date +%F)
YESTERDAY=$(ls -1 $DST | sort | tail -n 1)

rsync -a --delete \
  ${YESTERDAY:+--link-dest=$DST/$YESTERDAY} \
  "$SRC/" "$DST/.tmp-$TODAY/"

mv "$DST/.tmp-$TODAY" "$DST/$TODAY"{}
    

Первый запуск - обычная копия. Все следующие - инкременты. BashTex 📱 #bash #backup

Не все так просто, кожаный BashTex 📱 #юмор

Автоматический failover при недоступности mount-точки Неприятная ситуация когда mount вроде есть, но по факту хранилище уже умерло. NFS отвалился. iSCSI завис. Ceph не отвечает. Сервис продолжает писать… в никуда. Решение - автоматическая логика: Проверка -> попытка remount -> переключение на fallback. ▪️ Логика failover Проверяем, что mount существует; Проверяем доступность записи; Если ошибка, то пробуем remount; Если не помогло - переключаемся на fallback. 🛠 Пример скрипта

    
        
#!/usr/bin/env bash

MOUNT_POINT="/data"
FALLBACK="/data_local"
TEST_FILE="$MOUNT_POINT/.healthcheck"

log() {
  echo "$(date '+%F %T') | $1"
}

check_mount() {
  mountpoint -q "$MOUNT_POINT" || return 1
  timeout 3 touch "$TEST_FILE" 2>/dev/null || return 1
  rm -f "$TEST_FILE"
}

remount() {
  log "Попытка remount..."
  mount -o remount "$MOUNT_POINT"
}

switch_to_fallback() {
  log "Переключение на fallback $FALLBACK"
  umount -l "$MOUNT_POINT"
  mount --bind "$FALLBACK" "$MOUNT_POINT"
}

main() {
  if check_mount; then
    log "Mount работает нормально"
    exit 0
  fi

  log "Mount недоступен"

  remount && sleep 2

  if check_mount; then
    log "Remount помог"
    exit 0
  fi

  switch_to_fallback
}

main{}
    

▪️ Что здесь важно 1. timeout - если NFS завис, без timeout скрипт повиснет навсегда. 2. mountpoint -q - Проверяет именно mount, а не просто директорию. 3. umount -l - lazy umount - полезно, если есть залипшие процессы. ▪️ Как запускать правильно Лучше всего: systemd timer или healthcheck внутри сервиса или отдельный watchdog unit ⚠️ Нюансы Если сервис пишет активно, то нужно ставить его на паузу перед failover; fallback должен быть заранее подготовлен; важно логировать переключения; нужен механизм возврата обратно. BashTex 📱 #bash #utils