✅ AI-Промпт (Чек-лист): "Напиши мне systemd unit-файл"

Боль: Вы написали крутой скрипт на Python (app.py), но запускаете его в screen или через nohup ... &. Он "падает" — и всё.

Решение: Превратить его в настоящую Linux-службу (systemd). Но писать unit-файлы вручную — это "боль" (забыть [Install], User= и т.д.).

AI — идеальный генератор "болванок".

Промпт (для ChatGPT/Gemini/Copilot):

Выступи в роли Senior Linux SRE.
Напиши "production-ready" systemd unit-файл (`my-app.service`) для моего Python-приложения.

Чек-лист требований для AI:
1.  [ ] [Unit]: Добавить `Description=` и `After=network.target` (чтобы запускался *после* сети).
2.  [ ] [Service]:
    * `Type=simple`
    * `ExecStart=/usr/bin/python3 /opt/my-app/app.py` (путь к приложению).
    * `User=www-data` (Критично! Не запускать от root!).
    * `Restart=on-failure` (Критично! Авто-перезапуск при сбое).
    * `RestartSec=5`
    * `WorkingDirectory=/opt/my-app`
3.  [ ] [Install]:
    * `WantedBy=multi-user.target` (чтобы включался через `systemctl enable`).
4.  [ ] Объясни каждую секцию.

Взгляд архитектора: AI генерирует идемпотентный, безопасный (User=) и отказоустойчивый (Restart=) unit. Вы не тратите время на "бойлерплейт", а сразу получаете best-practice.

#ai4admin #linux #systemd #sre #automation #промпты #чеклисты

🕵️‍♂️ Linux: Что случилось, пока я спал?

Утро понедельника начинается не с кофе, а с вопроса: «Почему этот сервис лежит?». Читать весь лог за выходные — долго. Используем фильтры времени в journalctl.

Задача: Показать все ошибки, случившиеся с момента ухода с работы в пятницу (например, с 18:00).

Команда:

# --since принимает дату и время
# -p err (priority error) покажет только ошибки и хуже
# -x добавит пояснения к ошибкам (если есть в каталоге)

journalctl --since "2025-11-28 18:00:00" -p err -xb

Если нужно посмотреть конкретный сервис:

journalctl -u nginx --since "2 days ago"

Одной командой вы отсекаете 99% информационного шума и видите только проблемы выходных.

#linux #systemd #logs #troubleshooting #команды

💀 Cron мертв. Да здравствуют Systemd Timers

Мы все привыкли писать crontab -e. Это просто, но убого: ❌ Если задача упала, вы узнаете об этом только если настроили почту. ❌ Логи надо перенаправлять вручную (>> /var/log/my.log 2>&1). ❌ Нельзя сказать: «Запусти бэкап только ПОСЛЕ того, как загрузилась база данных».

В 2025 году Архитектор использует Systemd Timers.

Как это сделать:

Создаем сервис (/etc/systemd/system/backup.service): Описываем, что делать.

[Service]
Type=oneshot
ExecStart=/usr/local/bin/backup.sh

Создаем таймер (/etc/systemd/system/backup.timer): Описываем, когда делать.

[Timer]
OnCalendar=*-*-* 03:00:00  # Каждый день в 3 ночи
Persistent=true            # Если сервер был выключен, запустить сразу при включении!

[Install]
WantedBy=timers.target

Активируем: systemctl enable --now backup.timer

Бонусы:
* systemctl list-timers — показывает, когда был последний запуск и когда следующий.
* journalctl -u backup.service — все логи из коробки.
* Можно добавить OnFailure=alert.service, чтобы телеграфировать об ошибках.

#linux #systemd #cron #automation #modern #bestpractice

🛡 Linux: Как запретить системе убивать твою Базу Данных (OOM Killer)

Ситуация: На сервере кончилась память (RAM). Ядро Linux включает механизм OOM Killer (Out Of Memory Killer), который, как санитар леса, начинает убивать самые "жирные" процессы, чтобы спасти систему. Чаще всего под нож попадает MySQL, PostgreSQL или Java-приложение. И сервер падает.

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

Как это сделать: У каждого процесса есть файл /proc/[PID]/oom_score_adj. Значения в нем: от -1000 (бессмертный) до 1000 (убить первым).

Защищаем процесс (например, SSH или БД):

# Находим PID (например, 1234)
# Записываем -1000 в score_adj
echo -1000 > /proc/1234/oom_score_adj

Как сделать это вечным (через Systemd): Добавьте в unit-файл сервиса (/etc/systemd/system/mysql.service.d/override.conf):

[Service]
OOMScoreAdjust=-1000

Теперь, даже если память кончится полностью, Linux убьет Apache, агенты мониторинга, cron, но Базу Данных будет держать до последнего байта.

#linux #kernel #oom #stability #systemd #bestpractice

🧹 Linux: Укрощаем journald. Как освободить место без удаления файлов?

Если /var/log забит, но logrotate настроен правильно, скорее всего, виноват systemd-journald. Он хранит бинарные логи, которые могут копиться годами и занимать гигабайты. Просто удалять файлы в /var/log/journal/ опасно — можно повредить базу.

Используйте встроенные механизмы очистки (vacuum).

1. Проверяем, сколько места занято:

journalctl --disk-usage
# Вывод: Archived and active journals take up 4.2G in the file system.

2. Освобождаем место (безопасно): Утилита сама удалит самые старые записи, чтобы вписаться в лимит.

# Оставить только последние 500 МБ
sudo journalctl --vacuum-size=500M

# Или оставить логи только за последние 10 дней
sudo journalctl --vacuum-time=10d

3. Как сделать это автоматическим: В файле /etc/systemd/journald.conf раскомментируйте и настройте параметр: SystemMaxUse=500M Теперь systemd сам будет следить за диетой.

#linux #systemd #journalctl #cleanup #maintenance #storage

🐧 Linux: Что упало, пока мы отдыхали? (systemctl --failed)

Вы заходите на сервер.
Аптайм есть, SSH работает.
Все ок? Не факт.
Возможно, второстепенный сервис (бэкап-агент, ротация логов, обновление сертификатов) тихо умер 2 января.

Не ищите иголку в стоге сена. Спросите systemd прямо.

Команда:

systemctl --failed

Что она покажет: Только те сервисы, которые находятся в статусе failed.

Как починить:

* Смотрим логи упавшего: journalctl -u service_name -n 50

* Перезапускаем: systemctl restart service_name

Важно: Если ошибка разовая и вы её исправили, сбросьте счетчик ошибок, чтобы список стал чистым:

systemctl reset-failed

Начинайте год с чистого листа (и чистого вывода systemd).

#linux #systemd #maintenance #troubleshooting #healthcheck

🐧 Linux: Спасаем базу данных от OOM Killer

Бывало такое?
Серверу не хватило памяти, пришел OOM Killer (Out of Memory) и убил... нет, не зависший PHP-скрипт, а твой основной PostgreSQL.
💀 Почему? Потому что БД потребляет больше всего памяти, и для ядра она выглядит как самый "жирный" кандидат на расстрел.

Решение: Настроить oom_score_adj. Это число от -1000 (бессмертный) до +1000 (убить первым).

Как защитить критический процесс: Находим PID процесса (например, postgres):

pgrep -f postgres | head -1

Запрещаем OOM Killer'у трогать его (ставим -1000):

echo -1000 > /proc/[PID]/oom_score_adj

Как сделать это вечным (в systemd): Добавьте в unit-файл сервиса (systemctl edit postgresql):

[Service]
OOMScoreAdjust=-900

Теперь, когда память кончится, Linux убьет веб-сервер, кэш, SSH-сессию, но база данных останется стоять до последнего.

#linux #kernel #oom #postgresql #sysadmin #reliability #systemd 🛡️

🐧 Linux: systemd-run — запускаем скрипты в «песочнице» на лету 🛡️

Запускаешь тяжелый бэкап или скрипт миграции и боишься, что он съест всю память и положит прод? Не нужно писать сложные unit-файлы. В 2026 году админы используют Transient Scopes (временные скоупы).

Команда systemd-run позволяет обернуть любую команду в полноценный сервис с лимитами ресурсов прямо из консоли.

Команда дня:

# Запускаем скрипт, даем ему максимум 500Мб RAM и низкий приоритет CPU
systemd-run --scope -p MemoryMax=500M -p CPUWeight=20 ./heavy_script.sh

Что происходит: Скрипт запускается как обычно, но ядро Linux (cgroups) держит его в жестких рукавицах. Если скрипт попытается съесть 501 Мб — он будет убит (OOM), но основной сервер даже не поперхнется.

Почему это топ: Это идеальный способ тестировать лимиты для будущих сервисов или безопасно запускать "одноразовые" задачи на живом проде. 🧠

#linux #systemd #cgroups #performance #sysadmin #safety #devops

🐧 Linux: systemd-analyze security — узнай, насколько дырявые твои сервисы 🛡️

Ты поднял Nginx, базу данных и пару самописных демонов.
Они работают.
Но насколько они защищены от взлома, если в коде найдется уязвимость?
В 2026 году systemd имеет встроенный сканер безопасности, о котором многие забывают.

Он анализирует unit-файлы и выставляет оценку "опасности" от 0 (безопасно) до 10 (проходной двор).

Команда-аудитор:

systemd-analyze security

Как исправить "красные" зоны:
Выбери сервис с плохой оценкой (например, nginx.service) и посмотри детали:

systemd-analyze security nginx.service

Добавь в секцию [Service] файла юнита простые директивы изоляции:

[Service]
PrivateTmp=yes              # Свой /tmp, невидимый другим
ProtectSystem=strict        # Запрет записи в системные папки
ProtectHome=yes             # Запрет чтения /home
NoNewPrivileges=yes         # Запрет повышения прав (sudo)

Результат: Даже если сервис взломают, хакер окажется в "тюрьме" и не сможет навредить системе. Оценка упадет с 9.0 до 2.0. ✅

#linux #security #systemd #hardening #sysadmin #devops #audit

🐧 Linux: Быстрый тюнинг дескрипторов — исправляем «Too many open files» 📂

Бывает, что сервис (особенно нагруженный Nginx или БД) начинает захлебываться и сыпать ошибками `Too many open files`. Это значит, что процесс уперся в лимит открытых файловых дескрипторов. В 2026 году ручное редактирование `limits.conf` — это долго.

Как быстро проверить лимиты конкретного процесса:

# Берем PID процесса (например, 1234) и смотрим его мягкие и жесткие лимиты
cat /proc/1234/limits | grep "Max open files"

Как изменить лимит «на лету» без перезапуска всей системы (через systemd):
Если сервис управляется через systemd, создаем override-конфиг:

sudo systemctl edit nginx

Добавляем в открывшийся файл:

[Service]
LimitNOFILE=65535

Затем: `systemctl daemon-reload` и `systemctl restart nginx`.

Зачем это нужно: Современные приложения открывают сотни соединений и временных файлов.
Стандартный лимит в 1024 — это «бутылочное горлышко», которое ты теперь умеешь расширять за минуту.

#linux #systemd #performance #optimization #sysadmin #admin_future

🐧 Linux: Когда `/var/log/journal` съел диск — правильная диета для логов 🧹

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

Удалять файлы руками через `rm` — плохая примета (можно сломать целостность журнала). Делаем красиво через штатные инструменты.

Команды для очистки:

# 1. Смотрим, сколько реально занимают логи
journalctl --disk-usage

# 2. Оставляем логи только за последние 2 дня (остальное в /dev/null)
sudo journalctl --vacuum-time=2d

# 3. ИЛИ ограничиваем жестким размером (например, оставить 500 МБ)
sudo journalctl --vacuum-size=500M

Админский лайфхак: Чтобы не чистить вручную каждый раз, пропиши в `/etc/systemd/journald.conf` параметр `SystemMaxUse=1G` и перезапусти службу.

#linux #systemd #logs #maintenance #sysadmin #troubleshooting #admin_future

🐧 Linux: systemd-run — запускаем тяжелые задачи в «песочнице» без лишних конфигов

Часто бывает нужно запустить скрипт или тяжелую задачу (например, пересборку логов или парсинг), но ты боишься, что она «отъест» все ресурсы у боевого веб-сервера. Создавать полноценный .service файл лень? Используй systemd-run.

Техническая суть:
Команда создает временный (transient) юнит и позволяет лимитировать ресурсы (CPU, RAM, I/O) «на лету» прямо из командной строки.

Команда для запуска с лимитом памяти в 500МБ:

# Запускаем скрипт в отдельном слайсе с жестким лимитом по памяти
sudo systemd-run --scope -p MemoryMax=500M -p CPUWeight=50 ./heavy-script.sh
# Посмотреть статус этого временного юнита
systemctl status run-*.scope

Зачем это нужно:
Это намного надежнее, чем просто nice или ionice.
Ты гарантируешь, что скрипт не уронит сервер по OOM (Out Of Memory), даже если в коде утечка.

#linux #systemd #optimization #performance #sysadmin #admin_future

🐧 Linux: Убиваем демонов. Rootless Podman и systemd-quadlets на страже серверов

В 2026 году крутить жирного демона Docker от пользователя `root` — это не просто моветон, это красная тряпка для любого аудитора ИБ. В условиях тотального импортозамещения и перехода на защищенные отечественные ОС мы давно изолируем всё, что шевелится.

Под капотом:
Мы выкидываем Docker daemon и переходим на rootless Podman. А чтобы не страдать с docker-compose и кривыми авторестартами, отдаем управление жизненным циклом контейнеров нативному systemd через механизм Quadlets. Вы просто пишете декларативный юнит .container, а systemd сам генерирует сервис, следит за зависимостями, пробрасывает порты и пишет логи в journald. И всё это работает в пространстве обычного пользователя!

Практика:
Создаем файл /etc/containers/systemd/nginx-gost.container для запуска веб-сервера с поддержкой отечественной криптографии:

[Unit]
Description=GOST-enabled Nginx Web Server
After=network-online.target

[Container]
Image=registry.corp.local/nginx-gost:latest
PublishPort=8080:80
Environment=TLS_MODE=strict
Volume=/srv/web:/usr/share/nginx/html:ro

[Install]
WantedBy=multi-user.target

Перезагружаем демона и стартуем:

systemctl daemon-reload
systemctl start nginx-gost.service

Зачем это нужно:
Если злоумышленник и пробьет ваш веб-сервер, он окажется заперт в непривилегированном user namespace. Нулевой риск компрометации ядра, идеальная интеграция с системными логами и чистая архитектура без лишних прослоек.

#linux #podman #systemd #security #admin_future

🐧 Linux: Забываем про sudo. Встречаем run0 от systemd

Коллеги, если вы думали, что systemd уже поглотил все что мог, то вы ошибались. В современных дистрибутивах разработчики добрались до святая святых — утилиты sudo. Встречайте: run0. В 2026 году это новый стандарт повышения привилегий.

Почему sudo устарел:

Классический sudo существует десятилетиями. Его главная проблема — он опирается на SUID-биты (Set-user-ID). Это огромная кодовая база, работающая с правами root. Любая уязвимость в sudo — это моментальный взлом всей системы, что мы уже не раз наблюдали в истории кибербезопасности.

Как работает run0:

— Без SUID: run0 вообще не использует SUID-бинарники.
— Временная песочница: Он просит диспетчер служб systemd создать временный изолированный контекст (pty) и запускает процесс там.
— Интеграция с polkit: Права проверяются через штатный механизм polkit, а не через громоздкий конфигурационный файл sudoers.
— Визуальный контроль: Когда вы работаете через run0, терминал меняет цвет фона (например, на красноватый оттенок), чтобы вы физически видели, что находитесь в режиме бога и любые команды могут быть фатальны.

Как попробовать:
Если у вас дистрибутив с systemd версии 256 и выше, просто напишите в консоли:

run0 bash

Эра sudo медленно, но верно уходит. Меньше кода, меньше площадь атаки, больше интеграции с базовой системой. Привыкаем к новому синтаксису и безопасному повышению прав.

#linux #systemd #run0 #security #sysadmin #admin_future

🐧 Linux: systemd 260 убил SysV — и если у тебя ещё живёт /etc/init.d, читай срочно

Коллеги, 17 марта 2026 года вышел systemd 260 — и он сделал то, о чём предупреждали несколько лет. Наиболее разрушительное изменение: полное удаление поддержки System V init-скриптов. Компоненты systemd-sysv-generator, systemd-sysv-install и rc-local.service удалены окончательно. Никакого мягкого устаревания — мост сожжён.

Если у вас в продакшне живут legacy-сервисы со скриптами в /etc/init.d/ — они тихо перестанут запускаться после обновления. Без ошибок в журнале. Просто не стартуют.

Но в этом же релизе есть кое-что интересное: добавлен новый параметр MemoryTHP= для управления Transparent Huge Pages на уровне отдельного сервиса, а CPUSchedulingPolicy= теперь поддерживает значение ext для включения планировщика SCHED_EXT. Для высоконагруженных сервисов — это прямой рычаг тонкой настройки без правки параметров ядра глобально.

Сначала — аварийный аудит. Находим всё, что ещё на SysV:

# Ищем живые SysV-скрипты в системе
find /etc/init.d/ -type f -not -name "README" 2>/dev/null

# Проверяем, нет ли сервисов без native unit-файла
# (до обновления на systemd 260 — sysv-generator ещё конвертировал их)
systemctl list-units --type=service --state=loaded | grep -v ".service"

# Смотрим, какие сервисы СЕЙЧАС запущены через SysV-совместимость
systemctl list-units --type=service | \
  while read unit _; do
    unit_file=$(systemctl show "$unit" -p FragmentPath --value 2>/dev/null)
    [[ "$unit_file" == /etc/init.d/* ]] && echo "LEGACY SysV: $unit -> $unit_file"
  done

# Для найденного legacy-сервиса пишем нормальный unit.
# Пример: конвертируем старый /etc/init.d/myapp
cat > /etc/systemd/system/myapp.service << 'EOF'
[Unit]
Description=My Legacy Application
After=network.target

[Service]
Type=forking
ExecStart=/usr/local/bin/myapp --daemon
ExecStop=/usr/local/bin/myapp --stop
PIDFile=/var/run/myapp.pid
Restart=on-failure
RestartSec=5s

# Новое в systemd 260: тонкая настройка памяти для сервиса
# Отключаем THP для Java-приложений (они его не любят)
MemoryTHP=never

[Install]
WantedBy=multi-user.target
EOF

systemctl daemon-reload
systemctl enable --now myapp.service
systemctl status myapp.service

Зачем это нужно:
Сервисы, у которых нет native unit-файлов, после обновления на systemd 260 не запустятся тихо и без предупреждений. Самый критичный action item для всех администраторов — провести аудит и мигрировать оставшиеся SysV init-скрипты до обновления. Ubuntu 26.04 LTS выходит 23 апреля и несёт systemd 260 по умолчанию. Срок — неделя.

Итог: SysV жил с 1983 года. Хватит. Если у тебя до сих пор есть /etc/init.d/что-то — это не legacy, это пожарная опасность. Миграция на unit-файл занимает 15 минут. Объяснение инциденту на встрече с Романом — значительно дольше.

#linux #systemd #sysv #sysadmin #ubuntu #admin_future

🐧 Linux: systemd hardening — твои сервисы запущены в привилегиях которые им не нужны

Коллеги, большинство unit-файлов в продакшне выглядят так: Type=simple, ExecStart=..., Restart=on-failure — и всё. Сервис запускается с правами процесса, может писать куда угодно, видит всю файловую систему и весь сетевой стек. Это нормально для 2010 года.

В systemd 260 (Ubuntu 26.04, Fedora 44) появились дополнительные директивы изоляции и Memory THP-контроль на уровне юнита. Но главное — большинство директив безопасности были доступны давно, просто их не используют.

# Оцениваем текущий security score сервиса
systemd-analyze security nginx
# Покажет оценку от 0 (UNSAFE) до 10 (SAFE) и что именно проседает

# Добавляем hardening в override без правки оригинального юнита:
systemctl edit nginx

# /etc/systemd/system/nginx.service.d/override.conf
[Service]
# Приватная /tmp — сервис не видит /tmp хоста
PrivateTmp=true

# Запрет на запись в домашние директории
ProtectHome=true

# /usr, /boot, /etc монтируются read-only
ProtectSystem=strict

# Разрешаем писать только в нужные директории
ReadWritePaths=/var/log/nginx /var/cache/nginx /run/nginx

# Убираем все capabilities кроме нужных
CapabilityBoundingSet=CAP_NET_BIND_SERVICE
AmbientCapabilities=CAP_NET_BIND_SERVICE

# Запрет на новые привилегии через setuid/setgid
NoNewPrivileges=true

# Только нужные syscall-группы
SystemCallFilter=@system-service
SystemCallErrorNumber=EPERM

# Изолируем сетевые namespace-ы (если сервис только слушает)
# PrivateNetwork=true  # раскомментировать для полной изоляции

# Контроль памяти (новое в systemd 260)
# Отключаем THP для сервисов где он мешает (Java, Redis)
MemoryTHP=never

# После правки:
systemctl daemon-reload && systemctl restart nginx

# Проверяем новый score
systemd-analyze security nginx
# Цель: зелёный (8+)

Зачем это нужно:
Скомпрометированный nginx с PrivateTmp и ProtectSystem=strict не доберётся до ваших SSH-ключей, конфигов баз данных или других сервисов. Изоляция на уровне юнита — это дешёвый слой defence-in-depth, который не требует контейнеров.

Итог: запусти systemd-analyze security на своих сервисах сегодня. Гарантирую — будет неприятно, но полезно.

#linux #systemd #hardening #security #sysadmin #admin_future

🐧 Linux: Хватит терпеть зависания при OOM. Включаем PSI и systemd-oomd

Коллеги, добрый понедельник. Знакомая ситуация: на сервере потекла память, своп забился, load average улетел в космос, и вы даже по SSH зайти не можете. Классический OOM Killer в ядре срабатывает слишком поздно, когда система уже фактически в коме.

В 2026 году мы решаем это изящнее. Мы используем PSI (Pressure Stall Information) вместе с systemd-oomd. Этот демон убивает прожорливые cgroups ДО того, как операционная система намертво повиснет.

Скрипт для проверки и активации:

# Проверяем, включен ли PSI в ядре (вывод не должен быть пустым):
cat /proc/pressure/memory

# Если включен, активируем службу systemd-oomd:
systemctl enable --now systemd-oomd

# Смотрим статус и кто сейчас под угрозой:
oomctl status

Зачем это нужно:
Сервер должен оставаться управляемым при любых утечках памяти. Лучше пусть упадет один проблемный контейнер или веб-сервис, чем вся нода уйдет в hard reset по питанию, утащив за собой соседние процессы.

#linux #systemd #oom #performance #sysadmin #admin_future

🧠 Skills: journalctl — 10 команд, которые заменяют grep по /var/log

Коллеги, навык недели. Начиная с Debian 12 rsyslog по умолчанию не ставится — классических текстовых логов на свежих инсталляциях может просто не быть. Всё уходит в бинарный журнал systemd-journald.

🛠 10 БАЗОВЫХ КОМАНД
Bash

# 1. Только ошибки (от err и выше) с момента текущего старта системы
journalctl -p err -b

# 2. Логи конкретного сервиса за последний час
journalctl -u nginx --since "1 hour ago"

# 3. Режим live-мониторинга (аналог tail -f) по конкретной службе
journalctl -u ssh -f

# 4. Список всех зафиксированных загрузок ОС (с их ID и временными метками)
journalctl --list-boots

# 5. Сообщения ядра (dmesg) за ПРЕДЫДУЩУЮ загрузку (ключевое при анализе падений)
journalctl -k -b -1

# 6. Фильтр по исполняемому файлу в чистом текстовом выводе
journalctl _COMM=sshd -o cat | grep -i 'failed'

# 7. Выборка событий в жестком временном окне
journalctl --since "2026-10-05 09:00" --until "2026-10-05 10:00"

# 8. Просмотр структуры записи со всеми служебными метаполями (для построения точных фильтров)
journalctl -o json-pretty -n 1

# 9. Проверка дискового пространства, занятого журналами прямо сейчас
journalctl --disk-usage

# 10. Ротация и очистка архивов старше 30 дней
journalctl --vacuum-time=30d

⚠️ ПРОВЕРЬТЕ ПЕРСИСТЕНТНОСТЬ (сохраняются ли логи после ребута)
Bash

# Проверка наличия каталога постоянного хранения
ls -d /var/log/journal 2>/dev/null && echo "Логи пишутся на диск" || echo "ВНИМАНИЕ: логи живут только в RAM до ребута!"

# Проверка конфигурации лимитов
grep -E '^(Storage|SystemMaxUse)' /etc/systemd/journald.conf

Если каталога /var/log/journal нет — журнал по дефолту сбрасывается в tmpfs (RAM). После аварийной перезагрузки расследовать причину сбоя будет физически невозможно:

Bash

# Включение постоянного хранения логов на диске
mkdir -p /var/log/journal && systemctl restart systemd-journald

💡 В ЧЁМ СУТЬ

Связка флагов

-b -1

и

-p err

закрывает 80% всех типовых инцидентов из серии «почему сервер упал ночью».

Персистентное хранилище на диске с жестко зафиксированным лимитом

SystemMaxUse

в

journald.conf

— обязательный базовый харденинг, который настраивается сразу после установки ОС.

#skills #linux #systemd #journalctl #debian #troubleshooting #sysadmin #admin_future

🐧 Ubuntu 26.10 вышла: systemd 261 больше не поддерживает SysV-скрипты. Проверьте свои /etc/init.d

Коллеги, 15 октября состоялся релиз Ubuntu 26.10 «Stonking Stingray». Главное для серверов — не десктопный GNOME, а низкоуровневые изменения в подсистеме инициализации systemd.

📌 ФАКТЫ
Ядро Linux 7.3 (стартовый пакет собран на 7.3-rc6), поддержка 9 месяцев — до июля 2027

systemd 261 убрал поддержку SysV-скриптов (/etc/init.d/*)

Rust coreutils (uutils): в 26.10 на них переведены и cp, mv, rm

OpenSSL 4: Encrypted Client Hello, расширенный QUIC, улучшения постквантовой криптографии

dbus-broker вместо dbus-daemon, Sequoia PGP в main, вход через authd с паролем Microsoft и MFA

🛠 НАЙТИ СЛУЖБЫ НА SYSV-СКРИПТАХ
Bash

# Службы, которые systemd сейчас генерирует из /etc/init.d
for u in $(systemctl list-unit-files --type=service --no-legend | awk '{print $1}'); do
  systemctl show -p SourcePath --value "$u" | grep -q '^/etc/init.d/' && echo "$u"
done

Обычно туда попадают старые агенты мониторинга и бэкапа, ПО железа (RAID, ИБП), самописные демоны. На 26.10 они просто не запустятся.

💡 В ЧЁМ СУТЬ

26.10 — промежуточный релиз, на продакшен ставить не обязательно. Но это предупреждение: изменения из него придут в следующую LTS. Переписать init-скрипт на unit-файл — 15 минут. Делать это сейчас дешевле, чем после обновления.

#linux #ubuntu #systemd #migration #sysadmin #admin_future

🦀 systemd разрешил компоненты на Rust. Первым будет systemd-keyring-setup

Коллеги, интересное из мира Linux — продолжение тренда «Rust в базовой системе».

📌 ФАКТЫ
В кодовую базу systemd влита поддержка сборки отдельных утилит и компонентов на Rust в дополнение к C. Изменения войдут в релиз systemd 263

Ядро systemd (PID 1 и общая библиотека libsystemd) целиком остаётся на классическом C

Интеграция сделана опциональной: флаг сборки Meson -Drust=, по умолчанию выставлен в auto. Сборка завязана на Meson без прямого вызова Cargo

Переписывать существующий рабочий C-код разработчики не планируют

Первый пилотный компонент — systemd-keyring-setup: отвечает за раннюю инициализацию системных связок ключей ядра (keyrings) и регистрацию X.509-сертификатов для валидации dm-verity, fs-verity и подписанных BPF-программ

📊 ОБЩИЙ КОНТЕКСТ В ЭКОСИСТЕМЕ
В Ubuntu 26.10 завершен перевод ключевых утилит на Rust coreutils (uutils)

В планах Ubuntu 27.04 — переход на синхронизацию времени через ntpd-rs по умолчанию

В ядро Linux 7.4 заявлено уже более 17 тыс. строк новой инфраструктуры и драйверов на Rust

🛠 АДМИНУ НА ПРАКТИКЕ
Bash

# Проверяем версию systemd на хосте
systemctl --version | head -1

Для повседневной эксплуатации формат работы не меняется: привычные unit-файлы, синтаксис systemctl, journalctl и поведение демонов остаются прежними.

💡 В ЧЁМ СУТЬ

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

Для продакшена это шаг к сокращению privilege escalation векторов в low-level компонентах, а для тех, кто собирает минималистичные кастомные дистрибутивы из исходников, — сигнал готовить тулчейн

rustc

в сборочном окружении.

#linux #systemd #rust #opensource #sysadmin #admin_future