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

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

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

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

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

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

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

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

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

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

bash --noprofile --norc

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

🚪 Linux Ready | #совет

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

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

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

🚪 Linux Ready | #сайт

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

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

Посмотреть все процессы с родителем (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 | #практика

👍 Awesome-Shell — топовая коллекция утилит, скриптов и приёмов для терминала!

Здесь собраны десятки CLI-инструментов, полезные bash/zsh-скрипты, практичные сниппеты и лайфхаки, которые ускоряют работу. Отличный набор для автоматизации, оптимизации и прокачки навыков работы с командной строкой.

Оставляю ссылочку: GitHub 📱

🚪 Linux Ready | #репозиторий

Удобный способ смотреть логи и сразу находить проблемы!

Часто при анализе логов нужно видеть только важное, а не пролистывать тысячи строк вручную.

Самый базовый и рабочий вариант:

tail -f application.log | grep -i error

tail -f следит за обновлением файла,
grep -i ищет совпадения без учёта регистра.

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

tail -f application.log | grep -i -E "(error|warning|failure)"

-E включает расширенные регулярные выражения.
-P стоит использовать, если реально нужны возможности PCRE (lookbehind и т.п.).

Иногда полезнее сделать наоборот, убрать шум и оставить всё остальное:

tail -f application.log | grep -v -i "info"

🔥 Это особенно удобно, когда exception занимает несколько строк, видно его целиком, без разрывов по уровню логирования.

🚪 Linux Ready | #совет

📂 Напоминалка для работы с iptables!

Например, iptables -L позволяет быстро посмотреть текущие правила, а iptables -A — добавить новое правило для разрешения или блокировки трафика.

На картинке — полезные команды, которые стоит держать под рукой при работе с Linux-серверами, сетями и Docker.

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

🚪 Linux Ready | #ресурс

Как диагностировать нестабильные systemd-сервисы!

Если система в целом работает корректно, но отдельные сервисы периодически падают или перезапускаются, диагностику удобно начинать со systemd и его журналов.

Сервисы в ошибочном состоянии:

systemctl --failed

Показывает юниты, завершившиеся с ошибкой — базовая точка входа.

Перезапуски конкретного сервиса:

journalctl -u nginx --no-pager -g 'Starting|Stopped|Failed'

Позволяет быстро выявить циклические рестарты и их частоту.

Автоматические рестарты systemd:

journalctl -b | grep -Ei 'systemd\[1\].*(restart|Restart)'

Помогает обнаружить сервисы, которые systemd регулярно перезапускает.

Количество рестартов:

systemctl show nginx -p NRestarts

Счётчик рестартов с момента запуска systemd. Рост значения обычно указывает на нестабильность сервиса.

Причина остановки:

journalctl -xeu nginx

Даёт максимальный контекст ошибки и системные пояснения.

Проверка OOM-killer:

journalctl -k -b | grep -Ei 'oom|oom-kill|killed process'

Актуально, если сервис завершается без явных ошибок в собственных логах.

Конфигурация сервиса:

systemctl cat nginx

Позволяет проверить параметры рестарта, drop-in override’ы, зависимости и условия запуска.

🔥 Такой разбор покрывает большинство случаев нестабильной работы systemd-сервисов без дополнительных инструментов.

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

Знали, что можно сравнивать вывод команд напрямую — без временных файлов?

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

diff <(ls /etc) <(ls /etc.backup)

<(...) превращает вывод команды в псевдофайл (обычно /dev/fd/* или FIFO), который программа читает как обычный файл.

Можно сравнить локальный и удалённый конфиг:

diff nginx.conf <(ssh server 'cat /etc/nginx/nginx.conf')

Или проверить, что изменилось после деплоя, без копирования и мусора в /tmp.

🔥 Process substitution (<(...)) отлично работает с diff, grep, sort, comm, wc. Это быстрый способ сравнивать данные, но он зависит от shell и не поддерживается в sh/dash.

🚪 Linux Ready | #совет