Почему systemd-таймер срабатывает не тогда, когда вы ждёте?

Настроили systemd-таймер, всё вроде по документации. Но скрипт не запускается, или запускается не в то время? Это не баг — это AccuracySec.

1️⃣Что такое AccuracySec и зачем он нужен?

По умолчанию systemd не гарантирует миллисекундную точность.

Чтобы сэкономить ресурсы, он может откладывать таймер до ближайшего «удобного» момента. Именно это делает AccuracySec.

Пример:

[Timer]
OnCalendar=*-*-* 03:00:00
AccuracySec=1s

Если не задать AccuracySec, systemd может спокойно сдвинуть запуск на несколько минут вперёд — и вы будете гадать, почему бэкап не стартует ровно в 03:00.

2️⃣ Как проверить, что ваш таймер вообще живой?

systemctl list-timers

Покажет ближайшее время запуска и прошедшие срабатывания. Если не видите свой таймер — возможно, вы забыли Enable=true.

3️⃣Почему OnBootSec не сработал после перезагрузки?

Это типовая ошибка: вы включили таймер, но не активировали сам юнит.
Проверьте:

systemctl status your-timer.timer

А ещё — не забывайте, что OnBootSec=5min означает запуск спустя 5 минут после загрузки, а не сразу.

4️⃣ Хотите запуск точно по расписанию?

Сделайте AccuracySec=1s, и systemd не будет «оптимизировать» время:

[Timer]
OnCalendar=*-*-* 05:00:00
AccuracySec=1s
Persistent=true

Persistent=true важен, если хотите, чтобы задача выполнилась после выключения — она «догонит» при следующем старте

Вышел AlmaLinux 9.6 — синхронизирован с RHEL 9.6

20 мая 2025 года вышел стабильный релиз AlmaLinux 9.6. Дистрибутив основан на ядре Linux 5.14 и полностью бинарно совместим с Red Hat Enterprise Linux 9.6.

Доступны сборки для x86_64, ARM64, ppc64le и s390x.

Проект поддерживается некоммерческой AlmaLinux OS Foundation, распространяется бесплатно и развивается открытым сообществом.

Обновления и особенности:
⏺Улучшенная производительность и безопасность
⏺Удалены RHEL-специфичные пакеты (insights-client, subscription-manager и др.)
⏺Расширена поддержка оборудования (LSI, Adaptec, Dell, QLogic и др.)
⏺Репозиторий Synergy — дополнительное ПО (Pantheon, Warpinator и др.)

zombie процессы

Иногда вы запускаете top или ps aux, и вдруг замечаете статус Z. Это зомби-процесс. Он уже умер, но остался в таблице процессов, потому что его родитель не вызвал wait().

Такое бывает из-за багов, утечек, криво написанных демонов или скриптов.

Диагностика

Показать все зомби в системе:

ps -eo pid,ppid,state,cmd | grep ' Z '

Пример вывода:

1234  567   Z    [my-dead-child]

1234 — это PID зомби.
567 — это PPID — родитель, который должен был вызвать wait().

Посмотреть, кто этот родитель:

ps -p 567 -o pid,comm

Если родитель всё ещё жив, но “не собирает” зомби — это потенциальная проблема.

Что делать?

⏺Если это ваш сервис/скрипт — проверьте, обрабатываете ли вы SIGCHLD и вызываете ли wait() в родителе. В bash это можно сделать так:

while true; do
  ./child &
  wait $!
done

⏺Перезапустите родительский процесс, чтобы он корректно завершил своих детей:

systemctl restart <service>

⏺Если родитель — PID 1 (init/systemd) — зомби обычно исчезают автоматически, как только systemd обрабатывает SIGCHLD.

Создаём зомби для отладки

Если хотите поэкспериментировать:

// zombie.c
#include <stdlib.h>
#include <unistd.h>

int main() {
    if (fork() > 0) {
        sleep(60); // родитель спит, не вызывает wait
    } else {
        exit(0); // ребёнок умирает
    }
}

Компилируем и запускаем:

gcc zombie.c -o zombie
./zombie
ps aux | grep Z

Чем больше у вас данных, тем страшнее их потерять 👀

29 мая в 11:00 облачный провайдер Cloud․ru расскажет, как защитить бизнес от потери данных с помощью облачных технологий.

Что будет на вебинаре:
🤖 Непрерывность данных — почему без бэкапов бизнес в зоне риска.
🤖 Резервное копирование и аварийное восстановление — когда и зачем нужно.
🤖 Облако для защиты данных — как и зачем использовать.
🤖 Дополнительные методы защиты — что еще важно учитывать.

Будет live-демо — эксперт покажет настройку резервного копирования и восстановления в прямом эфире.

Зарегистрироваться на вебинар🖱

Правильное отношение к сервакам🥰

“Too many open files”: куда утекают дескрипторы

Сервисы начинают сыпать ошибками:

EMFILE: Too many open files

Но ulimit -n вроде нормальный. Что происходит?

⏺Причина:

Открытые файлы — это не только обычные файлы, но и сокеты, пайпы, устройства.

У каждого процесса есть лимит на количество открытых дескрипторов (nofile). При его превышении начинаются ошибки.

Проверка лимитов

ulimit -n                # лимит текущей сессии
cat /proc/$$/limits      # все лимиты текущего процесса

⏺Поиск виновника
Показываем процессы с наибольшим числом открытых файлов:

for pid in $(ls /proc | grep -E '^[0-9]+$'); do
  count=$(ls /proc/$pid/fd 2>/dev/null | wc -l)
  echo "$count $pid"
done | sort -nr | head

Смотрим, что именно открыто у подозреваемого:

ls -l /proc/<PID>/fd

⏺Что делать?

Если утекают дескрипторы — проверьте код, особенно вызовы open() и close().

Если активно растёт число сетевых соединений — проверьте, не остаются ли открытые сокеты:

netstat -anp | grep <PID>

Как увеличить лимит

# Временно
ulimit -n 65535

# Постоянно — /etc/security/limits.conf
* soft nofile 65535
* hard nofile 65535

Для systemd-сервисов:

[Service]
LimitNOFILE=65535

Когда sshd пускает всех: настройка ограничения доступа по IP и ключам

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

Как быстро проверить и настроить безопасный доступ?

1️⃣Проверяем текущие подключения и логи SSH

ss -tnpa | grep sshd
journalctl -u sshd -e

Смотрим, кто подключается и есть ли ошибки аутентификации.

2️⃣Ограничиваем доступ по IP в sshd_config

Добавьте в /etc/ssh/sshd_config:

AllowUsers [email protected].*
DenyUsers user2@*

Или используйте AllowGroups с похожим синтаксисом.

3️⃣ Разрешаем доступ только по ключам, отключаем пароль

PasswordAuthentication no
PubkeyAuthentication yes

4️⃣ Проверяем разрешённые ключи в ~/.ssh/authorized_keys

Убедитесь, что ключи корректные и права на папку и файл строго выставлены:

chmod 700 ~/.ssh
chmod 600 ~/.ssh/authorized_keys

5️⃣ Перезапускаем sshd

systemctl restart sshd

6️⃣ Тестируем подключение с нужных IP и с ключами

Если не работает — запускайте ssh с повышенной детализацией:

ssh -vvv user@server

7️⃣ При подозрениях — включаем дополнительный лог в sshd_config:

LogLevel VERBOSE

Это поможет понять, почему соединение не проходит.

💬 Вопрос на собеседовании для DevOps-инженера

Давайте разберем один из частых вопросов, который может быть задан на собеседовании и как на него отвечать.

❓Вопрос: Как работает oom-killer в Linux и как с ним работать, чтобы минимизировать негативные последствия?

✅Ответ: oom-killer (Out-Of-Memory Killer) — это механизм ядра Linux, который срабатывает, когда системе не хватает оперативной памяти, и она не может выделить память ни одному из процессов. В такой ситуации oom-killer выбирает и завершает “наименее ценную” с точки зрения ядра задачу, чтобы освободить ресурсы.

Как с ним работать:

— Поведение можно контролировать с помощью параметра oom_score_adj. Чем выше значение (макс. 1000), тем выше вероятность, что процесс будет убит.
— Можно настроить cgroups и ограничить память для отдельных групп процессов, чтобы сбои не затрагивали всю систему.
— Желательно использовать swap-файл/раздел, чтобы отложить момент срабатывания OOM, но не полагаться на это как на основную защиту.

Релиз Rust Coreutils 0.1.0

24 мая 2025 вышла версия 0.1.0 проекта Rust Coreutils (uutils) — кроссплатформенной альтернативы GNU Coreutils, написанной на Rust.

В набор входят популярные утилиты: ls, cp, cat, chmod, date и другие.

Цель — создать производительную и безопасную замену Coreutils, которая будет работать на Linux, Windows, Redox и Fuchsia. 

Rust Coreutils уже будет использоваться по умолчанию в Ubuntu 25.10.

Основные улучшения версии 0.1.0:
⏺Поддержка SELinux в ключевых утилитах (cp, ls, mkdir, stat и др.).
⏺Оптимизации производительности: uutils в ряде случаев быстрее GNU.
⏺Улучшена совместимость с тестами GNU Coreutils (522 успешных теста).
⏺Расширены функции и добавлены опции во многие утилиты.

Проект распространяется под MIT-лицензией — более либеральной, чем GPL у GNU Coreutils.

Bonding интерфейсов в Linux: простая настройка для отказоустойчивости и скорости

Bonding - это объединение нескольких физических сетевых интерфейсов в один логический, чтобы увеличить пропускную способность или обеспечить резервирование.

Зачем нужно?

• Если один кабель или интерфейс упадёт, сеть не потеряется.
• Можно повысить скорость, суммируя каналы.

Как проверить, поддерживается ли bonding?

modprobe bonding
lsmod | grep bonding

Простой пример конфигурации (mode=1 — active-backup):

⏺Создаём файл /etc/sysconfig/network-scripts/ifcfg-bond0 (для RHEL/CentOS):

DEVICE=bond0
TYPE=Bond
BONDING_MASTER=yes
BOOTPROTO=none
ONBOOT=yes
BONDING_OPTS="mode=1 miimon=100"

⏺Настраиваем интерфейсы, которые в bonding, например /etc/sysconfig/network-scripts/ifcfg-eth0:

DEVICE=eth0
BOOTPROTO=none
ONBOOT=yes
MASTER=bond0
SLAVE=yes

Аналогично для eth1.

⏺Перезапускаем сеть:

ifdown eth0 eth1
ifup bond0

Что важно знать:

1️⃣Режим bonding влияет на логику работы: active-backup — резервирование, balance-rr — агрегация с балансировкой нагрузки, другие — для продвинутых сценариев.

2️⃣На коммутаторе тоже нужно настроить LACP или соответствующий режим.

Автопробуждение по Wake-on-LAN

Иногда сервер должен спать — например, ночью или в выходные.

Но нужно, чтобы он включался сам: для бэкапа, обновлений, задач по cron. Wake-on-LAN (WOL) решает это, если правильно настроить.

1️⃣Включаем WOL в BIOS/UEFI

Ищем опции вроде Wake on LAN, Power On By PCI-E, Resume by LAN. Иногда нужно разрешить включение от сетевой карты.

2️⃣Настраиваем интерфейс в системе

Проверяем, поддерживает ли интерфейс WOL:

ethtool eth0

В выводе ищем:

Wake-on: d

d — выключено. Включаем:

ethtool -s eth0 wol g

Тип g — классический “magic packet”.

Чтобы сохранялось после перезагрузки — добавьте в rc.local или systemd unit.

3️⃣Отправляем magic packet с другого хоста

Узнаём MAC-адрес сервера:

ip link show eth0

Отправляем:

wakeonlan 00:11:22:33:44:55

или

etherwake -i eth0 00:11:22:33:44:55

WOL работает только в одной подсети (обычно UDP broadcast).

4️⃣Автоматический запуск по расписанию

Пример cron-задачи на другом хосте:

0 3 * * * /usr/bin/wakeonlan 00:11:22:33:44:55

Или запускаем вручную скриптом, когда хотим включить сервер под задачу.

Проверим: включается ли сервер?

• Сервер должен быть выключен (но не полностью обесточен).
• Сетевая карта должна гореть (светодиоды).
• Wake-on-LAN должен быть разрешён и в BIOS, и в ОС.

💬 Вопрос на собеседовании для сисадмина

Давайте разберем один из частых вопросов, который может быть задан на собеседовании и как на него отвечать.

❓Вопрос: Что такое Transparent Huge Pages (THP) в Linux и как они влияют на производительность?

✅Ответ: Transparent Huge Pages (THP) — это механизм Linux, автоматически объединяющий обычные страницы памяти (обычно по 4 KB) в более крупные страницы (обычно по 2 MB), чтобы сократить накладные расходы на управление памятью и ускорить доступ.

Проверить текущее состояние THP можно командой:

cat /sys/kernel/mm/transparent_hugepage/enabled

Отключить, если они мешают:

echo never > /sys/kernel/mm/transparent_hugepage/enabled

Бэкапы без rsync: моментальные снапшоты с Btrfs

Если у вас раздел на Btrfs — можно делать моментальные резервные копии за секунду, без копирования данных.

1️⃣Создаём снапшот

btrfs subvolume snapshot /home /btrfs-backups/home-$(date +%F)

Мгновенно создаётся снимок текущего состояния. Это не копия файлов — это ссылка на те же блоки.

2️⃣Откат к снапшоту

mv /home /home-old
btrfs subvolume snapshot /btrfs-backups/home-2025-05-28 /home

Можно быстро откатиться без rsync и без восстановления из архива.

3️⃣Монтируем снапшот отдельно

mount -o ro,subvol=home-2025-05-28 /dev/sdX /mnt/snapshot

Открываем снапшот как read-only и вытаскиваем нужные файлы.

4️⃣Удаление старых снапшотов

btrfs subvolume delete /btrfs-backups/home-2025-04-01

Удаляется мгновенно, освобождая место.

5️⃣Автоматизация через cron

Добавьте в crontab -e:

0 2 * * * btrfs subvolume snapshot /home /btrfs-backups/home-$(date +\%F)

Снапшоты будут создаваться каждый день в 2:00.

Sudo под контролем: аудит и ограничения для продакшена

Иногда sudo — это дыра в безопасности. Особенно, если все команды идут в лог просто как sudo bash.

Вот как сделать использование sudo прозрачным и контролируемым.

⏺Включаем логирование команд с точностью до аргументов

Добавьте в /etc/sudoers:

Defaults log_input, log_output
Defaults logfile="/var/log/sudo.log"

Теперь всё, что делает пользователь с sudo, пишется в лог.

⏺Ограничиваем команды

Разрешаем user1 только перезапуск nginx и просмотр логов:

user1 ALL=(ALL) NOPASSWD: /bin/systemctl restart nginx, /bin/journalctl -u nginx

Никаких sudo bash — только строго определённые команды.

⏺Проверяем логи sudo

cat /var/log/sudo.log | less
ausearch -k sudo

Анализируем, кто запускал sudo, когда, и что именно делал.

⏺Используем sudoreplay

Для продвинутого аудита:

sudo sudoreplay <ID>

Показывает ввод и вывод команды из лога log_input, log_output.

⏺Пример защиты от “sudo su”

В sudoers:

Cmnd_Alias BLOCKED = /bin/su, /bin/bash
user1 ALL=(ALL) !BLOCKED

Теперь нельзя поднять shell с sudo, только конкретные команды.