Многие не задумываются, что стандартизация имён сервисов спасает от путаницы!

Вместо nginx-web, postgres-main, redis-cache — используй простые имена: nginx.service, postgres.service, redis.service.

Тогда systemctl status/list/ restart работают без запоминания хаотичных названий.

Проверяем статус всех сервисов одной командой:

systemctl status nginx postgres redis

Быстрый поиск по части имени без путаницы:

systemctl list-units --type=service --state=running | grep nginx

Перезапуск группы сервисов brace expansion’ом:

systemctl restart {nginx,postgres,redis}.service

🔥 Стандартизация имён = команды работают везде без локальных танцев с бубном.

🚪 Linux Ready | #совет

Онлайн-профилирование CPU-интенсивного процесса через perf без даунтайма!

Когда сервис забирает почти весь CPU, важно быстро понять, где именно тратится время — в user-коде, ядре, библиотеках или на блокировках.

Найти PID:

pgrep -f myservice

Горячие функции в реальном времени:

sudo perf top -p <PID>

Показывает, какие функции потребляют больше всего CPU прямо сейчас.

Короткий профиль для детализации:

sudo perf record -F 99 -p <PID> -- sleep 15
sudo perf report

Небольшой профиль даёт репрезентативный срез и позволяет проваливаться в стеки.

User-space-only + стеки:

sudo perf record -F 99 -p <PID> -e cycles:u --call-graph=dwarf -- sleep 15
sudo perf report

Фокус на пользовательском коде и детальные стеки вызовов для точной локализации.

Проверка системных вызовов:

sudo strace -p <PID> -tt -T -f -o /tmp/strace.log

Нагрузка по потокам:

top -H -p <PID>

Помогает обнаружить конкретный поток, создающий основную нагрузку.

Права на профилирование:

cat /proc/sys/kernel/perf_event_paranoid

🔥 Этот набор команд позволяет без остановки сервиса быстро понять, куда именно уходит CPU, и принимать решения на основе объективного профиля.

🚪 Linux Ready | #практика

📂 Напоминалка по структуре каталогов Linux!

Например, /bin содержит системные бинарные файлы, а /etc — конфигурации, управляющие поведением системы.

На картинке — директории Linux, их назначение и место в иерархии.

Сохрани, чтобы не забыть!

🚪 Linux Ready | #ресурс

Мини-скрипт мониторинга файла с логом и простым alert (webhook)

Отслеживаем изменения файла/папки и логируем с таймстампом, при установленном ALERT_WEBHOOK отправляем короткий POST. Требуется inotifywait (inotify-tools):

#!/usr/bin/env bash
WATCH="$1"; LOG="${2:-/var/log/filewatch.log}"
inotifywait -m -e modify,create,delete,move --format '%T %w %e %f' --timefmt '%F %T' "$WATCH" |
while read -r ts path ev file; do
  echo "$ts $path $ev $file" >> "$LOG"
  [ -n "$ALERT_WEBHOOK" ] && curl -s -X POST -H 'Content-Type: application/json' --data "{\"text\":\"$ts $path $ev $file\"}" "$ALERT_WEBHOOK" >/dev/null 2>&1
done

Файл /var/log/filewatch.log начнёт пополняться строками вида:
YYYY-MM-DD HH:MM:SS /path MODIFY filename.

Запускаем скрипт в фоне (например, через nohup), чтобы он работал независимо от сессии:

nohup /usr/local/bin/file-monitor.sh /path/to/watch /var/log/filewatch.log >/dev/null 2>&1 &

Теперь скрипт работает в фоне, PID виден через pgrep -f file-monitor.sh.

Проверка работоспособности:

tail -n 3 /var/log/filewatch.log

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

2025-11-11 12:34:01 /path/to/watch MODIFY important.conf

Остановка/очистка. Убираем процесс-монитор:

pkill -f file-monitor.sh && echo "Остановлено" || echo "Процесс не найден"

🔥 В результате скрипт даёт простой и надёжный способ отслеживать изменения файлов и записывать события в лог.

🚪 Linux Ready | #практика

Нужно узнать, какие файлы были удалены, кем, когда и из какого процесса?

Если удалили “не то”, или скрипт стёр лишнее — при включённом auditd ядро фиксирует вызовы unlink/unlinkat.

Показать последние удалённые файлы:

sudo ausearch -x rm -sc unlink

Здесь будут: время, PID, пользователь и путь удалённого файла.

Хотите отслеживать удаления в режиме близком к реальному времени?

sudo auditctl -w / -p wa

Это включает контроль изменений по всей системе (в проде лучше ставить watch на конкретные каталоги)

После этого смотрим события:

ausearch -sc unlink

🔥 Пригодится при расследованиях, ошибочных deploy-скриптах и случайных rm.

🚪 Linux Ready | #совет

🧐 OverTheWire: Bandit — полезный тренажёр для освоения Linux!

Если хочешь учиться не по учебнику, а через практику, этот сайт идеальный старт. Каждый уровень — маленькая задача: работа с файлами, SSH, процессы, шифрование. Постепенно учишься использовать команды осознанно, а не просто запоминать их. А навыки остаются как после реальной работы на сервере.

📌 Оставляю ссылочку: overthewire.org

🚪 Linux Ready | #ресурс

Как диагностировать процессы, которые «висят» и не отвечают!

Когда приложение перестаёт реагировать, важно быстро определить, где оно застопорилось: в I/O, системном вызове, блокировке или в логике приложения.

Состояние процесса (R, S, D, Z, T):

ps -o pid,ppid,state,cmd -p <PID>

Ключевые состояния:

D — ожидание I/O
T — остановлен
Z — зомби

Kernel stack зависшего процесса (если он залип в системном вызове):

sudo cat /proc/<PID>/stack

Признаки I/O-зависания: io_schedule, wait_on_page_bit.

Открытые файлы, сокеты, дескрипторы:

sudo lsof -p <PID>

Python: быстрый traceback без перезапуска:

sudo py-spy dump --pid <PID>

Node.js: корректный способ получить диагностический отчёт: запуск:

node --report-on-signal --report-compact app.js

Получение отчёта:

kill -USR2 <PID>

Системные вызовы, на которых процесс висит:

sudo strace -p <PID>

Частые паттерны ожидания: futex(...), read(...), poll(...), select(...).

Профиль нагрузки процесса (CPU, context switch, I/O):

pidstat -p <PID> -w -d 1

🔥 Эти команды позволяют быстро и без даунтайма понять, завис ли процесс в I/O, блокировке, системных вызовах или в логике приложения.

🚪 Linux Ready | #практика