Как Debian 13 работает с sysctl: куда делся /etc/sysctl.conf и как теперь правильно настраивать систему

После обновления до Debian 13 файла /etc/sysctl.conf больше нет, а настройки теперь в других местах. Разбираемся, почему так происходит, как работает systemd‑sysctl, где теперь лежат конфигурации и как безопасно вносить свои изменения через /etc/sysctl.d, чтобы они не потерялись при обновлении системы.

Введение

После выхода Debian 13 появилось неожиданное изменение: привычный файл /etc/sysctl.conf пропал, а пользовательские настройки ядра перестали применяться. Это особенно проявляется при обновлении с Debian 12, когда старый файл оказывается переименован и скрыт от стандартного процесса загрузки параметров ядра.

В этой статье разберёмся, почему так происходит, какую роль теперь играет служба systemd-sysctl, где хранятся актуальные конфигурационные файлы и как правильно вносить свои изменения, чтобы они не потерялись при очередном обновлении системы.

Что происходит с /etc/sysctl.conf при обновлении до Debian 13

В одном из комментариев к статье про обновление Debian 12 до Debian 13 Trixie упомянули одно наблюдение. В процессе обновления система удаляет файл /etc/sysctl.conf, а его предыдущая версия сохраняется как /etc/sysctl.conf.dpkg-bak.

В результате:

• все изменения, которые вы когда‑то внесли в /etc/sysctl.conf, перестают применяться;
• настройки по‑прежнему физически присутствуют в резервной копии, но система их не читает автоматически.

Такого раньше не было с sysctl.conf. Это исторически основной файл для параметров ядра, в который часто вносятся правки вручную.

Почему в Debian 13 по умолчанию нет /etc/sysctl.conf

В Debian 13 разработчики убрали /etc/sysctl.conf по умолчанию. За применение параметров ядра теперь отвечает служба systemd-sysctl, которая ориентируется на конфигурационные файлы в каталогах sysctl.d.

Основное место для системных настроек теперь в /usr/lib/sysctl.d/. Здесь находятся файлы, которые входят в состав дистрибутива и установленных пакетов.

При этом стандартный каталог /etc/sysctl.d по‑прежнему может использоваться, и его содержимое также подхватывается при загрузке системы. Таким образом, вместо файла /etc/sysctl.conf теперь предпочтительно дробить настройки по конфигурационным файлам в /usr/lib/sysctl.d/ или /etc/sysctl.d.

В Linux давно сформировалась устоявшаяся практика: вместо правки «основного» конфигурационного файла используются специальные директории с суффиксом .d. В этих директориях хранятся корректирующие и дополняющие конфиги, которые накладываются поверх базовых настроек.

Для sysctl это:

• раньше каталог /etc/sysctl.d, куда рекомендуется помещать свои файлы;
• в Debian 13 основной акцент смещён на /usr/lib/sysctl.d/, но /etc/sysctl.d пока по‑прежнему поддерживается.

Схема примерно такая:

• базовые настройки поставляются пакетами в /usr/lib/sysctl.d;
• локальные/пользовательские настройки добавляются в /etc/sysctl.d;

Система при запуске читает все файлы с расширением .conf в этих директориях и применяет параметры в определённом порядке.

Как правильно вносить свои настройки sysctl в Debian 13

Рекомендация для Debian 13 и современных систем следующая: не правьте напрямую /etc/sysctl.conf, а добавляйте отдельные файлы в /etc/sysctl.d/.

Вносим правки так:

• Определяем параметр, который хотим изменить (например, включить форвардинг IPv4).
• Создаём отдельный конфигурационный файл в /etc/sysctl.d.
• Используем расширение .conf, чтобы файл был применён.
• Вручную применяем настройки командой sysctl -p с указанием файла.

Рассмотрим типичную задачу: нужно включить форвардинг пакетов между сетевыми интерфейсами, например для маршрутизатора или VPN‑шлюза. Вместо редактирования старого /etc/sysctl.conf используем современный подход через sysctl.d.

Создаём файл /etc/sysctl.d/forward.conf. Пишем в него:

net.ipv4.ip_forward = 1

Применяем вручную для проверки:

# sysctl -p /etc/sysctl.d/forward.conf

В выводе увидим подтверждение:

net.ipv4.ip_forward = 1

Так настройка начнёт работать сразу и сохранится между перезагрузками, не конфликтуя с пакетными обновлениями и не завися от существования /etc/sysctl.conf.

Почему важно избегать правок основных конфигов

У многих, в том числе меня, есть привычка хранить все настройки в одном файле. У такого подхода есть плюс: вся конфигурация сервиса находится в одном месте, её легко просмотреть и быстро понять общую картину. Например, мне удобнее держать всю конфигурацию Postfix или Dovecot в одном общем файле. А для Nginx или Logstash логичнее использовать разные файлы, так как там есть понятное смысловое разделение: виртуальные хосты, пайплайны обработки логов и т.п.

Основные конфиги часто управляются пакетным менеджером, и при обновлении они могут быть перезаписаны или заменены новой версией. Файл может быть обновлён, а старая версия сохранена рядом с расширением .dpkg-bak или аналогичным.

Использование .d‑директорий и отдельных конфигурационных файлов позволяет не  конфликтовать с обновлениями пакетов. Они чётко разделают ваши изменения от настроек по умолчанию. Их проще проще переносить между серверами и документировать.

Подход с корректирующими конфигами в отдельных директориях давно стал типичным для Linux‑сервисов. Вот несколько распространённых примеров:

• /etc/zabbix/zabbix_agentd.d — дополнительные настройки Zabbix Agent;
• /etc/fail2ban/fail2ban.d — локальные правки для Fail2Ban;
• /etc/dovecot/conf.d — фрагменты конфигурации почтового сервера Dovecot;
• /etc/sudoers.d — дополнительные правила для sudo, вместо правки основного /etc/sudoers;
• /etc/mysql/mariadb.conf.d — корректирующие конфиги для MariaDB/MySQL;
• /etc/logstash/conf.d — отдельные файлы с пайплайнами для Logstash.

Если вы встречаете у службы каталог с суффиксом .d, почти наверняка именно он предназначен для ваших кастомных настроек поверх стандартных.