Мир Линукса
408 subscribers
12 photos
22 links
Канал Мир Линукса. Новости, статьи и много интересного из мира линукса.
Download Telegram
Forwarded from Хабр Новости
В начале декабря 2025 года Linux 6.18 официально стал выпуском ядра с долгосрочной поддержкой (LTS) — до декабря 2027 года.

#ОС #разработка
👍1
Викторина «Linux или боль» завершена 🔥

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

И выбери, какую следующую линукс-викторину запускать:
«Найди ошибку в bash-скрипте»
«Угадай, какой сервис упал»
«Сетевой Linux: выживет только один»
Please open Telegram to view this post
VIEW IN TELEGRAM
5
📱 Новая подборка статей по Линуксу

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

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

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

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

#подборка_статей_Linux
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥52
📱 Подборка статей по Linux вам на изучение

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

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

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

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

#подборка_статей_Linux
Please open Telegram to view this post
VIEW IN TELEGRAM
👍2🔥1
Что на самом деле делает 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 проверяет ещё и права, что особенно критично в мультипользовательских системах и контейнерах.
Please open Telegram to view this post
VIEW IN TELEGRAM
👍16👎2
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, всё остальное - компромисс.
Please open Telegram to view this post
VIEW IN TELEGRAM
👍103
journalctl -xe: первая команда, которую вводят, когда «что-то сломалось»

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

journalctl -xe


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

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

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

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

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

-e

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

-x

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

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

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

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

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

Это точка входа в дебаг, а не финальный диагноз.
Please open Telegram to view this post
VIEW IN TELEGRAM
👍152
grep: история о возможностях, которыми почти никто не пользуется

Большинство знают grep как “поиск строки в файле”. На самом деле это один из самых мощных инструментов анализа в Linux.

Поиск по множеству файлов
grep "ERROR" /var/log/*.log
grep -r "token" .


Можно искать по каталогам, маскам и даже по всему проекту.

Регулярки и флаг -E
grep -E "ERROR|WARN|FATAL" app.log


-E включает расширенные регулярные выражения. Без него половина возможностей просто недоступна.

Читаемый вывод
grep --color=auto "timeout" app.log


Цвет - не гулянка. Это скорость анализа и меньше ошибок глазами.

Поиск с исключениями
grep -v "healthcheck" access.log


Идеально, когда нужно убрать шум и оставить только важное.
👍12
watch: команда, которая показывает живую систему

watch - один из самых недооценённых инструментов Linux. Он позволяет наблюдать за системой в реальном времени, без скриптов и демонов.

Базовая идея
watch <command>


Команда выполняется каждые N секунд, а ты видишь, как меняется состояние.

Реальные кейсы
watch df -h
watch ss -lntup
watch kubectl get pods
watch free -m


Идеально для:
🟢отладки
🟢диагностики
🟢наблюдения за деградацией

В расследовании инцидентов

Когда:
🟠растёт диск
🟠отваливаются сокеты
🟠поды флапают
🟠память “утекает”
watch показывает динамику, а не статический снимок.

Кастомизация
watch -n 1 command
watch -d command


Можно менять интервал и подсвечивать изменения - идеально для сравнения состояний.

Почему лучше cron
Cron даёт точки во времени.
watch даёт контекст и поведение системы.
Please open Telegram to view this post
VIEW IN TELEGRAM
👍12🥴3🤪1💊1
🥸 Свежая подборка статей для вашего обучения

💬 Самые частые ошибки при настройке VPS: опыт техподдержки - самые частые кейсы из практики поддержки - с пояснениями, что именно идёт не так и как это обычно чинится.

💬 Локальный диск на 288 ПБ: монтируем S3-бакет Yandex Cloud без боли - как с помощью GeeseFS смонтировать S3-бакет из Yandex Cloud как обычный локальный диск в Linux-системе (например, Fedora) через FUSE и systemd, получив огромный файловый объём для работы.

💬 Tiny Core Linux 16.2: полноценная система весом 23 МБ. Что это и зачем? - о том, как устроен Tiny Core Linux 16.2, почему остаётся минималистичным и в каких сценариях его можно использовать.

💬 Rust в ядре Linux: долгий путь от осторожных попыток к реальному применению - о том, как Rust постепенно внедряется в ядро Linux.

#подборка_статей_Linux
Please open Telegram to view this post
VIEW IN TELEGRAM
👍5