Всеми полюбившаяся подборка статей теперь и про линукс 🔥

✅ Как патчить ядро Linux: подробное руководство - Статья объясняет, как шаг за шагом собрать, протестировать и пропатчить ядро Linux - включая настройку окружения (виртуалки + Docker + Debian/QEMU), сборку ядра, упаковку в deb-пакет, установку и проверку изменений (на примере добавления поддержки опции PROTO_DOWN для Ethernet-интерфейсов).

✅ Установка Fedora Linux на MacBook Pro 2019 с чипом T2 - как установить Fedora Linux на MacBook Pro 2019 с чипом Apple T2 Security Chip - пошагово: от отключения Secure Boot и разметки диска до настройки ядра и активации Wi-Fi, Bluetooth, звука, тачпада и других компонентов.

✅ Хватит кормить облака: переезд пет-проектов на старый ThinkPad с разбитым экраном - о том, как автор перенёс свои pet-проекты с облачного хостинга на старый списанный ноутбук - фактически превратив его в домашний сервер с Linux + Docker + Cloudflare Tunnel + Traefik - чтобы сэкономить на хостинге, и делится плюсами и проблемами такого DIY-решения.

#подборка_статей_Linux

Викторина «Linux или боль» завершена 🔥

Если ты набрал:
8–10 - ты человек, который однажды забудет пароль root, но всё равно зайдёт через initramfs.
5–7 - у тебя устойчивость к боли. Ты ещё вернёшься.
0–4 - ты или джун, или уже слишком опытный, чтобы снова страдать.
Напиши свой результат в комментариях.

И выбери, какую следующую линукс-викторину запускать:
«Найди ошибку в bash-скрипте»
«Угадай, какой сервис упал»
«Сетевой Linux: выживет только один»

📱 Новая подборка статей по Линуксу

🟢Алиас в помощь - начинающим линуксоидам о такой интересной возможности, как использование алиасов.

🟢 Собираем Linux, который весит меньше, чем мем с котиком, ну или почти… - как собрать максимально лёгкую минималистичную сборку Linux так, что система будет занимать минимум места и станет отличным упражнением для изучения работы ОС «с нуля».

🟢 Мониторинг в Linux на уровне ядра. Краткое практическое введение в eBPF+Cilium - короткий гайд по работе с eBPF с уклоном в практику.

🟢 Автоматизация рутинных задач на VPS с помощью cron и скриптов - как автоматизировать рутинные задачи на Linux-сервере при помощи cron и немного с помощью скриптов.

#подборка_статей_Linux

📱 Подборка статей по Linux вам на изучение

🔵6 Docker-фич для продвинутого использования. Часть 2 - про инструменты, которые помогают анализировать, оптимизировать и улучшать контейнерные образы и процессы их использования.

🔵Два режима SPEC: разгоняемся на Peak, притормаживаем на Base - статья объясняет различие двух режимов бенчмарков SPEC CPU - Base и Peak, рассказывает, как они отличаются ограничениями на оптимизации при измерении производительности и для чего оба режима используются при оценке скорости и возможностей систем.

🔵Android-смартфон как веб-камера под Linux - как быстро и бесплатно превратить Android-смартфон в полноценную веб-камеру для Linux.

🔵Я установил k3s на Arch, чтобы вам не пришлось - полное руководство по ручной установке с реальными командами и решениями.

#подборка_статей_Linux

Что на самом деле делает kill -0 <PID> и почему это один из самых недооценённых приёмов в Linux

Что делает kill -0 <PID>?

Проверяет, существует ли процесс и можно ли к нему обращаться сигналами - при этом не посылает никакого сигнала.

Это просто тест на доступность процесса.

Почему это важно?

Потому что иногда нужно узнать:
⚪️ жив ли процесс?
⚪️ есть ли права взаимодействовать с ним?
⚪️ не “повис” ли PID после падения?
⚪️ стоит ли перезапускать сервис или это ложная тревога?

И всё это - без риска его случайно убить.

Как это работает?

Команда


kill -0 <PID>  

делает системный вызов kill(), но с “нулевым” сигналом.
Нулевой сигнал - это не сигнал. Это проверка.

Возможные результаты:

⚪️Выходит без ошибки → процесс существует, доступен, жив.
⚪️ESRCH → процесса с таким PID нет.
⚪️EPERM → процесс есть, но нет прав для сигналов.

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

Где используют kill -0 в реальной работе

1. В health-check скриптах
Перед тем как перезапустить сервис, проверяют, жив ли текущий PID.

2. В init-скриптах systemd и supervisord
Чтобы не запустить дублирующие процессы.

3. В CI/CD пайплайнах
Для проверки зависших тестов или фоновых задач.

4. В мониторинге
Zabbix, Prometheus exporters, cron - все любят быструю проверку на существование процесса.

Почему не стоит игнорировать этот приём

Это очень безопасный, надёжный и почти бесплатный способ понять текущее состояние процесса без взаимодействия с ним.
ps, pgrep, pidof - полезны, но kill -0 проверяет ещё и права, что особенно критично в мультипользовательских системах и контейнерах.

rsync, scp и sftp: чем копировать, чтобы потом не было больно

В Linux есть три популярных способа копирования файлов по сети: scp, sftp и rsync. Формально все они работают поверх SSH и считаются безопасными, но на практике решают разные задачи.

Протоколы и принцип работы
scp - это прямое копирование файла “как есть”.
Он не знает, что копирует, не умеет продолжать передачу и каждый раз гоняет файл целиком.

sftp - интерактивный файловый протокол поверх SSH.
Больше похож на FTP: можно ходить по каталогам, забирать файлы, но для автоматизации и массовых операций он неудобен.

rsync - не просто копирование, а синхронизация.
Он сравнивает источник и назначение и передаёт только различия. Именно поэтому его используют в проде.

Ускорение и контроль передачи
rsync выигрывает за счёт флагов:

🟢--partial - продолжение прерванной передачи

🟢--compress - сжатие данных на лету

🟢--progress - реальный прогресс, а не “ждите”

В scp максимум, на что можно рассчитывать - флаг -C для сжатия, без контроля состояния.

Безопасность

Все три работают по SSH.
Если настроены ключи, отключён пароль и ограничены права - по безопасности разницы нет.

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

Частые ошибки rsync

🗄 забывают / в конце пути и копируют каталог целиком
🗄 используют --delete без dry-run
🗄 синхронизируют /etc, не исключив секреты
🗄 копируют миллион мелких файлов без --inplace

Когда использовать что

✅Бэкапы 👉 rsync
✅Миграции серверов 👉 rsync
✅Перенос конфигов 👉 rsync
✅Один файл быстро забрать 👉 scp
✅Ручная работа с файлами 👉 sftp

Если коротко: в автоматизации rsync, всё остальное - компромисс.

journalctl -xe: первая команда, которую вводят, когда «что-то сломалось»

Когда в Linux внезапно не стартует сервис, systemd ругается, а причина неочевидна - почти всегда первым делом вводят:

journalctl -xe

И не просто так.

Что показывает journalctl -xe
Эта команда выводит детализированные сообщения об ошибках последних событий systemd, с пояснениями и фокусом именно на проблемах.

Она не показывает процессы, не лезет в сетевые логи и не является просмотром логов ядра в чистом виде. Это быстрый и удобный инструмент диагностики системных сбоев.

Почему именно -x и -e

Флаги здесь работают в связке:

-e

Перемещает вывод сразу в конец журнала - к самым свежим событиям. То есть ты сразу видишь, что произошло только что, без прокрутки километров логов.

-x

Добавляет человеческие пояснения к сообщениям systemd. Это не просто сухая ошибка, а подсказка, что именно пошло не так и в каком направлении копать.

Вместе они превращают journalctl в инструмент быстрого разбора аварий.

Когда реально полезно

journalctl -xe обычно запускают, когда:

🟠сервис не стартует (systemctl start вернул ошибку)
🟠systemd завис или ушёл в degraded
🟠после обновления что-то перестало работать
🟠приложение падает без логов в stdout
🟠сервер перезагрузился и нужно понять почему

Это точка входа в дебаг, а не финальный диагноз.