Linux Ready | DevOps

Кто и откуда запускает процессы на сервере!

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

Посмотреть все процессы с родителем (PPID) — сразу видны цепочки запуска:

ps -eo pid,ppid,user,cmd --sort=ppid

Процессы с родителем PID 1 — чаще всего systemd, но бывают и осиротевшие:

ps -eo pid,ppid,cmd | awk '$2==1'

Частый источник фоновой активности — планировщики. Проверка cron (зависит от дистрибутива):

sudo journalctl -u cron --since "1 hour ago"
# или
sudo grep CRON /var/log/syslog

Systemd-таймеры — современная замена cron и частое место «забытых» автозапусков:

systemctl list-timers --all

Для подозрительных процессов полезно проверить бинарник и окружение:

ls -l /proc/<PID>/exe
tr '\0' '\n' < /proc/<PID>/environ

🔥 Несколько команд из терминала обычно хватает, чтобы отличить нормальный сервис от случайно оставленного cron или странной фоновой активности.

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

🧐 Tutorialspoint: Linux / Unix — простые объяснения команд, процессов, памяти, файловых систем!

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

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

🚪 Linux Ready | #сайт

Запуск команды в полностью чистой среде!

Многие проблемы в Linux возникают не из-за команды, а из-за окружения: переменные, алиасы, функции, конфиги shell. Из-за этого одна и та же команда может вести себя по-разному.

Но можно запустить её в идеально чистой среде, как на новом сервере или внутри контейнера:

env -i PATH=/usr/bin:/bin <команда>

env -i очищает окружение полностью. Добавляем PATH и команда выполняется с нуля.

Хотите чистый интерактивный shell?

bash --noprofile --norc

🔥 Если что-то ведёт себя нестабильно, воспроизведите проблему в чистой среде, так сразу видно, где баг: в окружении или в самой программе.

🚪 Linux Ready | #совет

Как быстро понять, что система упирается в диск: iostat в реальной диагностике!

Когда сервис внезапно начинает отвечать медленнее, а CPU и сеть выглядят нормально — почти всегда стоит проверить I/O. iostat показывает реальную картину: latency, очередь, загрузку устройства и фактический поток операций.

Проверка в реальном времени (обновление каждую секунду):

iostat -xz 1

Ключевые метрики:

await — средняя задержка операции.
На SSD всё, что выше 10–15 мс, уже красный флаг.

util — занятость устройства (%).
100% = диск работает на полном пределе, очередь растёт.

rMB/s / wMB/s — фактический throughput.
Позволяет понять, упираетесь ли в предел устройства (особенно важно для HDD и VM с IOPS-лимитами).

svctm — время обслуживания диском (мс).
Метрика устарела и может отсутствовать; если есть, сравнение await с svctm помогает понять, проблема в очереди или в самом диске.

Посмотреть, кто именно создаёт нагрузку:

sudo iotop -oPa

Флаги -oPa показывают только процессы, реально генерирующие I/O, и отображают накопленную статистику за время работы утилиты — удобно, когда нагрузка пульсирует.

Проверить, не закончились ли место или inode:

df -h
df -i

Это не про I/O-производительность напрямую, но часто объясняет “внезапные” подвисания записи.

Проверить сообщения ядра о проблемах со storage:

sudo journalctl -k | grep -Ei 'i/o|nvme|blk'

🔥 iostat — быстрый способ отделить проблемы приложения от проблем диска. Если await растёт, а util стремится к 100% — это почти всегда I/O bottleneck, а не код.

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

📂 Наглядный разбор, как работает HTTPS-шифрование между браузером и сервером!

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

Сохрани, чтобы быстро освежить в памяти, что происходит под капотом при каждом HTTPS-запросе.

🚪 Linux Ready | #ресурс

👩‍💻 Разбираем зависимости бинарей: видимые, скрытые и те, что подгружаются в рантайме!

Малейшее несовпадение библиотек может менять поведение приложения, поэтому важно быстро определить, какие .so оно действительно использует в конкретной системе.

В этом посте:

• Проверяем базовые зависимости через ldd;

• Извлекаем скрытые зависимости из ELF через readelf;

• Смотрим фактические загруженные библиотеки через /proc/<pid>/maps;

• Получаем полную картину, которая помогает решать проблемы несовместимых или “пропавших” .so.

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

🚪 Linux Ready | #задача

☕️ На Хабре вышла полезная статья: «Как патчить ядро Linux: подробное руководство»!

В этой статье:
• Пошагово разберёте, как собрать и пропатчить ядро под свои нужды;
• Настроите виртуальную машину + контейнерное окружение, чтобы безопасно экспериментировать;
• Освоите сборку ядра, конфигурацию, подготовку deb-пакета и установку патчей;
• Получите готовую базу, чтобы разбираться глубже в ядре и настраивать систему под себя.

🔊 Продолжайте читать на Habr!

🚪 Linux Ready | #статья

Как понять, что блокирует процесс — точная точка ожидания в ядре!

В Linux каждый процесс может “зависнуть” не в смысле ошибки, а потому что ждёт диск, сеть, mutex или ресурс ядра.

Но можно увидеть, на чём он сейчас стоит, без strace или ptrace. Посмотрим стек ядра процесса:

sudo cat /proc/<PID>/stack

Увидим функции ядра, в которых процесс находится.
Например: futex_wait_queue_me - блокировка / mutex, filemap_read - чтение с диска и т.д.

Хотите короткий ответ, без стека?

sudo cat /proc/<PID>/wchan

🔥 Вернёт одну точку блокировки - идеально для быстрых проверок. /proc/<PID>/stack — это именно то, что видит ядро.

🚪 Linux Ready | #совет

📂 Шпаргалка по перенаправлению ввода-вывода в Linux!

Linux-редиректы позволяют гибко управлять потоками stdin, stdout и stderr. С их помощью можно направлять вывод в файлы, разделять или объединять потоки, работать с here-documents и here-strings — всё для автоматизации и точного контроля над командами.

На картинке — основные варианты редиректов, включая базовые операции, комбинирование потоков и полезные приёмы.

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

🚪 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 | #практика

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

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

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

🚪 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 | #совет