BitPage

Место на диске съели индексы, а не данные: раздувание b-tree, которое autovacuum не лечит

BitPage — Sun, 06 Sep 2026 06:30:00 +0300

Короткий ответ: если PostgreSQL занял диск, сначала разделите тело таблицы и её индексы — pg_relation_size против pg_indexes_size. При нагрузке из массовых вставок и удалений раздуваются именно индексы: b-tree освобождает только полностью опустевшие страницы, а полупустые оставляет в дереве навсегда. Плотность падает с дефолтных 90% до 13–15%, то есть индекс занимает вшестеро больше нужного. Autovacuum это не чинит ни при каких настройках — лечит только REINDEX. А привычный VACUUM FULL в такой ситуации опасен: он пишет вторую копию таблицы рядом и требует свободного места размером с неё.

Началось всё с алерта про диск на стенде. Закончилось тем, что «мало места» оказалось не проблемой места, а проблемой скорости: на проде нашёлся индекс с плотностью в районе 15%, по которому идёт основной поток чтения. Каждое обращение к нему разбирает страницы, заполненные на одну шестую.

Кластер тот же, что в истории про conflict with recovery и разборе bootstrap.dcs в Patroni: PostgreSQL 15 под Patroni, синхронная реплика, Laravel-приложение сверху. Там же описана и нагрузка, которая всё это создаёт, — крон, раз в четверть часа переписывающий крупную таблицу целиком.

Коротко (TL;DR)

Диагноз: раздуты индексы при здоровом теле таблицы. Проверяется одним запросом — pg_relation_size (heap) отдельно от pg_indexes_size.
Причина: b-tree переиспользует только полностью пустые страницы. Страница, с которой удалили все ключи кроме пары, остаётся в дереве занятой. PostgreSQL не сливает соседние разреженные страницы и не перебалансирует дерево.
Мера: avg_leaf_density из pgstatindex. Ориентир — 90%, дефолтный fillfactor для b-tree. Всё, что заметно ниже, — раздувание.
Лечение: REINDEX INDEX CONCURRENTLY по одному индексу. Пиковый оверхед — размер одного нового индекса, а не всей таблицы.
Чего не делать: VACUUM FULL ради индексов. Он пишет новую копию таблицы и не отпускает старую до конца операции — при нехватке места добьёт диск в ноль.
Грабля, которая портит данные: уникальный индекс с idx_scan = 0 не мёртвый. Проверка уникальности при вставке — не сканирование, счётчик она не трогает.
Прогноз выигрыша: размер × плотность / 90. На практике попадает в единицы процентов.

Почему «база распухла» — это два разных диагноза

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

Картина была такая (дальше все абсолютные величины модельные, соотношения — настоящие). Возьмём главную таблицу расчётов на два десятка миллионов строк: суммарно тридцать гигабайт, из них тело — четыре, а индексы — двадцать шесть. И рядом таблицу-кэш: живых строк ноль, тело в десятки мегабайт, индексы — под четыре гигабайта.

Тело на четыре гигабайта при двух десятках миллионов строк — норма, тут лечить нечего. Вся масса в индексах, соотношение примерно шесть к одному. Разделяющий запрос занимает одну строку:

1
2
3
4
5
6
7
8


SELECT relname,
 pg_size_pretty(pg_total_relation_size(relid)) AS total,
 pg_size_pretty(pg_relation_size(relid)) AS heap,
 pg_size_pretty(pg_indexes_size(relid)) AS idx,
 n_live_tup, n_dead_tup
FROM pg_stat_user_tables
ORDER BY pg_total_relation_size(relid) DESC
LIMIT 10;

Разница принципиальная. Раздутое тело лечит VACUUM FULL. Раздутые индексы при здоровом теле он тоже вылечит — попутно, перестроив их, — но заплатить придётся полной блокировкой и второй копией всей таблицы. Документация PostgreSQL про VACUUM FULL говорит прямо:

This method also requires extra disk space, since it writes a new copy of the table and doesn’t release the old copy until the operation is complete.

Вот тут и вылезает арифметика, из-за которой очевидный путь закрыт. На модельном стенде диск на 100 ГБ, занято 80, свободно 20. Таблица — 30. Свободного места меньше, чем размер таблицы, а VACUUM FULL требует положить рядом полную копию. Он не «долго отработает», он упрётся в ноль свободных байт на середине и оставит базу в интересном состоянии.

REINDEX идёт по одному индексу: пиковый оверхед — размер одного нового индекса, и место возвращается после каждого шага. Разница между «нужно 30 ГБ разом» и «нужно 4 ГБ на шаг» — это разница между «нельзя» и «можно прямо сейчас».

	`VACUUM FULL`	`REINDEX INDEX`	`REINDEX INDEX CONCURRENTLY`
Что чинит	тело + все индексы	один индекс	один индекс
Блокировка	`ACCESS EXCLUSIVE`	`ACCESS EXCLUSIVE`	`SHARE UPDATE EXCLUSIVE`
Пиковое доп. место	размер всей таблицы	размер одного индекса	размер одного индекса
Пишет в WAL	много	умеренно	больше, чем обычный
Гранулярность отката	нет, всё или ничего	по индексу	по индексу

Autovacuum не сломан, и это самое контринтуитивное

Место не возвращается не потому, что autovacuum не работает, а потому что он в принципе не делает того, что здесь нужно. Инстинкт подсказывает обратное, и я на него потратил время: полез проверять, не отключён ли автовакуум, нет ли зависшей транзакции, нет ли забытого репликационного слота, удерживающего horizon.

Всё оказалось в порядке. Автовакуум включён, слотов лишних нет, зависших транзакций нет. А счётчик запусков на горячих таблицах шёл на десятки тысяч. Он работал на износ — и не помогал.

Дальше стало понятно, почему. Тут работают три независимых механизма, и все три — штатное поведение, а не поломка.

Первый: VACUUM освобождает место внутри файла, а не отдаёт его операционной системе. Документация формулирует это с единственным исключением:

The standard form of VACUUM removes dead row versions in tables and indexes and marks the space available for future reuse. However, it will not return the space to the operating system, except in the special case where one or more pages at the end of a table become entirely free and an exclusive table lock can be easily obtained.

«pages at the end of a table» — ключевое. При хаотичной перезаписи пустые страницы разбросаны по всему файлу, а не собираются в хвосте. Условие не выполняется практически никогда.

Второй, и это корень: b-tree не сливает полупустые страницы. Раздел «Routine Reindexing» описывает ровно наш случай:

B-tree index pages that have become completely empty are reclaimed for re-use. However, there is still a possibility of inefficient use of space: if all but a few index keys on a page have been deleted, the page remains allocated. Therefore, a usage pattern in which most, but not all, keys in each range are eventually deleted will see poor use of space. For such usage patterns, periodic reindexing is recommended.

Обратите внимание на точность формулировки: полностью опустевшие страницы переиспользуются. А вот страница, с которой удалили все ключи кроме пары, остаётся занятой — и такой останется навсегда. PostgreSQL не объединяет соседние разреженные страницы и не перебалансирует дерево. Плотность падает и не восстанавливается. Никакая настройка автовакуума этого не меняет, потому что автовакуум тут вообще ни при чём.

Третий — акселератор: HOT-обновления не работают там, где нужнее всего. Если UPDATE не трогает индексируемых колонок и на странице есть место, PostgreSQL обновляет строку, не касаясь индексов. На горячей таблице пересчёта доля HOT округляется до 0.0%: на миллиард обновлений быстрым путём проходят единицы миллионов. Значит каждое обновление дописывало новую запись в каждый индекс таблицы — а их там не один и не два.

Механизм два объясняет, почему раздувание не рассасывается. Механизм три — почему оно накапливается так быстро.

Есть и четвёртый фактор, из-за которого часть таблиц не обслуживается вовсе. autovacuum_vacuum_scale_factor по умолчанию равен 0.2 — документация описывает его как «a fraction of the table size to add to autovacuum_vacuum_threshold», и уточняет: «The default is 0.2 (20% of table size)». Возьмём таблицу на десять миллионов строк: порог — два миллиона мёртвых строк. Накопилась четверть миллиона. До порога далеко, autovacuum_count остаётся нулём, и таблица не вакуумировалась ни разу за всё время жизни. Не потому что сломалось, а потому что так настроено по умолчанию.

Как измерить раздувание, а не гадать по размеру

Мерить надо плотность листовых страниц, и у неё есть точный публичный ориентир. avg_leaf_density из pgstatindex показывает, насколько плотно упакованы листья b-tree. Эталон — 90%, и это не эмпирическое наблюдение, а дефолт: документация CREATE INDEX говорит «B-trees use a default fillfactor of 90». Свежепостроенный индекс набивает листья ровно до этого значения.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13


CREATE EXTENSION IF NOT EXISTS pgstattuple;

SELECT i.indexrelname,
 pg_size_pretty(pg_relation_size(i.indexrelid)) AS sz,
 round(s.avg_leaf_density::numeric, 1) AS density
FROM (SELECT indexrelid, indexrelname
 FROM pg_stat_user_indexes
 ORDER BY pg_relation_size(indexrelid) DESC
 LIMIT 20) i
JOIN pg_class c ON c.oid = i.indexrelid
JOIN pg_am am ON am.oid = c.relam AND am.amname = 'btree',
LATERAL pgstatindex(i.indexrelid) s
ORDER BY s.avg_leaf_density ASC;

Зная эталон, выигрыш считается заранее: размер × плотность / 90. Индекс на гигабайт с плотностью 15% ужмётся примерно до 170 МБ. На стенде я сверил прогноз с фактом — разошлось на единицы процентов, чего для планирования более чем достаточно.

Два предостережения по замеру. Во-первых, pgstatindex полностью сканирует индекс, и на лидере под нагрузкой это заметно; лучше снимать на реплике — файлы там те же, а расширение приезжает репликацией. Во-вторых, фильтр по amname = 'btree' обязателен: для не-b-tree индексов функция даст либо ошибку, либо бессмысленный результат, да и документация честно признаёт, что раздувание в них исследовано плохо.

Уникальный индекс с нулём обращений — не мёртвый

Самая дорогая ошибка в этой истории — та, которую я почти совершил: удалить индексы с idx_scan = 0 как неиспользуемые. На горячей таблице таких набралось больше половины от всех её индексов, окно статистики — больше полугода. Соблазн очевидный.

Часть из них оказалась уникальными, подпирающими ограничения целостности. Причина расхождения — в определении счётчика. Документация описывает idx_scan как «Number of index scans initiated on this index»: он считает сканирования. А проверка уникальности при вставке — не сканирование, это отдельный путь внутри вставки в индекс. Счётчик она не трогает никогда.

Получается индекс, который по всем метрикам мёртв, а фактически единственный не пускает дубликаты в расчёты. Удали его — и данные начнут портиться молча, а заметят это через недели, когда сойдутся не те цифры.

Поэтому в запросе поиска неиспользуемых индексов фильтр по уникальности обязателен:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12


SELECT i.relname AS tbl, i.indexrelname AS idx,
 pg_size_pretty(pg_relation_size(i.indexrelid)) AS sz, i.idx_scan
FROM pg_stat_user_indexes i
JOIN pg_index x ON x.indexrelid = i.indexrelid
WHERE i.idx_scan = 0
 AND NOT x.indisunique -- без этой строки запрос опасен
 AND pg_relation_size(i.indexrelid) > 5 * 1024 * 1024
ORDER BY pg_relation_size(i.indexrelid) DESC;

-- ноль без окна наблюдения не значит ничего
SELECT stats_reset, now() - stats_reset AS window
FROM pg_stat_database WHERE datname = current_database();

Рядом живёт вторая ловушка того же класса: счётчики pg_stat_* ведутся на каждом узле отдельно. Реплика считает свои сканирования сама, и если часть чтения уходит на неё, лидер об этом не знает. Я проверил лидер и один standby, взятый из инвентаря, — и молча предположил, что standby единственный. Вывод оказался верным, но обоснован он не был. Список узлов надо брать из самой базы:

1

SELECT client_addr, state, sync_state FROM pg_stat_replication;

Сначала перечислить подписчиков запросом, потом обойти каждого — и только после этого говорить «индекс не используется».

Грабли при самой перестройке

Перестройка на живом кластере ломается не на SQL, а на обвязке вокруг него — на Patroni, на миграциях приложения и на синхронной реплике. Четыре места, где я споткнулся или мог споткнуться.

REINDEX CONCURRENTLY оставляет мусор при сбое, и суффикс говорит, что делать. Если перестройка упала, в базе остаётся невалидный индекс. Документация различает два случая: суффикс _ccnew — это недостроенный новый индекс, его надо удалить и повторить попытку; суффикс _ccold — это старый, который не смогли удалить, и тогда перестройка уже удалась, надо просто дропнуть остаток. Путать их дорого: во втором случае «повторю REINDEX» — лишняя работа на часы. К суффиксу может добавляться цифра (_ccnew1, _ccold2). Проверка невалидных индексов должна стоять первым шагом любой автоматизации:

1
2
3


SELECT c.relname
FROM pg_index i JOIN pg_class c ON c.oid = i.indexrelid
WHERE NOT i.indisvalid;

Patroni затрёт ALTER SYSTEM. Параметр применили, SHOW подтверждает, после переключения значение прежнее. Patroni сам управляет postgresql.conf и перезаписывает его из своей конфигурации в DCS. Менять надо через patronictl edit-config — подробнее об этом слое в разборе bootstrap.dcs.

Laravel оборачивает миграцию в транзакцию, и только на PostgreSQL. DROP INDEX CONCURRENTLY внутри транзакционного блока запрещён, и миграция падает. В коде миграции этого не видно, потому что решение принимается во фреймворке: в Migration.php объявлено public $withinTransaction = true, а мигратор проверяет пару условий сразу:

1
2
3
4


$this->getSchemaGrammar($connection)->supportsSchemaTransactions()
 && $migration->withinTransaction
 ? $connection->transaction($callback)
 : $callback();

Тонкость в первом условии. PostgresGrammar объявляет protected $transactions = true, а MySqlGrammar этого свойства не переопределяет. То есть одна и та же миграция на MySQL пройдёт, а на PostgreSQL упадёт — и разработчик, который тестировал локально не на той СУБД, узнает об этом на деплое. Лечится одной строкой в классе миграции:

1

public $withinTransaction = false;

Синхронная реплика превращает перестройку в задержки приложения. REINDEX выглядит локальной операцией на лидере, но порождает WAL объёмом примерно с сам индекс, а при synchronous_commit = on каждый коммит ждёт подтверждения от standby. Перестройка многогигабайтного индекса гонит этот объём по сети, и время отклика приложения растёт. Отсюда — по одному индексу, в непиковое окно, с проверкой лага между шагами и с оглядкой на wal_compression.

Отдельно про WAL: после серии перестроек каталог pg_wal разбухнет, и CHECKPOINT его не ужмёт. Я попробовал — не сработало, и не должно было. Если max_wal_size выставлен, скажем, в 4 ГБ, каталог упрётся ровно в этот потолок: это не протечка, а штатное поведение. PostgreSQL держит сегменты преаллоцированными и сжимает каталог постепенно, при спаде нагрузки. Гоняться за этими гигабайтами бессмысленно.

Два одинаковых индекса под разными именами

Если на таблице два уникальных индекса по одному набору колонок, а обращения идут только к одному — это, скорее всего, дубликат, но проверять надо не по списку колонок. Картина выглядит так: у одного индекса сканирования идут миллиардами, у другого ровно ноль.

Разный порядок колонок в UNIQUE сбивает с толку, хотя для уникальности он не значит ничего: UNIQUE (a, b) и UNIQUE (b, a) запрещают ровно одни и те же дубликаты. Но и совпадение колонок ещё не делает индексы одинаковыми. Сравнивать надо весь набор свойств:

1
2
3
4
5
6
7


SELECT i.relname, x.indisunique, x.indnullsnotdistinct,
 x.indnatts, x.indnkeyatts,
 x.indcollation::text, x.indclass::text, x.indoption::text,
 (x.indpred IS NOT NULL) AS partial,
 (x.indexprs IS NOT NULL) AS expr
FROM pg_index x JOIN pg_class i ON i.oid = x.indexrelid
WHERE x.indrelid = 'имя_таблицы'::regclass;

Что здесь важно и почему: indclass — классы операторов, indcollation — сортировки, indoption — направление и NULLS FIRST/LAST, indnkeyatts против indnatts покажет спрятанный INCLUDE, indpred и indexprs выдадут частичный индекс или индекс по выражению, а indnullsnotdistinct (появился в PostgreSQL 15) — трактовку NULL в уникальности. Если совпало всё, индексы действительно взаимозаменяемы — и удалять безопасно любой из двух, включая тот, на который приходятся все сканирования: планировщик прозрачно перейдёт на близнеца. Проверьте заодно attnotnull на колонках — при NOT NULL вопрос NULL-семантики снимается совсем.

И последняя отложенная грабля: удалённый индекс вернётся с ближайшим деплоем, если удаление сделано руками в базе, а объявление осталось в миграции или в схеме для тестов. Перед удалением — поиск имени по репозиторию, само удаление — только миграцией.

Что сделать, по шагам

Порядок такой, чтобы дорогие и необратимые шаги стояли после дешёвых и проверяемых.

Разделите тело и индексы запросом выше. Если раздут heap — это другая болезнь и другое лечение.
Поставьте pgstattuple и снимите avg_leaf_density по крупнейшим b-tree индексам. Замер делайте на реплике.
Посчитайте выигрыш: размер × плотность / 90. Так вы поймёте, стоит ли овчинка выделки, ещё до первой блокировки.
Проверьте окно статистики через stats_reset. Без него нули в idx_scan не значат ничего.
Найдите неиспользуемые индексы с фильтром AND NOT indisunique. Уникальные оценивайте только по бизнес-смыслу, не по счётчику.
Обойдите все узлы кластера, перечислив их через pg_stat_replication, а не по инвентарю.
Перестраивайте по одному: REINDEX INDEX CONCURRENTLY на проде, обычный REINDEX на стендах. Между шагами смотрите лаг реплики.
Заведите мониторинг плотности, а не только свободного места. К моменту дискового алерта индексы деградируют уже месяцами.

Пункт 8 стоит последним, а по важности он первый: место — это симптом, который заметил мониторинг, а не болезнь.

Итог

Раздувание индексов — не поломка и не недосмотр администратора, а осознанный компромисс PostgreSQL. Слияние полупустых страниц b-tree стоило бы блокировок и перебалансировок на горячем пути, и его сознательно не делают. Отсюда единственный корректный вывод: перестройку индексов надо планировать, как планируют бэкапы, а не ждать, что автоматика справится сама.

Практический вывод, который переживёт конкретную версию: когда база «распухла», первое действие — не выбрать инструмент, а разделить диагнозы. Тело и индексы лечатся разным, и VACUUM FULL, назначенный по общему размеру таблицы, в лучшем случае сделает лишнюю работу, а в худшем добьёт диск, которого и так не хватает.

И про метрики. idx_scan = 0 на уникальном индексе — хороший пример того, как метрика не знает о смысле. Она честно отвечает на свой вопрос («сколько было сканирований»), а мы читаем в ней ответ на другой («нужен ли этот индекс»). Прежде чем удалять что-то по счётчику, стоит выяснить, что именно счётчик считает — и, главное, чего он не считает.

Первоисточники: Routine Reindexing, Routine Vacuuming, REINDEX, VACUUM, параметры autovacuum, CREATE INDEX и fillfactor, pgstattuple, Monitoring Statistics, Migration.php в laravel/framework, PostgresGrammar.php.

Сервер не отвечает, но работает: беззнаковое вычитание в ZFS и systemd CrashAction=freeze

BitPage — Wed, 02 Sep 2026 16:00:00 +0300

Короткий ответ: если сервер перестал отвечать по всем портам, а после ресета в журнале обнаружилась лавина segfault’ов в несвязанных друг с другом процессах и строка systemd[1]: Freezing execution — виновата не память, а арифметика в ядре. В OpenZFS до 2.4.4 и 2.3.9 функция zfs_fillpage() считала длину чтения как io_len = i_size - io_off в беззнаковых типах: если файл усечь ровно в тот момент, когда подкачивается mmap-страница, разность уходит в минус, превращается в «почти 2⁶⁴», и dmu_read() забивает нулями физическую память далеко за пределами страницы. Машина при этом остаётся жива — до конца её добивает systemd, у которого CrashAction по умолчанию равен freeze.

Отказ выглядел как выключенный сервер: ни SSH, ни HTTP, ни веб-морда гипервизора. Помог жёсткий ресет через панель хостера. Дальше остался вопрос, который никто не любит: а что это, собственно, было, и повторится ли оно завтра.

Час расследования дал два ответа вместо одного. Баг в ZFS — это спусковой крючок. Настоящую цену отказу назначил дефолт systemd.

Коротко (TL;DR)

Причина: беззнаковое вычитание в zfs_fillpage() при гонке mmap-чтения с усечением файла на месте. Ядро затирает нулями чужие страницы физической памяти, жертвами становятся случайные процессы.
Где починено: OpenZFS 2.4.4 и 2.3.9, оба от 21 августа 2026. В Proxmox — пакет zfsutils-linux версии 2.4.4-pve1. В 2.2.11, вышедшей в тот же день, фикса нет.
Почему отказ длится часами, а не секундами: CrashAction=freeze — дефолт systemd. Упавший PID 1 замирает навсегда, службы никто не перезапускает, systemctl виснет, sshd со временем умирает следом.
Как за минуту отличить от битой памяти: счётчики ECC в /sys/devices/system/edac/mc/mc0/ нулевые и в журнале нет ни одного Machine Check — значит планки ни при чём.
Признак в дампе: регистр длины memset — не мусор, а аккуратное отрицательное число, ровно минус другой регистр. Это переполнение при вычислении размера, а не сбойное железо.
Смягчение на одну строку: CrashAction=reboot в drop-in — и повторение аварии стоит десяти секунд вместо целой ночи.
Побочные грабли: restart: on-failure у Docker переживает жёсткий ресет, но по документации не переживает перезапуск демона.

Как выглядит отказ снаружи

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

Гипотеза разваливается о журнал. journalctl --list-boots показывает предыдущую загрузку, и записи в ней идут вплоть до момента, отстоящего от новой загрузки на полторы-две минуты — ровно на длительность POST серверной платы. Последняя строка перед ресетом была такой:

nginx[…]: [alert] …#…: worker process … exited on signal 11

Машина не выключалась. Она работала всё это время и исправно писала в журнал, что ей плохо. Просто снаружи её не было слышно.

Отсюда же вылезает вторая неприятность: настоящий момент сбоя лежит сильно раньше, чем «время падения» из last. last -x покажет crash, но не покажет, когда именно всё началось. Начало ищется по первому segfault’у в лавине — и оно может отстоять от ресета на всю ночь.

Почему это не битая память, хотя выглядит именно так

Массовые одновременные segfault’ы в несвязанных процессах — классический почерк неисправной RAM, и первый рефлекс здесь неправильный. Планировать даунтайм под memtest86+ не надо, сначала стоит потратить минуту на два счётчика:

1
2
3


cat /sys/devices/system/edac/mc/mc0/ce_count # исправленные ошибки
cat /sys/devices/system/edac/mc/mc0/ue_count # неисправленные
journalctl -b -1 -k | grep -i "machine check"

Нули во всех трёх местах при ECC-памяти означают, что память как подсистема исправна. Одиночный перевёрнутый бит контроллер поймал бы и записал. А заодно проверьте, что ECC действительно работает, а не просто планки такие:

1

dmidecode -t memory | grep -E "Error Correction Type|Total Width|Data Width"

Total Width на 8 бит больше Data Width — вот это и есть работающий ECC, дополнительные биты под коррекцию физически присутствуют. Если ширины равны, ECC у вас нет, кто бы что ни писал в спецификации.

Эта минута экономит несколько часов даунтайма на диагностике не той подсистемы. ECC защищает от перевёрнутых битов, а не от кода, который сам, штатным путём исполнения, пишет нули не туда.

Четыре ложных следа, и все четыре через одну функцию

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

След 1: гонка Direct IO. Первый же осмысленный поиск по стеку вывел на обсуждение реальной гонки в OpenZFS: конкурентная запись с O_DIRECT может выставить db->db_data = NULL, и тогда dmu_read_impl() падает на разыменовании. Имена функций совпадали с нашим стеком буквально. Проверка тюнабла подлила масла в огонь — Direct IO включён:

# cat /sys/module/zfs/parameters/zfs_dio_enabled
1

Я успел назвать это главной гипотезой вслух. Развалилось об регистры: у нас не разыменование нуля, а memset с осмысленным адресом назначения и абсурдной длиной. Механизм принципиально другой.

След 2: повреждение SLUB на шифрованном ZFS. Нашёлся свежий issue #18427 с симптомом слово в слово нашим — массовые segfault’ы в userspace, воспроизводится на версиях с 2.2.3 по 2.4.1. Отверг одной командой:

# zfs get -r encryption rpool
NAME PROPERTY VALUE SOURCE
rpool encryption off default

След 3: уже исправленная регрессия в dmu_read_impl. Issue #17886 — Oops в той же функции и тоже с затиранием памяти по кривой длине, закрыт через PR #17915. Выглядело как «баг известен, фикс есть, обновляйтесь». Прочитал сам PR — он чинит потерянные скобки в макросе BRT_RANGESIZE_TO_NBLOCKS(), деление вместо умножения. Автор пишет прямо: «this could cause small memory corruptions for vdevs bigger than 64TB+». Порог отсекает сразу: до 64 ТБ на vdev типовой пул под веб-нагрузку не дотягивает на порядок. Да и стек в том баге идёт через brt_load() при импорте пула, а не через mmap под нагрузкой. Общее место падения, разные баги.

След 4: «сервер был выключен несколько часов». Про него выше — разбился о непрерывный журнал предыдущей загрузки.

Общий вывод неприятный: четыре следа из четырёх шли через dmu_read_impl. Функция популярная, «повреждение памяти» — слишком общий симптом, и поиск по симптому в такой ситуации выдаёт бесконечную ленту чужих несчастий. Развязку дал не поиск, а арифметика.

Развязка: длина `memset` — это ровно минус другой регистр

Разгадка целиком лежала в дампе Oops, надо было просто посчитать. Вот он, сокращённо до значимого:

BUG: unable to handle page fault for address: ffff8983e8400000
#PF: supervisor write access in kernel mode
#PF: error_code(0x0003) - permissions violation
Comm: php-fpm
RIP: 0010:memset+0xb/0x20
RAX: 0000000000020000 RSI: 0000000000000000 RDI: ffff8983e8400000
RDX: ffffffffff7a4000 R15: 000000000085c000
Call Trace:
? dmu_read_impl+0x21e/0x230 [zfs]
dmu_read [zfs]
zfs_fillpage [zfs]
zfs_getpage [zfs]
zpl_read_folio [zfs]
filemap_read_folio
filemap_fault
__do_fault
handle_mm_fault

Смотрим на аргументы memset. В x86-64 SysV это RDI — адрес, RSI — чем заполнять, RDX — сколько байт.

RSI = 0, заполняем нулями. RDX = 0xffffffffff7a4000 — на первый взгляд мусор. А теперь R15 = 0x85c000 = 8 765 440. И вот здесь надо остановиться: 0xffffffffff7a4000 — это ровно −8 765 440 в дополнительном коде. Не случайное значение, не затёртый регистр. Аккуратное отрицательное число.

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

Заодно RAX = 0x20000 — это 128 КиБ, дефолтный recordsize ZFS. Всё сходится: обычное чтение записи ZFS, у которого поехала длина.

С этой гипотезой поиск перестал быть поиском по симптому и стал поиском по имени функции вместе с точной версией. Нужный issue нашёлся первым же результатом.

Что сломано в ZFS: инвариант, который не доживает до релизной сборки

Виновата пара строк в zfs_fillpage(), а прикрывал их ASSERT, которого в релизных сборках нет вовсе. Вот код из ветки 2.4.3:

1
2
3
4
5
6
7
8


loff_t i_size = i_size_read(ip);
u_offset_t io_off = page_offset(pp);
size_t io_len = PAGE_SIZE;

ASSERT3U(io_off, <, i_size);

if (io_off + io_len > i_size)
 io_len = i_size - io_off;

Инвариант записан прямым текстом: смещение страницы обязано быть меньше размера файла. Ниже строчкой на этом инварианте построено вычитание. Всё честно — ровно до того момента, пока не заглянешь в определение ASSERT3U для сборки без отладки, в include/os/linux/spl/sys/debug.h:

1
2
3
4
5
6
7


/*
 * Debugging disabled (--disable-debug)
 */
#ifdef NDEBUG

#define ASSERT3U(x, y, z) \
 ((void) sizeof ((uintptr_t)(x)), (void) sizeof ((uintptr_t)(z)))

Макрос разворачивается в два sizeof. Он ничего не вычисляет и ничего не проверяет — он существует, чтобы аргументы не считались неиспользуемыми. А дистрибутивы, включая Proxmox, собирают ZFS именно без отладки. То есть единственная защита от переполнения выключена ровно в тех сборках, которые крутятся на проде.

Дальше механика простая. Файл усекают на месте (O_TRUNC при перезаписи), i_size падает. Страница, которая уже стоит в очереди на подкачку, оказывается за новым концом файла: io_off > i_size. Условие io_off + io_len > i_size истинно, io_len = i_size - io_off — и size_t уезжает в «почти 2⁶⁴». dmu_read() получает эту длину, видит за концом файла дыру и добросовестно заполняет нулями всё, до чего дотянется.

Причину назвал участник обсуждения в issue #18787, пользователь @Zaczero, — и сформулировал её так:

in zfs_fillpage(), if a page is faulted in just after the file is truncated, io_len = i_size - io_off underflows (unsigned) to ~2⁶⁴, and dmu_read() then writes zeros forward across physical memory from that one page.

Там же назван и типичный триггер: «an mmap read (PHP readfile()) racing an in-place truncate of the same file». В нашем дампе Comm: php-fpm — попадание точное.

Второе наблюдение из того же комментария объясняет, почему симптом так сбивает с толку:

Kernel slab + two unrelated userspace heaps (redis, php-fpm) + journald’s mmap’d file all corrupted in the same second → a physical-page sweep, not a single-list bug. Explains why ZFS isn’t in the faulting stack (it’s a sweep on another CPU; the crashing threads are just victims).

Затирание идёт по физическим страницам, поэтому ZFS в стеке падающего процесса чаще всего вообще не появляется. Падают жертвы, а не виновник. Именно из-за этого поиск по симптому уводит куда угодно, только не к файловой системе.

Отдельная деталь для тех, кто держит контейнеры: в дампе стоял UID 100082. Расшифровывается механически — непривилегированный LXC по умолчанию маппит хостовые UID со смещением 100000, значит внутри контейнера это uid 82, а 82 в Alpine — это www-data. Рядом в трейсах мелькал ld-musl-x86_64.so.1, тоже Alpine. Так по одному числу локализуется, чей именно PHP дёргал файл: не хостовый, а тот, что в контейнере.

В каких версиях баг живёт и куда обновляться

Уязвимы все версии до 2.4.4 и 2.3.9, а вдобавок вся ветка 2.2 целиком, включая свежайшую 2.2.11. Фикс — PR #18715 «linux: handle mmap read beyond file size», коммит 223b8bc446, влит в master 30 июня 2026. Он добавляет ранний выход, когда страница целиком лежит за концом файла:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12


/*
 * The page may be faulted in after the file has been truncated.
 * There is no data to read; just zero-fill the page.
 */
if (io_off >= i_size) {
 void *zva = kmap(pp);
 memset(zva, 0, PAGE_SIZE);
 kunmap(pp);
 ClearPageError(pp);
 SetPageUptodate(pp);
 return (0);
}

Симметричная правка сделана в zfs_getpage(), чтобы range lock брался на корректный диапазон. Следом влит регрессионный тест — PR #18824, 20 июля 2026.

Релиз 2.4.3 вышел 12 июня 2026, то есть фикс опоздал к нему на 18 дней. Вот как обстоят дела с релизами сейчас:

Ветка	Последний релиз	Дата	Фикс `zfs_fillpage()`
2.4	2.4.4	21.08.2026	есть
2.3	2.3.9	21.08.2026	есть
2.2	2.2.11	21.08.2026	нет, уязвимый код на месте
Proxmox	`zfsutils-linux` 2.4.4-pve1	в `pve-no-subscription`	есть

Таблицу я собрал не по анонсам, а сравнением zfs_fillpage() в тегах репозитория: в zfs-2.2.11 строки ASSERT3U(io_off, <, i_size); и io_len = i_size - io_off; стоят ровно там же, где в 2.4.3. Ветка 2.2 на сегодня уязвима, хотя релиз у неё того же числа, что у исправленных. В списке изменений 2.4.4 и 2.3.9 фикс упомянут явной строкой linux: handle mmap read beyond file size #18715, в описании 2.2.11 такой строки нет.

Проверить, что стоит у вас, можно одной командой — она же покажет, дошёл ли пакет до вашего репозитория:

1

modinfo zfs | grep -E '^(version|srcversion)'

Ещё одна деталь, отрезвляющая насчёт «просто откатимся на прошлое ядро»: уязвимый код одинаков и в 2.4.2, и в 2.3.x, и в 2.1.15. Это не свежая регрессия, а давняя мина. Откат на запасное ядро с ZFS постарше не лечит ничего.

Отдельно любопытна хронология. Фикс появился раньше issue и совсем не по нему: коммит влит 30 июня, автор патча — Brian Behlendorf, руководитель проекта OpenZFS, а в теле коммита стоит Reported-by: Iliya Polihronov (@vnsavage) (Automattic). То есть на баг независимо наткнулись в компании, которая держит WordPress.com. Issue же заведён 12 июля, и связали одно с другим только 16-го — через две с половиной недели после того, как патч уже лежал в master.

Автор issue — @stgraber, мейнтейнер Incus. У него это ловилось на хостах с сотней LAMP-контейнеров, причём тоже на ECC-памяти:

All systems use ECC memory and I’ve confirmed that the system where I’ve captured the crash data here also has a completely clean SEL so physical memory should be fine.

11 августа он подтвердил, что после выкатки cherry-pick’а коммита падения прекратились: «haven’t heard about any more crashes since this got rolled out, so seems like that did the trick». Сам issue при этом до сих пор открыт — ориентироваться надо на номер PR, а не на статус тикета.

Почему отказ длится часами, а не секундами

Отказ длится часами, потому что systemd по умолчанию замораживает упавший PID 1 навсегда вместо перезагрузки. Это вторая половина разгадки, и она дороже первой. Через считаные миллисекунды после начала затирания памяти в журнале появляется:

systemd[1]: Caught <ABRT>, from our own process.
systemd[1]: Caught <ABRT>, dumped core as pid …
systemd[1]: Freezing execution.

У systemd есть параметр CrashAction, и по умолчанию он равен freeze. Документация systemd(1) описывает это без всякой двусмысленности:

Takes one of freeze, reboot or poweroff. Defaults to freeze. If set to freeze, the system will hang indefinitely when the system manager (PID 1) crashes. If set to reboot, the system manager (PID 1) will reboot the machine automatically when it crashes, after a 10s delay.

«Hang indefinitely» — это ровно то, что мы видели. Логика дефолта понятна: замереть, чтобы администратор подошёл и изучил живую систему. На арендованном железе в чужом дата-центре она означает «зависни навсегда и жди, пока кто-нибудь заметит».

Замороженный PID 1 отнимает у системы способность себя чинить. Упавшие службы никто не перезапустит, systemctl виснет, штатное выключение невозможно. Дальше картина становится издевательской: мастер-процесс nginx жив, послушно форкает воркеров, воркеры наследуют испорченную память и умирают мгновенно. При частоте порядка двух падений в секунду за ночь набегают сотни тысяч строк в журнале. Обычный systemctl restart nginx вылечил бы это за секунду — но выполнять его было некому.

Через полчаса умирает и sshd:

sshd[…]: free(): invalid pointer
sshd[…]: recv_rexec_state: ssh_msg_recv failed

После этой строки в журнале нет ни одного упоминания sshd — ни попыток входа, ни отказов. Порт 22 просто никто не слушал. Отсюда и полное молчание снаружи при живом ядре внутри.

Смягчение — одна строка, и ставить её лучше drop-in’ом, а не правкой основного файла:

1
2
3


# /etc/systemd/system.conf.d/10-crash-reboot.conf
[Manager]
CrashAction=reboot

1
2


systemd-analyze cat-config systemd/system.conf # посмотреть, что получится, ДО применения
systemctl daemon-reexec # применить к живому PID 1

Теперь повторение аварии стоит десяти секунд до автоперезагрузки. Прикиньте разницу сами: если PID 1 замрёт вечером, а первый человек посмотрит на сервер утром — это часы простоя вместо десяти секунд, и вся разница в одной строке конфига.

Параметр CrashAction= появился в systemd 256, вместе с ним завели и systemd.crash_action= в командной строке ядра. В Debian 13 и Proxmox 9 приезжает systemd 257, так что опция там точно есть.

Побочная находка: restart-политика, которая переживает аварию, но не переживает ребут

Политика restart: on-failure поднимает контейнеры после жёсткого ресета, но не поднимает их после штатной перезагрузки — и это даёт ложную уверенность в отказоустойчивости. У контейнеров стояло именно on-failure. После жёсткого ресета они поднялись как миленькие: процессы убиты SIGKILL, код выхода ненулевой, политика сработала.

А теперь документация Docker про эту же политику:

The on-failure policy only prompts a restart if the container exits with a failure. It doesn’t restart the container if the daemon restarts.

При штатной перезагрузке dockerd шлёт контейнерам SIGTERM, и тот, кто завершается с кодом 0 — nginx именно так и делает, — под on-failure не поднимется. Получается парадокс: конфигурация переживает аварию, но может не пережить плановый ребут. А люди тестируют отказоустойчивость как раз выдёргиванием питания и делают из этого неверный вывод.

Лечится без простоя и без пересоздания контейнеров:

1

docker update --restart unless-stopped <container>

Рядом нашлась и вторая мина: у контейнера с мониторингом директивы restart: не было вообще, а это значит no — не поднимать никогда. После каждой перезагрузки он не стартовал, а зависящий от него прокси уходил в цикл перезапусков с host not found in upstream — десятки рестартов за четверть часа. depends_on тут не спасает: он задаёт порядок только внутри docker compose up, а при автозапуске контейнеров демоном никакого порядка нет, есть только restart-политика у каждого контейнера по отдельности.

Что сделать сейчас, по шагам

Минимум — обновить ZFS и переключить CrashAction; первое убирает причину, второе ограничивает цену следующего краха PID 1 десятью секундами.

Проверьте версию ZFS: modinfo zfs | grep ^version. Всё, что ниже 2.4.4 или 2.3.9, а также вся ветка 2.2 включая 2.2.11 — уязвимо.
Обновитесь. На Proxmox — apt update && apt install zfsutils-linux zfs-initramfs до 2.4.4-pve1, дальше перезагрузка: модуль ядра на живой системе не подменить.
Если обновиться нельзя, снизьте вероятность триггера. Он — перезапись файла на месте под mmap-чтением. Вынесите кэш-каталоги, куда приложение пишет через O_TRUNC, на tmpfs: где нет ZFS, там нет и бага. В приложении правильный путь — писать во временный файл и rename(), но на легаси-кодовой базе полного покрытия не будет.
Поставьте CrashAction=reboot drop-in’ом. Это независимо от ZFS и полезно при любом крахе PID 1.
Пройдитесь по restart-политикам контейнеров: docker inspect -f '{{.Name}} {{.HostConfig.RestartPolicy.Name}}' $(docker ps -aq). Всё, что no или on-failure, переведите на unless-stopped.
Заведите внешнюю проверку доступности. Хоть что-нибудь снаружи, что дёргает порт раз в минуту и пишет вам, когда он молчит.

Пункт 6 я поставил последним, а по важности он первый.

Итог

В этой аварии три слоя вины, и починить самому можно два из них. Баг в ZFS — спусковой крючок, он от вас не зависел и уже исправлен апстримом: обновляйтесь до 2.4.4 или 2.3.9 и живите дальше. Дефолт CrashAction=freeze превратил единичный сбой в многочасовой отказ — это чинится одной строкой и стоит того, чтобы прописать её на всех арендованных машинах заранее, до первого случая. А отсутствие внешнего мониторинга растянуло отказ до утра, и это, честно говоря, дыра крупнее самого бага в файловой системе.

Практический вывод, который переживёт конкретно этот баг: когда ядро падает на memset или memcpy — посмотрите на регистр длины и проверьте, не аккуратное ли это отрицательное число. Если да, искать надо не того, кто испортил память, а того, кто неправильно посчитал размер. Это сразу отсекает всю ветку с диагностикой железа, а она самая дорогая по времени.

И отдельно — про ASSERT в чужом коде. Инвариант, записанный ассертом, в релизной сборке не существует. Он документирует намерение автора, а не гарантирует поведение системы. Читая исходники в поисках причины падения, каждый ASSERT стоит мысленно читать как комментарий — и проверять, что будет, если он неверен.

Первоисточники: issue openzfs/zfs#18787, PR #18715 и коммит 223b8bc446, регрессионный тест #18824, релиз zfs-2.4.4, zfs_vnops_os.c в теге zfs-2.4.3, определение ASSERT3U в debug.h, man systemd(1) про systemd.crash_action=, документация Docker про restart-политики.

PHP теряет сессию после апгрейда: звёздочка в имени cookie превращается в %2A

BitPage — Wed, 02 Sep 2026 10:00:00 +0300

Короткий ответ: если в session.name есть символ вне [0-9A-Za-z-._], PHP отправляет его в Set-Cookie в URL-кодированном виде (* → %2A), а обратно принимает имя как есть, без декодирования. Имена перестают совпадать, сервер не находит session-id, стартует пустую сессию — пользователь навсегда гость. Ломается это ровно в окне версий 7.2.34, 7.3.23–7.3.33, 7.4.11–7.4.16 и 8.0.1–8.0.3: в этих релизах декодирование имён уже убрали (фикс CVE-2020-7070), а кодирование ещё не убрали. Лечится одной строкой — убрать спецсимвол из имени cookie.

Легаси-портал на Yii2 переехал со старого хоста в Docker. Вход у него только через внешний SSO, своей формы логина нет. После переезда вход перестал доходить до конца: пользователь логинится на SSO, возвращается — и снова видит форму входа. Код приложения при этом не трогали ни строкой.

Часа два ушло на детектив, из них полтора — на версии, которые оказались мимо. Разгадка была в одной строке заголовка с самого начала.

Коротко (TL;DR)

Причина: php_url_encode() применяется к session.name при отправке, но имена входящих cookie с некоторого патча больше не декодируются. Round-trip имени разорван.
Симптом: сессия на диске корректная, идентити внутри есть, storage читается — а пользователь всё равно гость. Классический рефлекс «чини хранилище» здесь бесполезен.
Проверка за минуту: взять один валидный session-id и дёрнуть закрытую страницу дважды — с именем cookie как в конфиге и как в Set-Cookie. 200 против 302 — диагноз.
Фикс: убрать из session.name всё, кроме [0-9A-Za-z-._]. Одна строка в конфиге, рантайм остаётся свежим.
Грабли: php:7.3-fpm-alpine — это «последний 7.3», а не «тот же 7.3». Пин мажор.минор не защищает от смены поведения.
Грабли: диагностируя руками, не подставляйте PHPSESSID по привычке — при кастомном session.name вы получите 302 и ложный вывод.

Как это выглядит снаружи

Снаружи это выглядит как сломанный SSO, хотя SSO ни при чём. Флоу входа обычный для самодельного single sign-on:

Гость идёт на закрытую страницу — редирект на внешний SSO.
Логинится там.
SSO возвращает его обратно с ?session_key=….
Приложение проверяет ключ через API SSO, находит пользователя, вызывает login(), редиректит на профиль.
Профиль под сессией отдаёт 200.

После переезда шаг 5 не наступает никогда: профиль всегда отвечает 302 обратно на вход. Круг замыкается. За пару суток после переезда в логе не нашлось ни одного успешного входа — только редиректы.

Причём часть сигналов выглядела обнадёживающе, и это сбивало. Поле updated_at у пользователей обновлялось — приложение пишет данные до финального login(), так что «свежий вход» в базе означал только «нас коснулись». API SSO на запросы приложения отвечало 200: проверка ключа проходила. Оба сигнала намекали «всё почти работает» — и оба уводили от места поломки.

Пять версий, которые оказались мимо

Все пять первых гипотез указывали наружу или в инфраструктуру, и ни одна не подтвердилась. Выписываю их не для красоты: каждая закрывает целое направление поиска, и если у вас похожий симптом — эти ветки можно не проходить заново.

Версия 1: сломался внешний SSO. В браузере кнопка «Войти» на форме SSO вела себя странно, будто не отправляла запрос. Логично обвинить чужой сервис. Отверг: на сервере SSO ничего не менялось, процессы подняты давно и не перезапускались, а его API на запросы приложения отвечало 200. Значит разрыв — после возврата, уже на нашей стороне.

Версия 2: кончился диск. Лог приложения SSO застыл на позавчерашней записи — классический признак заполненного раздела. Отверг: места и инодов свободно с запасом. Застывший лог оказался отдельной болячкой ротации и к входу отношения не имел.

Версия 3: чужая ручка отдаёт 500. В цепочке входа приложение дёргает у SSO ещё один эндпоинт, и тот стабильно отвечал 500. Выглядело как то, что рушит флоу до login(). Отверг сравнением логов до и после переезда: эта ручка отдавала 500 и раньше, когда вход работал. Давний безобидный дефект, не регрессия.

Версия 4: login() не отрабатывает. Раз профиль считает гостем — может, идентити не находится: в Yii findIdentity() фильтрует по статусу, и неактивный пользователь вернёт null. Отверг: на диске нашлись session-файлы с идентити внутри — условно __id|i:1234. Значит login() отрабатывает и сессию пишет, а пользователи из этих сессий в базе активны.

Версия 5: сломано хранилище сессий. Сессия пишется, но на следующем запросе не читается — похоже на разъехавшийся session.save_path или эфемерный volume. Отверг временным скриптом: session_id($known); session_start(); спокойно прочитал сессию с идентити. Хранилище работает.

Вот на пятой версии я и налажал сам. Проверяя «читается ли сессия по cookie», я слал запрос с заголовком Cookie: PHPSESSID=<sid>, получал 302 и чуть было не записал это в улики как «сессия не подхватывается». А приложение использует кастомное имя session-cookie — мой PHPSESSID сервер просто игнорировал. Тест был бессмысленным с самого начала.

Урок дешёвый, но я его оплатил: воспроизводя сессию руками, сперва посмотри реальный session.name, а не подставляй PHPSESSID по привычке.

Что на самом деле: две половинки, которые перестали сходиться

Развязку дал не поиск по симптому, а буквальное сравнение того, что сервер пишет в Set-Cookie, с тем, что он потом ждёт во входящем Cookie. Когда storage отпал, непроверенным осталось ровно одно звено — само имя.

Имя session-cookie в конфиге приложения содержало звёздочки — условно myapp-front***end-s. Смотрим, что реально уходит клиенту:

set-cookie: myapp-front%2A%2A%2Aend-s=aa5db984...; path=/; HttpOnly

%2A%2A%2A — это URL-кодированные ***. Сервер сам, своей рукой, записал имя в закодированном виде. А при чтении входящего заголовка он ищет сессию по исходному имени, со звёздочками. Имена не совпадают → session-id не найден → стартует новая пустая сессия → пользователь гость → редирект → круг.

Легко прочитать %2A%2A%2A в заголовке как «это браузер так прислал». Нет: это сервер так отдал. Смотреть надо обе стороны round-trip.

Решающая проверка — один и тот же валидный session-id, два написания имени:

1
2
3
4
5
6
7


# имя с буквальными звёздочками — как оно записано в session.name
curl -s -o /dev/null -w '%{http_code}\n' https://portal.example/profile \
 -H 'Cookie: myapp-front***end-s=<sid>' # → 200, залогинен

# имя в том виде, в каком сервер сам его прислал
curl -s -o /dev/null -w '%{http_code}\n' https://portal.example/profile \
 -H 'Cookie: myapp-front%2A%2A%2Aend-s=<sid>' # → 302, гость

200 против 302 на одной и той же сессии, при одном и том же session-id. Содержимое сессии ни при чём — ломается именно совпадение имён.

Почему это сломал именно security-фикс

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

Половинка первая — отправка. Расширение session прогоняет session.name через php_url_encode(). В ext/session/session.c ветки PHP-7.3 это сделано с говорящим комментарием:

1
2
3


/* URL encode session_name and id because they might be user supplied */
e_session_name = php_url_encode(PS(session_name), strlen(PS(session_name)));
e_id = php_url_encode(ZSTR_VAL(PS(id)), ZSTR_LEN(PS(id)));

А php_url_encode() из ext/standard/url.c — это обычный urlencode, не знающий ничего про cookie. Он оставляет как есть только цифры, латинские буквы, -, . и _; пробел превращает в +, всё прочее — в %XX. Звёздочка (0x2A) под исключения не попадает и уезжает как %2A.

Половинка вторая — чтение. Раньше PHP декодировал имена входящих cookie, и это ровно компенсировало кодирование: %2A%2A%2A на входе превращалось обратно в ***, имя совпадало с session.name, всё работало. Два перекоса гасили друг друга.

Именно это декодирование и оказалось дырой. В security-баге #79699 репортёр описал проблему так: «The PHP cookie parser parses the HTTP_COOKIE string percent decoding the entire string» — и дальше показал, что cookie с именем __%48ost- превращается сервером в __Host-, обходя браузерную защиту префиксов. Его рекомендация была прямой: «I would not percent decode the names of cookies».

Так и сделали. В официальном changelog PHP 7 для версии 7.3.23 от 1 октября 2020 года запись дословно такая:

Fixed bug #79699 (PHP parses encoded cookie names so malicious __Host- cookies can be sent). (CVE-2020-7070)

В коде это выглядит как одно условие в main/php_variables.c — имя декодируется для чего угодно, кроме cookie:

1
2
3
4


if (arg != PARSE_COOKIE) {
 php_url_decode(var, strlen(var)); /* имя: больше НЕ для cookie */
}
val_len = php_url_decode(val, strlen(val)); /* значение: всегда */

Компенсация исчезла, кодирование осталось. Round-trip разорвался.

Приложение при этом ничего не нарушало: по RFC 6265 имя cookie — это token, а звёздочка входит в разрешённые символы token и сепаратором не является. Имя было легальным. Просто PHP кодировал его generic-функцией, которая про RFC 6265 не знает.

В каких версиях PHP баг живёт

Баг живёт в узком окне: между релизом, где убрали декодирование, и релизом, где убрали кодирование. Обе даты я определил по тегам php-src, сравнивая ext/session/session.c и main/php_variables.c.

Кодирование имени из session_send_cookie убрали позже — в 7.4.18 и 8.0.5 (обе от 29 апреля 2021). Вместо него появилась валидация: имя не должно содержать =,; \t\r\n\013\014, иначе E_WARNING с текстом «session.name cannot contain any of the following». Звёздочка в этот запрет не входит, так что с 7.4.18 она в имени работает нормально — её и не кодируют, и не декодируют.

Ветка	Декодирование убрано (CVE-2020-7070)	Кодирование имени убрано	Окно, где вход ломается
7.2	7.2.34 (01.10.2020)	не успели, ветка закрыта	7.2.34
7.3	7.3.23 (01.10.2020)	не успели, ветка закрыта	7.3.23 — 7.3.33
7.4	7.4.11 (01.10.2020)	7.4.18 (29.04.2021)	7.4.11 — 7.4.16
8.0	8.0.1 (07.01.2021)	8.0.5 (29.04.2021)	8.0.1 — 8.0.3
8.1 и новее	—	уже без кодирования	не затронуты

Две оговорки по таблице, обе проверяемые. Версий 7.4.17 и 8.0.4 не существует вовсе — их нет ни среди тегов php-src, ни в changelog: после 7.4.16 и 8.0.3 от 4 марта 2021 сразу идут 7.4.18 и 8.0.5 от 29 апреля. И отдельной changelog-записи про снятие кодирования с session.name я не нашёл — изменение видно по коду, но в списке исправлений оно не поименовано.

Практический вывод из таблицы: хуже всего веткам 7.2 и 7.3. Они закрылись, не дождавшись второй половины изменения, поэтому любой последний патч 7.2 или 7.3 ломает спецсимвол в имени session-cookie навсегда. Наш случай ровно такой: старый хост работал на 7.3.16, официальный образ php:7.3-fpm-alpine принёс 7.3.33 — то есть перепрыгнул фикс 7.3.23, стоящий ровно посередине.

Отсюда же понятно, почему готового ответа на этот симптом почти не найти. Окно узкое, а совпасть должны три вещи разом: спецсимвол в session.name, версия из окна и апгрейд через границу 7.3.23.

Как проверить это у себя за минуту

Проверка не требует ни стенда, ни доступа к коду — хватит curl и одного валидного session-id.

Посмотрите, что сервер пишет в имя cookie: curl -s -D - -o /dev/null https://portal.example/ | grep -i set-cookie
Найдите в выводе % внутри имени (до знака =). %2A — звёздочка, %21 — восклицательный знак, %24 — доллар. Если проценты только в значении — вы не здесь, ищите дальше.
Сравните имя из Set-Cookie с тем, что лежит в session.name (php -i | grep session.name или конфиг фреймворка). Расходятся — диагноз подтверждён.
Добейте round-trip’ом: одну и ту же закрытую страницу с одним и тем же sid, но двумя написаниями имени. Разные коды ответа — это оно.
Проверьте версию: php -v. Попадает в окно из таблицы выше — сомнений не осталось.

Шаг 2 — самый дешёвый и отсекает почти всё. Минута против пары часов гадания про save_path, volume и права на каталог.

Чем чинить: четыре варианта

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

Вариант	Что делает	Почему не выбран
Сменить `session.name`	убрать всё, кроме `[0-9A-Za-z-._]`	выбран: одна строка, рантайм остаётся свежим
Закрепить старую патч-версию	пин 7.3.16 в Dockerfile	откатывает рантайм на релиз с незакрытыми уязвимостями, включая саму CVE-2020-7070
Отключить кодирование в PHP	—	нечего отключать: это внутренняя логика отправки, параметром не управляется
Переписывать имя в nginx	подменять `%2A` на `*` на лету	хрупко и непрозрачно; следующий человек будет искать это полдня

Сам фикс — переопределение компонента сессии в локальном конфиге, который не лежит в git:

1
2
3
4


// config/main-local.php
'session' => [
 'name' => 'myapp-frontxxxend-s', // было 'myapp-front***end-s'
],

Дальше docker compose restart php. Все текущие сессии при смене имени обнуляются, но терять было нечего: залогиненных не было вовсе — все и так висели гостями.

Звёздочки в имени cookie изначально были сомнительной практикой, так что фикс заодно убрал и её. Что осталось не сделанным: исходное имя со звёздочками всё ещё лежит в конфиге в репозитории, локальный override его лишь перебивает. Кто поднимет окружение с чистого git — наступит снова. Чинить надо в апстриме, и это долг.

Итог

Когда сессия «не помнит» пользователя, первым делом сравните имя в Set-Cookie с тем, которое сервер ждёт во входящем Cookie. Если в имени есть хоть один символ вне [0-9A-Za-z-._] — это главный подозреваемый, и проверка занимает минуту. Ветка «сломано хранилище» отсекается тем, что сессия на диске корректна: запись и чтение — два независимых шага, и ломается именно второй, на уровне имени, а не содержимого.

Второй вывод — про пины. php:7.3-fpm-alpine означает «последний 7.3», а не «тот же 7.3, что был на старом сервере». Между 7.3.16 и 7.3.33 лежит security-фикс, меняющий поведение, и приложение, завязанное на тонкости рантайма, переживёт такой прыжок не всегда. Если тащите легаси в контейнер — пиньте патч-версию и прогоняйте регресс-тест входа, а не только composer install.

И третий, менее приятный: работавший вход опирался на баг. Кодирование при отправке и декодирование при чтении гасили друг друга годами, и никто об этом не знал, потому что снаружи всё выглядело исправно. Такие связки вскрываются ровно в тот момент, когда одну половину чинят по соображениям безопасности.

Первоисточники: security-баг #79699 в трекере PHP, changelog PHP 7 (записи 7.2.34, 7.3.23, 7.4.11 от 01.10.2020), ext/session/session.c и main/php_variables.c в php-src, RFC 6265 §4.1.1 про допустимые символы в имени cookie.

Patroni игнорирует правки patroni.yml: почему bootstrap.dcs работает один раз и как вернуть Ansible-роли управление кластером

BitPage — Sat, 08 Aug 2026 10:00:00 +0300

Короткий ответ: правки параметров PostgreSQL в секции bootstrap.dcs шаблона patroni.yml не действуют на живом кластере — секция читается один раз, при первичной инициализации, дальше конфигурацией управляет DCS (etcd) через patronictl edit-config. Чтобы Ansible-роль снова стала источником правды, я перенёс в локальную секцию postgresql.parameters всё, что не входит в CMDLINE_OPTIONS Patroni: из полусотни параметров шаблона за DCS остаются только полтора десятка — ровно те, что уходят в командную строку, — а для всего остального приоритет у локального конфига. Выкат прошёл без единого рестарта, через SIGHUP.

Кластер тот же, что в истории про conflict with recovery: PostgreSQL 15 под Patroni 3.0.2, конфигурация в etcd, синхронная реплика, pgBackRest в S3, PgBouncer, HAProxy. Тогда я мимоходом обнаружил, что ротация логов, аккуратно прописанная в шаблоне роли, не работала несколько лет и в каталоге тихо лежали десятки гигабайт. Эта статья — про то, что вскрылось, когда я сел разбираться до конца.

Масштаб оказался больше одной ротации. Параметр, который в репозитории значится в часах, на сервере равен секундам. Заявленный гигабайт удержания WAL на деле — 128 МБ. Никакой диверсии: все правки делались добросовестно, просто они физически не могли примениться, и ничто в выводе Ansible об этом не сообщало.

Коротко (TL;DR)

Решение: из полусотни параметров шаблона старт переживают только полтора десятка CMDLINE_OPTIONS; всё остальное перенести из bootstrap.dcs в локальную секцию postgresql.parameters — там локальный файл выигрывает у DCS, и роль становится источником правды обычным прогоном плейбука.
Для остатка: cluster-wide минимум (15 параметров из CMDLINE_OPTIONS) иначе как через DCS не задать — для него отдельный плейбук с идемпотентным PATCH /config, намеренно не включённый в обычный прогон роли.
Обязательно: хендлер на systemctl reload (SIGHUP). Таск, который пишет конфиг и никого не уведомляет, создаёт иллюзию управления. Рестарт не подходит: рестарт Patroni на лидере — это failover.
Грабли: shared_buffers: 4G — невалидная единица (PostgreSQL принимает GB, не G). Patroni выбрасывает параметр целиком, сервер работает на старом значении до первого рестарта, после — поднимается со стоковыми 128 МБ.
Грабли: wal_keep_segments удалён в PostgreSQL 13, но Patroni молча пересчитывает его в wal_keep_size (8 × 16 МБ = 128 МБ). Параметр-призрак работает через слой совместимости — ровно до какого-нибудь обновления Patroni.
Диагностика: SELECT name, setting, source FROM pg_settings — колонка source точно говорит, из какого слоя пришло значение и как его оттуда убрать.

Почему правка patroni.yml ничего не меняет на живом кластере

Секция bootstrap.dcs применяется ровно один раз за жизнь кластера — при первичной инициализации. Документация Patroni в разделе Dynamic Configuration Settings формулирует это без оговорок: «All later changes of bootstrap.dcs will not take any effect! If you want to change them please use either patronictl edit-config or Patroni REST API». После bootstrap конфигурация переезжает в распределённое хранилище — у нас etcd — и живёт там.

То есть правка шаблона на живом кластере — это правка файла, который больше никто не читает. Ansible исправно рапортует changed, файл на сервере действительно меняется, ревью проходит, коммит есть. А поведение базы — прежнее.

За несколько лет так накопилось четыре независимых слоя конфигурации, каждый со своей историей:

Слой	Что это	Как разошёлся
git	роль и group_vars	обычные правки в репозитории
`/etc/patroni/patroni.yml` на хосте	что реально развёрнуто	роль давно не прогонялась — файл отстал от git
DCS в etcd	чем управляется живой кластер	правки руками через `patronictl edit-config`
Фактические значения	что видит PostgreSQL	сверху `ALTER SYSTEM` и `ALTER DATABASE`

Показательная деталь: файл на сервере отставал от git, а DCS, наоборот, опережал его. Кто-то грамотно поправил живой кластер и синхронно обновил репозиторий — но роль с тех пор ни разу не прогонял. Дисциплина у людей была. Не было архитектуры, при которой дисциплина не нужна.

Какие параметры нельзя забрать из DCS

Пятнадцать параметров Patroni передаёт PostgreSQL аргументами командной строки, и для них локальный конфиг не действует в принципе. В исходниках это словарь CMDLINE_OPTIONS в patroni/postgresql/config.py: listen_addresses, port, cluster_name, wal_level, hot_standby, max_connections, max_wal_senders, wal_keep_segments, wal_keep_size, max_prepared_transactions, max_locks_per_transaction, track_commit_timestamp, max_replication_slots, max_worker_processes, wal_log_hints.

Причина уважительная: реплика в любой момент может стать мастером, поэтому такие параметры обязаны совпадать на всех нодах. Документация Patroni говорит про них прямо: «values set either in the local patroni configuration files or via the environment variables take no effect».

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

Проверить разделение на живом кластере можно одним запросом — параметры из командной строки видны по источнику:

1

SELECT name, setting, source FROM pg_settings WHERE source = 'command line';

Как вернуть Ansible-роли статус источника правды

План свёлся к трём ходам: развести параметры по тому, кто физически может ими управлять, и заставить роль уведомлять Patroni о каждой правке.

Всё, что не входит в CMDLINE_OPTIONS, — в локальную секцию postgresql.parameters. Здесь локальный файл выигрывает у DCS, значит роль становится источником правды сама собой: обычный прогон плейбука, без вмешательства в etcd. В нашем случае под это подпали все параметры шаблона, кроме тех полутора десятков, что уходят в командную строку.
В bootstrap.dcs остаётся только cluster-wide минимум, которым иначе управлять нельзя. Для него — отдельный плейбук с идемпотентным PATCH /config через REST API Patroni. Он намеренно не включён в обычный прогон роли: рутинный деплой не должен трогать живой кластер.
Хендлер на reload. Таск деплоя конфига обязан кого-то уведомлять, иначе файл переписан, а Patroni об этом не знает. Правильный сигнал — SIGHUP (systemctl reload patroni), не рестарт: рестарт Patroni на лидере означает потерю лидерства и failover на ровном месте.

Бонус от разделения: параметр, зависящий от объёма RAM, теперь разведён по нодам через group_vars — раньше на кластер из разных по размеру машин стояло одно значение на всех, потому что DCS другого и не умеет.

Выкатывал я в порядке «сначала реплика, потом мастер» — и этот порядок окупился на первом же шаге.

Как shared_buffers: 4G превращается в 128 МБ без единой ошибки

Невалидная единица измерения не роняет Patroni и не ломает YAML — она молча выбрасывает параметр целиком. В конфиге лежало shared_buffers: 4G. Выглядит нормально, читается нормально. Но PostgreSQL принимает другие суффиксы — документация по настройке перечисляет их закрытым списком: «Valid memory units are B (bytes), kB (kilobytes), MB (megabytes), GB (gigabytes), and TB (terabytes)». Голое G в списке отсутствует, и валидатор Patroni реагирует так:

WARNING: Removing integer parameter=shared_buffers from the config due to the invalid value=4G

Параметр не «падает в дефолт» — его просто нет в сгенерированном postgresql.conf, и значение подхватывается из включаемого postgresql.base.conf, где лежит стоковое 128MB. Работающий сервер этого не замечает: он держит старое значение в памяти. Ловушка взводится и ждёт следующего рестарта — нода поднимется с 128 МБ кэша вместо 4 ГБ. На реплике это деградация чтения, после failover — деградация продакшена.

Самое коварное: 4G годами лежал в инертной bootstrap.dcs и не вредил никому. Он ожил ровно в тот момент, когда я перенёс параметры в работающую секцию. Отсюда правило, которое я теперь произношу вслух перед каждым таким переносом: перенос параметра из мёртвой секции в живую — это изменение, а не рефакторинг.

Поймал я это на реплике, где цена ошибки нулевая, — одним запросом:

1

SELECT name, setting, source, pending_restart FROM pg_settings WHERE pending_restart;

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

Почему wal_keep_segments из DCS продолжает работать на PostgreSQL 15

Параметр, удалённый из PostgreSQL три мажорные версии назад, работал через слой совместимости Patroni — и это опаснее честной ошибки. В DCS лежал wal_keep_segments: 8. Release notes PostgreSQL 13 описывают его судьбу: «Rename configuration parameter wal_keep_segments to wal_keep_size … It is specified in megabytes, rather than number of files as with the old parameter».

Кластер на PG15, но никакой ошибки нет: Patroni молча пересчитывает старый параметр в новый по формуле 8 × 16 МБ = 128 МБ. В git при этом значился 1 ГБ — и не действовал: wal_keep_size входит в CMDLINE_OPTIONS, файл против DCS здесь бессилен.

Опасность не в самом расхождении, а в его молчаливости. Пока слой совместимости работает, всё выглядит нормально. Исчезнет он при каком-нибудь обновлении Patroni — и удержание WAL изменится без единой правки в конфигах, и никто не свяжет одно с другим.

Как найти, откуда на самом деле пришло значение параметра

Единственный надёжный способ — колонка source в pg_settings: она прямо называет слой и подсказывает, как из него значение убрать.

`source`	Где лежит	Как убрать
`default`	нигде не задано	—
`configuration file`	`postgresql.conf` (генерирует Patroni) или `postgresql.auto.conf`	смотреть `sourcefile`
`command line`	`CMDLINE_OPTIONS`, только через DCS	`patronictl edit-config` / REST API
`database`	`ALTER DATABASE … SET`	`ALTER DATABASE … RESET`
`user`	`ALTER ROLE … SET`	`ALTER ROLE … RESET`

Полный аудит ручных наслоений — три команды:

1
2
3


SELECT * FROM pg_db_role_setting; -- ALTER DATABASE / ALTER ROLE
SELECT name, setting, source, sourcefile
FROM pg_settings WHERE source <> 'default';

1

cat $PGDATA/postgresql.auto.conf # ALTER SYSTEM

Отдельно про ALTER SYSTEM под Patroni: он невидим и для git, и для самого Patroni, и теряется при пересборке ноды из бэкапа. Из всех способов «быстро поправить прод» этот — самый дорогой в обслуживании.

Аудит DCS принёс ещё один сюрприз: теневую копию pg_hba с ослабленным правилом доступа. Она годами лежала миной на случай, если из роли уберут локальную секцию, — и ушла вместе с мёртвым wal_keep_segments.

Сколько ставить wal_keep_size: считать, а не наследовать

Значение удержания WAL надо выводить из измеренной скорости генерации, причём по часам — среднее за сутки скрывает пики. Старые 128 МБ и «правильный» 1 ГБ из git одинаково взяты с потолка; я решил посчитать.

Если включён архив pgBackRest, дешёвый способ — распределение заливок сегментов по часам из лога PostgreSQL:

1

grep "pushed WAL file" postgresql-<дата>.log | cut -c12-13 | sort | uniq -c

Порядок величин, из которого удобно считать: возьмём кластер, который прокачивает под полтораста гигабайт WAL в сутки, — в среднем это около сотни мегабайт в минуту, а на всплесках кратно больше. Чтобы пережить транзиентный обрыв реплики минут в двадцать, достаточно пары гигабайт — столько и уехало в конфиг.

Важная оговорка из документации PostgreSQL: «This sets only the minimum size of segments retained in pg_wal» — это пол удержания, не гарантия. При включённой архивации отставшая реплика доберёт сегменты из архива, а при живом слоте репликации параметр вообще не участвует. В современной конфигурации это третий по значимости слой защиты, раздувать его бессмысленно.

Куда важнее оказался сосед, на которого никто не смотрел: max_slot_wal_keep_size. Та же страница документации: «If max_slot_wal_keep_size is -1 (the default), replication slots may retain an unlimited amount of WAL files». Слоты у нас включены. При таком потоке умершая реплика забивает диск мастера за считанные дни, а переполнение pg_wal — это остановка записи в базу. Вот настоящий риск — в отличие от выбора между 128 МБ и гигабайтом, вокруг которого всё началось.

Две мелкие ловушки Ansible, съевшие полдня

Обе не про Patroni, но обе всплыли в этом же выкате — оставляю здесь, потому что искал я их дольше, чем чинил.

--diff печатает секреты в терминал и в лог. Шаблон рендерит конфиг pgBackRest с ключами S3. Ansible в режиме --diff показывает изменённые строки с тремя строками контекста — в короткие файлы в это окно попадает соседняя строка с секретом, и дальше он оседает в ansible.log, который живёт вечно. Соблазн закрыть всё через no_log: true или diff: false — плохой размен: на прод-выкате diff и есть главный контроль, слепое применение опаснее секрета на экране оператора, у которого и так есть ключи от хранилища. Проблема не в видимости, а в сохранении. Durable-фикс — вынести секреты из шаблонируемого конфига: pgBackRest читает /etc/pgbackrest/conf.d/*.conf, так что ключи уехали в отдельный маленький файл под no_log, а основной конфиг остался полностью диффабельным.

--check ломается на связке shell + register. Классика, которая делает dry-run невозможным:

1
2
3
4
5
6
7
8
9


- name: Check if stanza exists
 ansible.builtin.shell: pgbackrest --stanza={{ stanza }} info
 register: stanza_check
 changed_when: false
 failed_when: false

- name: Create stanza
 ansible.builtin.shell: pgbackrest --stanza={{ stanza }} stanza-create
 when: stanza_check.rc != 0

В check-режиме shell пропускается, stanza_check не получает rc, следующий таск падает на неопределённой переменной. Read-only проверке лечение — одна строка: check_mode: false.

Пошагово

Снять фактическое состояние: SELECT name, setting, source, sourcefile FROM pg_settings WHERE source <> 'default', содержимое pg_db_role_setting, postgresql.auto.conf и patronictl show-config. Четыре слоя — четыре снимка.
Свести расхождения в таблицу git ↔ файл ↔ DCS ↔ факт. У каждого расхождения найти, какой слой прав по смыслу, а не по свежести.
Разделить параметры: всё, что не в CMDLINE_OPTIONS, — в postgresql.parameters роли; cluster-wide минимум — в отдельный плейбук с PATCH /config.
Перед переносом провалидировать каждое значение — единицы измерения, удалённые параметры. Перенос из мёртвой секции в живую — изменение, а не рефакторинг.
Добавить хендлер systemctl reload patroni на таск деплоя конфига. Не рестарт.
Прогнать на реплике, проверить SELECT … FROM pg_settings WHERE pending_restart и source ожидаемых параметров. Только потом — лидер.
Убрать ручные наслоения: ALTER SYSTEM — через ALTER SYSTEM RESET, pg_db_role_setting — через ALTER DATABASE/ROLE … RESET, лишнее в DCS — через patronictl edit-config.
wal_keep_size посчитать от измеренной генерации WAL по часам; max_slot_wal_keep_size ограничить, если включены слоты.

Итог

Весь выкат лёг через SIGHUP, без единого рестарта. Все параметры теперь приходят из кода: source = configuration file, pg_db_role_setting пуст, postgresql.auto.conf пуст, в DCS — только cluster-wide минимум без параметров-призраков. Ротация логов заработала: на мастере каталог сжался с десятков гигабайт до единиц, на реплике — с гигабайтов до сотен мегабайт.

Из этой истории я унёс три вещи. Ansible-роль, которая пишет файл и никого не уведомляет, не сходится к желаемому состоянию — она создаёт иллюзию управления. Конфигурация, которую можно править из двух мест, будет расходиться — не «может», а будет, вопрос срока; лечится это не дисциплиной, а тем, что второе место убирают или делают производным от первого. И порядок «сначала реплика, потом мастер» — не перестраховка: он поймал ошибку с 4G там, где она стоила ноль, вместо прода с урезанным в 32 раза кэшем.

Первоисточники, к которым я обращался по дороге:

Patroni — Dynamic Configuration Settings (про однократность bootstrap.dcs)
Patroni — Patroni configuration (приоритеты слоёв, параметры только для DCS)
Patroni 3.0.2 — CMDLINE_OPTIONS в patroni/postgresql/config.py и пересчёт wal_keep_segments → wal_keep_size
PostgreSQL 15 — Setting Parameters, допустимые единицы
PostgreSQL 15 — wal_keep_size и max_slot_wal_keep_size
PostgreSQL 13 — Release Notes, переименование wal_keep_segments

PostgreSQL conflict with recovery: почему hot_standby_feedback со слотами опасен, а lag= в Patroni мерит не то

BitPage — Thu, 06 Aug 2026 10:00:00 +0300

Короткий ответ: оба популярных лекарства от canceling statement due to conflict with recovery в связке Patroni + HAProxy вредны. hot_standby_feedback=on при включённых репликационных слотах сажает xmin в сам слот, и он переживает отключение реплики — проблема чтения превращается в риск для мастера. Рост max_standby_streaming_delay конвертируется в отставание, по которому балансировщик выкидывает реплику: вместо двух десятков отменённых запросов в сутки получаются веерные обрывы всего чтения. Настоящий виновник нашёлся замером: отставание в покое — десятки килобайт, всплеск от крона — около 170 МБ за несколько секунд, а порог health-check стоял на 10 МБ.

Прод: один праймари и одна реплика под Patroni 3.0.2 с etcd, PostgreSQL 15, синхронный режим, слоты включены. Веб читает с реплики через HAProxy 2.4.30, CLI ходит на мастер. Раз в четверть часа крон переписывает крупную таблицу целиком — удаляет и создаёт всё её содержимое; это чужая бизнес-логика, повлиять нельзя. Масштаб проблемы — около двух сотен отменённых запросов за полторы недели, почти все ERROR, единицы FATAL. Выглядят они так:

ERROR: canceling statement due to conflict with recovery
DETAIL: User query might have needed to see row versions that must be removed.
FATAL: terminating connection due to conflict with recovery

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

Коротко (TL;DR)

Решение: убрать on-marked-down shutdown-sessions из read-бэкенда HAProxy. Реплика всё ещё может выпасть, но живые read-запросы дорабатывают, а новые соединения уходят на мастер через use_backend master if { nbsrv(slave) eq 0 }. Лечится ущерб, а не причина — осознанно.
Не делать: hot_standby_feedback=on при use_slots: true и единственной реплике. xmin оседает в слоте и переживает смерть реплики; мастер копит мёртвые строки до заполнения диска.
Не делать: поднимать max_standby_streaming_delay с 30 с до 300 с, если health-check балансировщика смотрит на replayed-позицию. Отложенный накат — это и есть то отставание, по которому реплику выкидывают.
Грабли: lag= в Patroni задаётся только в байтах, временного порога в эндпоинте нет в принципе. Бизнес формулирует требование в секундах, health-check меряет в мегабайтах, и на пачечной записи эти величины расходятся в разы.
Грабли: pg_replication_lag_seconds на реплике в тишине растёт сам по себе — она показывает возраст последней транзакции, а не отставание.
Приём: длину всплеска можно восстановить из тайминга health-check (inter/fall/rise), не заводя новых метрик. Две трети выпадений длились ровно минимально возможные 6 секунд.

Почему hot_standby_feedback при включённых слотах — плохой размен

Со слотами hot_standby_feedback перестаёт быть локальной настройкой реплики и становится долгом мастера, который тот не может списать. Это первое, что выдаёт любой поиск по тексту ошибки, и рекомендация правильная — документация PostgreSQL 15 в разделе про конфликты запросов говорит прямо: «The first option is to set the parameter hot_standby_feedback, which prevents VACUUM from removing recently-dead rows and so cleanup conflicts do not occur» (Hot Standby — Handling Query Conflicts).

Механика проста: реплика сообщает мастеру свой xmin, вакуум не трогает версии строк, которые ещё кому-то видны, конфликтов нет. Описание параметра там же честно предупреждает про цену — «can cause database bloat on the primary for some workloads» (runtime-config-replication).

Вся разница — в том, где живёт этот xmin. Без слотов он привязан к сессии walsender: реплика отвалилась — сессия закрылась — мастер свободен. Со слотами (postgresql.use_slots в Patroni по умолчанию true) xmin оседает в самом слоте, а слот — это персистентная сущность в каталоге. Описание колонки pg_replication_slots.xmin формулирует это без оговорок: «The oldest transaction that this slot needs the database to retain. VACUUM cannot remove tuples deleted by any later transaction» (pg_replication_slots).

Слот не знает, что реплика умерла. Он знает, что кто-то ещё вернётся за этими строками.

Реплика в кластере одна, запасной нет. Включи я hot_standby_feedback, и сценарий «реплика ушла в ребут на полчаса» превращается в «мастер полчаса не вакуумит таблицу, которую крон раз в четверть часа переписывает целиком». Меняем «падает отчёт на реплике» на «может лечь мастер». Совет из интернета не плохой — он молча предполагает отсутствие слотов и наличие второй реплики. У нас нет ни того, ни другого.

Почему поднять max_standby_streaming_delay в схеме с балансировщиком хуже, чем ничего не делать

Отложенный накат WAL на реплике буквально равен отставанию, по которому health-check выносит её из пула. Второй по популярности совет выглядит безобиднее первого: не убивать конфликтующий запрос, а подождать. Цена платится только на реплике, мастера не касается вообще. Я собирался поднять max_standby_streaming_delay с дефолтных 30 секунд до 300 и уже писал правку.

Остановила конфигурация балансировщика. Health-check у нас такой:

backend slave
option httpchk GET /replica?lag=10485760
http-check expect status 200
default-server inter 3s fall 3 rise 2 on-marked-down shutdown-sessions

Patroni считает отставание по replayed-позиции — то есть по тому, сколько WAL реплика применила. А документация PostgreSQL описывает суть параметра прямо: «it is the maximum total time allowed to apply WAL data once it has been received from the primary server» (max_standby_streaming_delay). Задержка наката — это ровно рост дельты между позицией мастера и replayed-позицией реплики. Тот самый показатель, на который смотрит балансировщик.

Получается контур с положительной обратной связью. Конфликтный запрос тормозит накат → replayed отстаёт → health-check видит превышение порога → реплика уходит в DOWN → on-marked-down shutdown-sessions обрывает все живые соединения к ней. Вместо десятка-двух отменённых запросов в сутки — веерный обрыв всего чтения на каждый всплеск. Хуже исходного состояния, причём заметно.

Третий подход — поднять сам байтовый порог с 10 МБ до 512 МБ — отверг заказчик, и по делу. Требование сформулировано во времени: «секундное отставание приемлемо, полминуты — нет». Порог задан в байтах. Любое число в байтах здесь — попытка угадать время через объём.

Вариант	Что чинит	Чем платим	Вердикт
`hot_standby_feedback=on`	Конфликты уходят полностью	Со слотами xmin переживает смерть реплики → bloat на мастере	Нет: единственная реплика, риск для праймари
`max_standby_streaming_delay` 30 с → 300 с	Запросы не отменяются	Растёт replayed-отставание → флап в HAProxy	Нет: усиливает вторую проблему
Порог `lag=` 10 МБ → 512 МБ	Реплика не выпадает	Порог в байтах не отвечает на требование в секундах	Нет: угадывание времени через объём
Убрать `on-marked-down shutdown-sessions`	Живые read-запросы не рвутся	Выпадения остаются, лечится только ущерб	Да, выкачено
`agent-check` с порогом в секундах	Корректный критерий	Новая сущность в инфраструктуре	Отложено до замера

Что на самом деле выбивает реплику: посекундный замер отставания

Реплика отставала не потому, что тормозила накат, а потому, что WAL физически не успевал доехать. Развязку дал прямой замер на праймари — раз в секунду:

1
2
3
4


SELECT now()::time(0),
 pg_wal_lsn_diff(pg_current_wal_lsn(), replay_lsn) AS replay_bytes,
 pg_wal_lsn_diff(pg_current_wal_lsn(), flush_lsn) AS flush_bytes
FROM pg_stat_replication;

Если привести отсчёты к относительной шкале и огрубить величины, один всплеск выглядит так:

T+0 c replay= 0 МБ flush= 0 МБ
T+1 c replay=150 МБ flush=150 МБ ← старт пачки крона
T+2 c replay=170 МБ flush=170 МБ
T+3 c replay= 90 МБ flush= 90 МБ
T+5 c replay= 0 МБ flush= 0 МБ ← догнала

Ключевое здесь — flush практически равен replay. Разница между ними и есть время наката: то, что реплика получила, но ещё не применила. Она околонулевая. Значит накат не заторможен вообще, реплика применяет всё, что успела принять, и отставание чисто транспортное — мастер генерирует WAL быстрее, чем тот уезжает по сети.

В покое отставание держится на десятках килобайт. Всплеск от крона — около 170 МБ, и весь он укладывается в несколько секунд. Порог health-check при этом 10 МБ: до фона от него сотни раз вниз, до всплеска — семнадцать раз вверх. Всплеск перешагивает порог мгновенно и так же мгновенно кончается, и никакое значение между фоном и пиком не спасает — потому что промежуточных значений тут просто нет.

Отдельно смешное: порог уже поднимали до нас — в group_vars остался комментарий, что его увеличили, чтобы не ловить ложные DOWN на checkpoint и autovacuum. Не помогло, и теперь понятно почему: против всплеска в 170 МБ ни одно значение из десятков мегабайт не значит ничего.

Почему порог lag= в health-check Patroni нельзя задать в секундах

Временного порога в этом эндпоинте нет в принципе: lag= принимает исключительно байты. Документация Patroni формулирует это обтекаемо — «In addition to checks from replica, it also checks replication latency and returns status code 200 only when it is below specified value» (Patroni REST API). Слово «latency» сбивает с толку: единицы приводятся тут же и все они объёмные (kB, MB, GB), но пока не полезешь в исходник, остаётся ощущение, что секунды где-то рядом.

Исходник версии 3.0.2 не оставляет пространства для интерпретации (patroni/api.py, строки 101–109):

1
2
3
4
5
6
7
8
9


leader_optime = cluster and cluster.last_lsn or 0
replayed_location = response.get('xlog', {}).get('replayed_location', 0)
max_replica_lag = parse_int(self.path_query.get('lag', [sys.maxsize])[0], 'B')
if max_replica_lag is None:
 max_replica_lag = sys.maxsize
is_lagging = leader_optime and leader_optime > replayed_location + max_replica_lag

replica_status_code = 200 if not patroni.noloadbalance and not is_lagging and \
 response.get('role') == 'replica' and response.get('state') == 'running' else 503

Три вещи, которые видно только отсюда:

parse_int(..., 'B') — единица измерения зашита, байты и ничего кроме.
leader_optime берётся из DCS и обновляется раз в loop_wait, по умолчанию 10 секунд (Patroni settings). Сама величина, с которой сравнивают, уже несёт погрешность до десяти секунд.
Проверки роли и состояния идут независимо от проверки отставания, через and.

Третий пункт оказался самым важным. Умершая реплика отсекается не по lag, а по state/role: при обрыве стриминга строка в pg_stat_replication просто исчезает, и байтовую метрику неоткуда взять. То есть lag= покрывает ровно один сценарий — «реплика жива, но отстала». Всё остальное ловится другими условиями.

Сколько реплика отстаёт во времени — и почему метрика мониторинга врёт

Отставание во времени оказалось на три порядка меньше того, что заказчик считал неприемлемым. После выкатки я снял тот замер, которого не хватало для развязки: двадцать минут, раз в секунду, с праймари, колонки write_lag/flush_lag/replay_lag. Документация описывает replay_lag как «Time elapsed between flushing recent WAL locally and receiving notification that this standby server has written, flushed and applied it» (pg_stat_replication) — то есть это полный путь байта от мастера до применения на реплике.

Метрика	Значение
Медиана	единицы миллисекунд
p95	десятки миллисекунд
Максимум за всё наблюдение	пара секунд
Сэмплов выше 5 с	ни одного
Сэмплов выше 30 с	ни одного

Требование звучало как «секунда приемлема, полминуты — нет». Медиана ниже неприемлемого порога на три порядка, худший сэмпл за всё наблюдение — на порядок с лишним.

Транспортная природа отставания подтвердилась окончательно. Разница replay_lag минус flush_lag на самих пиках — три крупнейших отсчёта окна, величины огрублены:

пик 1 ~160 МБ | flush 1,0 с | replay 1,0 с | разница — доли миллисекунды
пик 2 ~100 МБ | flush 0,7 с | replay 0,7 с | разница — доли миллисекунды
пик 3 ~95 МБ | flush 1,7 с | replay 1,7 с | разница — доли миллисекунды

Накат добавляет доли миллисекунды к секунде-полутора транспорта. В окно попали два запуска крона — ровно четверть часа врозь.

Дальше я полез в Prometheus за историей и чуть не сделал неверный вывод. Метрика pg_replication_lag_seconds за месяц давала p99 в десятки секунд — то есть по её версии реплика регулярно была несвежей на десятки секунд. Это неправда. На реплике postgres_exporter считает её как now() - pg_last_xact_replay_timestamp(), и в тишине между записями она растёт сама по себе: не потому что реплика отстала, а потому что новых транзакций не было. На праймари эта же метрика всегда ровно 0.

Проверить легко — в актуальном upstream в запрос добавлена ветка-предохранитель именно на этот случай (collector/pg_replication.go):

1
2
3
4
5


CASE
 WHEN NOT pg_is_in_recovery() THEN 0
 WHEN pg_last_wal_receive_lsn () = pg_last_wal_replay_lsn () THEN 0
 ELSE GREATEST (0, EXTRACT(EPOCH FROM (now() - pg_last_xact_replay_timestamp())))
END AS lag

Вторая строка CASE — «получено равно применённому, значит лаг ноль» — гасит ровно тот эффект, который я наблюдал. В нашей версии её не было. Метрика не была сломана: она измеряла не то, что подразумевает её имя.

Одну вещь этот же Prometheus дал бесплатно. За месяц лаг превышал минуту ровно один раз: единственный реальный отказ длился несколько часов — реплика осталась без сети после ребута гипервизора. Вот с чем стоит сравнивать порог: пара секунд у худшего рабочего всплеска против нескольких часов у настоящей поломки, разница в тысячи раз. Порог lag=10MB стоял вплотную к нижней границе этого диапазона.

И ограничение самого инструмента: при scrape-интервале 15 секунд всплески длиной в несколько секунд Prometheus физически не разрешает. Для коротких событий источник — логи балансировщика, а не графики.

Как посчитать длину всплеска по таймингу самого health-check

Длина всплеска = длительность DOWN в логе плюс (fall − rise) × inter, и всё нужное для этого балансировщик уже записал сам. Приём пригодился, когда встал вопрос «а что даст fall 3 → 5», а разрешения мониторинга на такие короткие события не хватало.

Арифметика прямая. Пусть всплеск начался в T₀ и кончился в T₁:

DOWN объявляется после fall 3 × inter 3s = 9 секунд превышения порога подряд, то есть в T₀ + 9.
UP возвращается после rise 2 × inter 3s = 6 секунд ниже порога, то есть в T₁ + 6.
Длительность DOWN = (T₁ + 6) − (T₀ + 9) = длина всплеска − 3 с.

Отсюда длина всплеска ≈ длительность DOWN + 3 с.

Разбор по логу HAProxy всех выпадений за неделю с небольшим — три десятка событий:

DOWN длился	Доля выпадений	Всплеск был
6 с	около двух третей	~9 с
9 с	единичные случаи	~12 с
18 с	единичные случаи	~21 с
21 с	примерно пятая часть	~24 с
27 с	один случай	~30 с

Две трети выпадений длились ровно минимально возможный DOWN — всплеск едва перешагнул порог и тут же кончился. Отсюда конкретный ответ вместо мнения: fall 5 (нужно 15 секунд подряд) снял бы около 70 % выпадений. Оставшаяся треть — всплески по 21–30 секунд, они продолжали бы ронять реплику при любом fall.

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

Почему «конфликты роняют реплику» оказалось совпадением, а не причиной

По времени совпала примерно треть выпадений и едва двадцатая часть конфликтов. Это разные события от одной причины, а не причина и следствие. И именно эту гипотезу я проверял последней, потратив до неё заметное время на две другие.

Гипотеза про чекпоинты: checkpoint_timeout=15min, чекпоинты в логе мастера идут раз в четверть часа. Выпадения ложатся на другие минуты — не совпадают ни разу.

Гипотеза про окно бэкапа: скрипт на время pg_dump выставляет max_standby_streaming_delay=3600s, и версия «он и выбивает реплику» выглядела складно. Все выпадения длятся 6–27 секунд. Часовых окон нет ни одного.

Гипотеза «конфликты роняют реплику» держалась дольше всех, потому что и то и другое кучковалось по одним и тем же минутам. Логи лежали в разных таймзонах, я привёл их к одной шкале и сопоставил по таймстампам — вышла двадцатая часть. Кучковались они по одним минутам просто потому, что у них общий источник: крон, который раз в четверть часа переписывает крупную таблицу целиком.

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

Что выкачено: убрать ущерб, если нельзя убрать причину

Из read-бэкенда HAProxy убран on-marked-down shutdown-sessions — реплика по-прежнему может выпасть, но живые read-запросы больше не обрываются:

1
2
3
4
5


 backend slave
 option httpchk GET /replica?lag=10485760
 http-check expect status 200
- default-server inter 3s fall 3 rise 2 on-marked-down shutdown-sessions
+ default-server inter 3s fall 3 rise 2

В бэкендах master и long_queries опция оставлена — там она нужна для failover, чтобы при смене роли клиенты не остались висеть на бывшем мастере. На read-бэкенде она делала ровно противоположное задуманному. Документация HAProxy 2.4 описывает её так: «all connections to the server are immediately terminated when the server goes down. It might be used if the health check detects more complex cases than a simple connection status, and long timeouts would cause the service to remain unresponsive for too long a time» (HAProxy 2.4 configuration, on-marked-down). Формулировка описывает застрявшую базу. У нас база не застревала — она отставала на несколько секунд.

В логах это выглядело так (N — число живых сессий на момент выпадения, порядок величины — десятки):

Server slave/pg_replica is DOWN, reason: Layer7 wrong status, code: 503,
info: "Service Unavailable", check duration: 4ms. 0 active and 0 backup
servers left. N sessions active, 0 requeued, 0 remaining in queue.

Десятки живых сессий, убитых одним решением балансировщика о том, что реплика отстала на 10 мегабайт. Причём приложение видит при этом не SQLSTATE[40001], а оборванный коннект — и перехватчик, с которого началась вся история, его не ловит вообще. Новые соединения уходят на мастер сами, это уже было настроено: use_backend master if { nbsrv(slave) eq 0 }.

Размен здесь честный: убран ущерб, не причина. Для корректного критерия нужен свой health-check — agent-check HAProxy с агентом на реплике, отдающим up/down по now() - pg_last_xact_replay_timestamp(). Это новая сущность в инфраструктуре, и решение о ней принимается с цифрами на руках. Теперь цифры есть.

Приложению в ревью ушло другое: разделить ERROR (запрос отменён, соединение живо) и FATAL (соединение разорвано) — это разные сценарии восстановления; убрать недостижимый цикл повторов; добавить метрику вместо одного Log::warning. Сам перехватчик оказался корректным. Половина моих первоначальных замечаний к нему не пережила перепроверки — полезное упражнение на отделение «я бы написал иначе» от «здесь дефект».

Грабли по дороге: Ansible, ротация логов и ленивое соединение

Три находки, не связанные с задачей напрямую, но каждая из них дороже самой правки.

--check --diff вскрыл дрейф конфигурации. На сервере руками были дописаны weight 80 / weight 20, в шаблоне их не было. Прогон плейбука молча стёр бы чужую работу. Пришлось сначала подтянуть код к фактическому состоянию сервера и только потом класть свою правку. Отдельно выяснилось, что один файл group_vars оказался хардлинком на несколько инвентарей — правка в одном месте меняет все окружения сразу. Перед выкаткой на давно живущий прод надо читать весь diff, а не только «свой» кусок: это единственный шанс не стереть чужую работу.

pg_log не ротировался: десятки гигабайт на мастере, единицы на реплике, файлы копятся не первый год. Причина не в logrotate, а в том, что рабочий конфиг разошёлся с шаблоном Patroni. Настройки лежали в bootstrap.dcs, а документация Patroni про эту секцию высказывается недвусмысленно: «All later changes of bootstrap.dcs will not take any effect! If you want to change them please use either patronictl edit-config or Patroni REST API» (Patroni SETTINGS). Секция применяется ровно один раз, при первичном bootstrap кластера. Дальше живые параметры лежат в DCS, и правка шаблона не делает ничего.

Ленивое соединение с репликой терялось на любом запросе с биндингами. В проектной обвязке метод bindValues() начинался с $this->getPdo()->getAttribute(...). В Laravel getPdo() резолвит ленивое замыкание, и это буквально одна строка (Illuminate\Database\Connection):

1
2
3
4
5
6
7
8


public function getPdo()
{
 if ($this->pdo instanceof Closure) {
 return $this->pdo = call_user_func($this->pdo);
 }

 return $this->pdo;
}

$this->pdo — это write-соединение. Метод bindValues() вызывается для любого запроса с биндингами, включая чисто читающий. То есть каждый параметризованный SELECT открывал соединение с мастером просто чтобы прочитать атрибут PDO. Ленивое подключение к праймари, ради которого read/write split и городится, не работало вообще.

И ещё два наблюдения из логов. За две недели база залогировала примерно вдвое больше конфликтов, чем отрапортовало приложение, — оно видит хорошо если половину того, что с ним происходит. А application_name пуст во всех событиях, поэтому атрибутировать запрос к конкретному сервису по логам БД невозможно: виден только пользователь БД, а под ним ходят все. Второе чинится одной строкой в DSN, первое — метрикой вместо записи в лог. Обе дырки обнаруживаются только когда садишься считать вручную.

Пошагово

Прежде чем трогать hot_standby_feedback, проверить SELECT slot_name, xmin, catalog_xmin FROM pg_replication_slots; и число реплик. Слоты + одна реплика — параметр не включать.
Снять посекундный замер pg_wal_lsn_diff по replay_lsn и flush_lsn с праймари. Если flush ≈ replay, отставание транспортное, и тормозить накат бессмысленно.
Снять замер во времени — write_lag/flush_lag/replay_lag из pg_stat_replication, минимум несколько сотен сэмплов, с попаданием в пиковое окно.
Сопоставить таймстампы конфликтов и выпадений реплики, приведя логи к одной таймзоне. Делать это первым, а не последним.
Посчитать длину всплесков из лога балансировщика: длительность DOWN + (fall − rise) × inter. Отсюда — обоснованное значение fall.
Проверить, что метрика мониторинга измеряет заявленное. Для pg_replication_lag_seconds — сравнить значение на реплике в простое со значением на праймари.
Прогнать ansible-playbook --check --diff целиком и вычитать весь diff, а не свой кусок.
Выкатывать конфиг HAProxy через reload (kill -USR2 мастеру в master-worker режиме), а не рестартом. Сокеты держит мастер-процесс, порт не закрывается, старый воркер доживает текущие сессии.

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

Итог

Байтовый порог отставания отвечает на вопрос «сколько WAL не доехало». Бизнесу нужен ответ на другой — «насколько несвежие данные я сейчас отдаю». На ровной нагрузке эти вопросы почти эквивалентны, на пачечной расходятся в разы: фон — десятки килобайт, порог 10 МБ, всплеск около 170 МБ. Вся дискуссия про «какой порог поставить» была бессмысленной, пока это не проговорили вслух.

Порог, который срабатывает на рабочем всплеске в пару секунд, притом что настоящая поломка длится часами, — это не «настроено строго». Это настроено случайно: между этими двумя величинами почти четыре порядка, и порог сел вплотную к нижней. Правильный путь дальше — agent-check с временным критерием через pg_last_xact_replay_timestamp(); промежуточный и уже обоснованный — fall 3 → 5, который снимает 70 % выпадений без риска отдать несвежие данные. Оставшиеся 30 % — всплески по 21–30 секунд; их закрывает либо более высокий байтовый порог, либо смена единицы измерения на секунды.

Отдельный вывод для расследований: когда не хватает разрешения у мониторинга, считай из тайминга того, что уже логируется. Health-check с известными inter/fall/rise — готовый прибор с секундной точностью, и он ведёт запись всё время, пока ты решаешь, какую метрику завести.

Первоисточники, к которым я обращался по дороге:

Gmail отбивает всю почту: 550-5.7.26 и три сломанные аутентификации разом

BitPage — Wed, 29 Jul 2026 09:00:00 +0300

Короткий ответ: если Gmail отбивает письма с кодом 550-5.7.26, причина почти никогда не одна. У меня на легаси-релее одновременно не работали три механизма: SPF-записи не было вовсе (вместо неё лежал мёртвый SenderID), DKIM не подписывал письма из-за типа датасета в конфиге OpenDKIM (refile: там, где нужен file:), а PTR указывал на хост, чья A-запись вела на другой сервер. Чинить пришлось все три — пока сломан хотя бы один, суточная сводка остаётся прежней: bounced четырёхзначный, sent однозначный, то есть тысячи отказов против единиц доставленных.

Сервер — исходящий релей для транзакционной почты: восстановление пароля, уведомления, письма от приложений с пары десятков хостов. Postfix плюс OpenDKIM 2.10.3 в легаси-контейнере OpenVZ, DNS в Route 53, входящая почта домена идёт мимо — в Google Workspace. Аптайм — больше двух лет, конфиги не трогали годами, контейнер вне Ansible. Никто ничего не менял; поменялся Gmail.

Коротко (TL;DR)

Решение: чинить SPF, DKIM и FCrDNS одновременно, а проверять — по заголовкам доставленного письма, а не по логам Postfix. Итог: DKIM-Signature на месте, spf=pass, dmarc=pass, 250 2.0.0 OK.
Альтернатива: отдать транзакционную почту внешнему сервису (Postmark, Unisender, SES) — если некому годами следить за репутацией IP и bounce rate.
Грабли: OpenDKIM при ненайденном ключе не пишет в лог ничего. systemctl is-active → active не доказывает, что подпись ставится. Ручная отправка с самого сервера проходит успешно и создаёт ложное ощущение победы.

Что Gmail требует с 2024 года и почему сервер сломался «сам»

Требования ужесточились в феврале 2024, и легаси-конфиг, который до этого годами работал, перестал им соответствовать без единой правки на сервере. Руководство для отправителей Google требует от всех отправителей аутентификации хотя бы одним механизмом, а от массовых (от 5000 писем в сутки на адреса Gmail) — SPF и DKIM, плюс DMARC, плюс валидные прямая и обратная DNS-записи, плюс долю жалоб на спам ниже 0,3 %.

Отсюда главная ловушка этого инцидента: нет события «изменили X — упало Y». Искать «что я вчера сломал» бесполезно, потому что вчера ничего не ломали. Сломалось соответствие требованиям, которые переехали.

Дословно Gmail говорил вот что:

550-5.7.26 Your email has been blocked because the sender is unauthenticated.
550-5.7.26 Gmail requires all senders to authenticate with either SPF or DKIM.
550-5.7.26 Authentication results:
550-5.7.26 DKIM = did not pass
550-5.7.26 SPF [example.org] with ip: [203.0.113.51] = did not pass

Gmail честно перечислил оба провалившихся механизма — и SPF, и DKIM. Я это прочитал, но всё равно полез чинить их по очереди, ожидая после каждого шага, что письма пойдут. Не шли.

Почему я начал не с того: собственная заметка врала

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

Что было записано	Что оказалось на самом деле
PTR в порядке, прямая и обратная сходятся	PTR вёл на `legacy.example.org`, чья A-запись — `198.51.100.216`, другой сервер
DNS хостится на Cloudflare	Route 53 (`dig NS` → `ns-.awsdns-`)
DMARC отсутствует	DMARC на месте: `v=DMARC1; p=none`
Почта отбивается Gmail	Верно

Мораль скучная, но дорогая: перепроверять вводные руками, даже если их писал ты сам и даже если это было вчера. Особенно если это было вчера — свежая заметка вызывает больше доверия, чем заслуживает.

Что на самом деле значит 550-5.7.25 про PTR

Формулировка Gmail про PTR состоит из двух половин, и вторая важнее первой. Полностью она такая:

550-5.7.25 [203.0.113.51] The IP address sending this message does not have a PTR
550-5.7.25 record setup, or the corresponding forward DNS entry does not match the sending IP

Я, как и все, прочитал до слов «does not have a PTR record», проверил dig -x, увидел ответ и поставил галочку. А сообщение говорит «or the corresponding forward DNS entry does not match» — то есть претензия может быть не к отсутствию PTR, а к тому, что цепочка не замыкается. Проверка занимает две команды:

1
2


dig -x 203.0.113.51 +short # -> legacy.example.org.
dig A legacy.example.org +short # -> 198.51.100.216 (не тот IP)

Это классический FCrDNS: IP → имя → обратно должен получиться тот же IP. Здесь обратно получался чужой сервер. Чинить через A-запись legacy.example.org было нельзя — хост живой и обслуживает посторонний сервис. Поэтому переклеил PTR в панели хостера на mail.example.org, чья A-запись уже вела куда надо, и заодно выставил myhostname = mail.example.org, чтобы HELO совпадал с PTR. Побочных эффектов — ноль.

Почему grep по mail.log ничего не доказывает про DKIM

Проверять наличие DKIM-подписи через лог Postfix нельзя: Postfix не пишет заголовки писем в лог вообще. Я начал именно с этого:

1

grep -c "DKIM-Signature" /var/log/mail.log # -> 0

Ноль выглядит убедительно. На самом деле он не значит ничего — этот метод не отличает «не подписывает» от «подписывает». Полчаса я строил гипотезы на показаниях прибора, который ничего не измеряет.

Рабочая проверка ровно одна: отправить письмо на локальный ящик и прочитать заголовки доставленного письма.

1
2
3
4
5
6


sendmail -f noreply@example.org nobody@localhost <<'EOF'
Subject: dkim test

test
EOF
grep -A3 "DKIM-Signature" /var/mail/nobody

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

Три настоящих дефекта, которые ничего не исправили

Дальше я нашёл три реальные поломки, починил каждую — и подписи не появилось ни разу. Это стоит отдельного раздела, потому что ощущение «я же нашёл проблему» здесь работает против тебя.

Гипотеза	Как проверял	Вердикт
`opendkim.conf` обрезан	в файле 4 строки: ни `Mode`, ни `KeyTable`, ни `SigningTable`	Дефект настоящий. Дописал, рестарт — подписи нет
Демон не стартует	`systemctl is-active opendkim` → `active`, в логе чистый старт	Не дефект
Права на приватный ключ	ключ принадлежал `_apt:uuidd` с `0600`, демон работает от `opendkim`	Дефект настоящий. Исправил — подписи нет

Про конфиг: каталог /etc/opendkim/ трогали недавно, а файлы внутри были старше на годы — обновление пакета переписало часть содержимого, а заодно переставило владельца ключа на _apt. Проверять доступ надо от лица сервисного пользователя, а не от root:

1
2


su -s /bin/sh opendkim -c "head -c 20 /etc/opendkim/default/mail.private"
# head: невозможно открыть ... Отказано в доступе

chown opendkim:opendkim — обязателен. Но подписи после него так и не было. В этот момент гипотезы у меня кончились, и это оказалось лучшим, что случилось за весь инцидент.

Почему OpenDKIM молчал: file: против refile:

Причина нашлась в man-странице на самом сервере — в одном абзаце про тип датасета, от которого зависит, найдётся ключ или нет. Читал я именно локальный man opendkim.conf от версии 2.10.3: он авторитетнее любой веб-копии, потому что описывает ровно тот бинарник, который у тебя запущен. Та же страница онлайн описывает поиск в SigningTable так:

If this table specifies a regular expression file (“refile”), then the keys are wildcard patterns that are matched against the address found in the From: header field. […] For all other database types, the full user@host is checked first, then simply host, then user@.domain

То есть при refile: шаблон сопоставляется с адресом целиком. В таблицах у меня лежали записи простого формата:

example.org mail._domainkey.example.org

А подключены они были как refile:. Шаблон example.org сопоставляется с адресом noreply@example.org — не совпадает. Ключ не найден, письмо уходит неподписанным, и в логе не появляется ни одной строки. При file: вторым шагом ищется «simply host» — совпадает, ключ находится.

Фикс — одно слово в двух строках:

KeyTable file:/etc/opendkim/KeyTable
SigningTable file:/etc/opendkim/SigningTable

Альтернатива — оставить refile: и переписать записи в вид *@example.org. Я её отверг: таблицы описывали несколько доменов, и править каждую строку данных ради сохранения неподходящего типа датасета рискованнее, чем поменять тип под уже существующий формат.

Почему ручной тест проходил, а почта приложений уходила голой

Вторая половина той же поломки — слишком узкий InternalHosts, и она не видна ни одним тестом с самого сервера. Man описывает опцию так: «Identifies a set internal hosts whose mail should be signed rather than verified» — то есть хосты вне списка не подписываются, а проверяются.

Список указывал на TrustedHosts, а там лежало меньше десятка адресов. В mynetworks у Postfix их было вдвое-втрое больше. Хосты приложений в пересечение не попадали — их почта верифицировалась вместо подписи и уходила голой. А мой ручной тест шёл с 127.0.0.1, который в списке был, и проходил успешно.

InternalHosts refile:/etc/opendkim/TrustedHosts

Здесь refile: уместен: TrustedHosts действительно содержит шаблоны и подсети. Синхронизировал список с mynetworks — после синхронизации он вырос втрое и накрыл наконец те хосты приложений, которые релей и так пропускал через себя. Общий вывод дороже конкретной опции: тестировать надо тем же путём, которым ходит настоящий трафик. Отправка с самого сервера — не тот путь.

Что чинил по порядку

SPF. Записи v=spf1 не было вовсе — лежал только SenderID вида spf2.0/mfrom,pra. RFC 7208 требует «discard records that do not begin with a version section of exactly v=spf1», так что для Gmail этой записи не существовало. Опубликовал v=spf1 ip4:203.0.113.51 include:_spf.google.com include:spf.example.net ~all (последний include — рассылочный сервис, через который уходила часть писем).
DKIM, конфиг. Восстановил Mode, Canonicalization, KeyTable, SigningTable, InternalHosts, ExternalIgnoreList.
DKIM, владелец ключа. chown opendkim:opendkim на приватный ключ, проверка через su -s /bin/sh opendkim.
DKIM, тип датасета. refile: → file: для KeyTable и SigningTable.
DKIM, охват. TrustedHosts синхронизирован с mynetworks — список вырос втрое.
FCrDNS. PTR переклеен на mail.example.org, myhostname приведён к тому же имени.

Итоговый рабочий фрагмент /etc/opendkim.conf:

Mode sv
Canonicalization relaxed/simple
KeyTable file:/etc/opendkim/KeyTable
SigningTable file:/etc/opendkim/SigningTable
ExternalIgnoreList refile:/etc/opendkim/TrustedHosts
InternalHosts refile:/etc/opendkim/TrustedHosts

Сводка по трём механизмам:

Механизм	Что было	Чем проверять	Что стало
SPF	только мёртвый SenderID `spf2.0/mfrom,pra`	`dig TXT example.org +short`	`v=spf1 … ~all`, `spf=pass`
DKIM	подпись не ставилась, в логе ни строки	заголовки доставленного письма	`d=example.org; s=mail`, `dkim=pass`
FCrDNS	PTR → чужой хост → чужой IP	`dig -x IP` + `dig A <ответ>`	PTR → `mail.example.org` → тот же IP

После шестого шага письмо на Gmail получило 250 2.0.0 OK.

Что осталось сломанным: bounce rate — шесть писем из десяти

Аутентификация починена, но репутация — нет, и это отдельная задача не для админа, а для разработчиков приложения. Суточная сводка после починки: отказов по-прежнему больше, чем доставок, — примерно шесть писем из десяти уходит в никуда. Приложение годами шлёт на несуществующие адреса, включая опечатки в доменах — на @iclaud.com набегает под сотню писем в сутки.

При требуемых Google 0,3 % жалоб такой bounce rate рано или поздно уронит репутацию IP, и письма поедут в «Спам» уже при идеальных SPF и DKIM.

Отдельно красивый механизм самосокрытия проблемы: сервер слал отчёты о недоставке на адрес отправителя, домен которого сам же считал локальным через mydestination. Локального пользователя с таким именем не было, отчёт уничтожался. Круг замкнут: приложение шлёт на мёртвый адрес → отчёт об этом уничтожается → никто не узнаёт → приложение продолжает слать. Сотни уничтоженных отчётов в сутки.

Ещё не решено: envelope sender совпадает с From (правильно — отдельный технический адрес возврата с автоматической обработкой), certbot 0.12.0 стучится в отключённый acme-v01, сертификат просрочен уже несколько лет, и все правки сделаны руками на сервере вне Ansible. Последнее — честный техдолг: в репозитории этого контейнера не существует, и следующий человек ничего не найдёт.

Итог

Если Gmail отбивает почту с легаси-релея, не чините первую найденную причину — сначала постройте способ проверки, который не врёт. Для DKIM это заголовки доставленного письма, для FCrDNS — dig -x с обратной проверкой A-записи, для SPF — dig TXT с проверкой, что запись начинается ровно с v=spf1. И держите в голове главное свойство OpenDKIM: при ненайденном ключе он не пишет в лог ничего, поэтому «демон активен, конфиг валиден, ключ читается» — это ноль доказательств того, что подпись ставится.

Общее правило, которое я вынес из полутора часов: когда демон работает, но не делает свою работу, и при этом молчит — гипотезы пора прекращать и идти в man за семантикой конкретной опции. Молчание — это не «всё хорошо», это отдельный класс поведения, и у него всегда есть описание в документации.

Как вывезти живой docker-проект с умирающего диска: стрим pg_dump, pull образов, якорный exclude

BitPage — Fri, 24 Jul 2026 14:00:00 +0300

Короткий ответ: на умирающем диске pg_dump в локальный файл виснет молча — надо стримить дамп через ssh -T на здоровый диск целевой машины, чтобы источник только читал. Образы — тянуть из registry, скопировав /root/.docker/config.json с самого источника; чинить сборку из EOL-баз (buster/stretch, PGDG для PG11) — тупик: apt отдаёт 404. И rsync --exclude=log/ без ведущего слэша вырезает vendor/yiisoft/yii2/log/Logger.php, а приложение отдаёт 500 «failed to open stream».

Сервер под проектом — PHP-Yii2 + PostgreSQL порядка десяти гигабайт + Redis + пул воркеров очередей, полтора десятка сервисов в docker-compose — жил на OpenVZ-хосте с деградировавшим RAID. Диск сдох на записи, а трафик переключать было нельзя: нужно было поднять прод-подобную копию на новом Proxmox-узле (LXC + Docker), чтобы владелец пощупал вживую, но без исходящих писем и платежей. Пара часов работы, четыре тупика по дороге — все четыре из-за того, что на живом железе действуют одни правила, а на умирающем — другие.

Коротко (TL;DR)

Решение: источник читает, цель пишет. pg_dump -Fc на источнике, вывод по ssh -T в файл на быстром диске цели → pg_restore -j 4 разворачивает те же примерно десять гигабайт и около сотни таблиц с расширением rum на месте.
Решение: образы тянуть из registry, кред брать с источника — /root/.docker/config.json копируется одним scp, и docker compose pull вытягивает весь набор образов (точные прод-версии).
Решение: для теста поднимать только web-контур через COMPOSE_FILE=docker/docker-compose.yml — очереди и шедулер лежат, никакие письма и платежи никуда не уходят.
Грабли: дамп в дохлый диск не падает, а зависает — размер стоит, процесс жив. Мониторить надо дельту размера файла, а не pgrep, который совпадает сам с собой.
Грабли: rsync --exclude=log/ рекурсивен — режет log/ на всех уровнях. Ошибку выдаёт приложение, а не rsync.
Грабли: внешние сервисы фильтруют по IP. С нового узла ClickHouse встречает Connection refused — allowlist нового IP собирать заранее, а не по ходу дела.

Почему pg_dump на умирающем диске виснет, а не падает

Дамп в мёртвый диск не отдаёт ошибку — он перестаёт двигаться, оставаясь живым процессом. Первое, что я попробовал — очевидное: pg_dump -Fc внутри контейнера в bind-каталог backup/ на самом источнике. Файл дорос примерно до гигабайта и встал. Две проверки размера с интервалом в 6 секунд вернули одно и то же число, процесс — S+ в ps. Диск сдох именно на записи, и из userspace это выглядит ровно так: pg_dump ждёт очередной write(), а тот не возвращается.

Отдельно врал сторожок. Я мониторил жизнь дампа через pgrep -f pg_dump — и получал ложный «STILL_RUNNING», потому что командная строка самого pgrep содержит подстроку pg_dump и матчит саму себя. Проверки, которые не обманывают:

ps -C pg_dump — точное совпадение по имени процесса, а не по подстроке в командной строке.
Дельта размера выходного файла между двумя stat -c %s — если delta=0 за 6 с при живом процессе, дамп встал.

Мораль такая: pgrep -f вообще не годится сторожем над командами с общеупотребимой подстрокой в имени — это ложный друг, который матчит наблюдателя.

Стрим дампа: любую запись — с источника долой

Решение — снять с источника работу «писать», оставив ему только «читать». pg_dump запускается на источнике внутри контейнера с базой, но его вывод по ssh уходит на здоровый диск целевого узла:

ssh -T target-host \
"cat > /srv/dumps/appdb.dump" \
< <(docker exec app-postgres pg_dump -Fc -U app appdb)

Или наоборот — с цели pull’ом:

ssh -T old-host \
'docker exec app-postgres pg_dump -Fc -U app appdb' \
> /srv/dumps/appdb.dump

Дамп с живой базы — норма для PostgreSQL, документация 11-й версии говорит это прямо: «pg_dump does not block other users accessing the database (readers or writers)» (pg_dump 11 reference). Слоты снапшота держит сам pg_dump, приложение продолжает работать.

Две детали в транспорте, без которых стрим бинарного -Fc дампа испортится:

ssh -T — без выделения pseudo-tty. Иначе \n в бинарном потоке превращается в \r\n (мапинг ONLCR терминала), и pg_restore потом рапортует про corrupt custom archive.
docker exec — без -t по той же причине. Только docker exec app-postgres pg_dump ..., без -it.

С этими двумя флагами дамп в полтора гигабайта прошёл, EXIT=0, а на цели:

pg_restore --no-owner -j 4 -d appdb /srv/dumps/appdb.dump

Развернулся обратно в те же примерно десять гигабайт, около сотни таблиц, расширение rum подхватилось. Проверил \dx — на месте.

Почему EOL-образы нельзя пересобрать, но можно вытянуть

Готовый образ в registry — это точная прод-версия, а сборка Dockerfile через несколько лет упирается в исчезнувшие apt-репозитории. Первый docker compose pull на новом узле лёг:

Error response from daemon: error from registry: access forbidden

Приватный GitLab-registry, новая машина против него не авторизована. Я пошёл не в ту сторону — решил, что раз pull не идёт, соберу из docker/ (Dockerfile’ы те же, что в проде). Собирать пришлось из EOL-баз, и apt по очереди вернул мне это:

База образа	Debian внутри	Что говорит apt в 2026
`nginx:1.17.4`	buster	`Err:5 http://deb.debian.org/debian buster Release 404 Not Found`
`postgres:11`	stretch	`E: Failed to fetch http://apt.postgresql.org/pub/repos/apt/dists/stretch-pgdg/11/binary-amd64/Packages 404 Not Found`

Buster ещё как-то перенаправляется на archive.debian.org. А stretch-based postgres:11 дальше не идёт: PGDG для EOL-мажора вычистили, официальных пакетов не существует. Я потратил на этот проулок полчаса, пока не сообразил, что решаю не ту задачу.

Ответ всё это время лежал на самом источнике: он же откуда-то эти образы pull’ит. Значит, у него есть рабочие креды registry, и лежат они там, куда их складывает docker login — в /root/.docker/config.json. Копия одного файла:

scp old-host:/root/.docker/config.json /root/.docker/config.json

И docker compose pull вытянул весь набор образов — те самые байты, что крутятся в проде. Никакой сборки.

Как rsync-exclude без слэша съел framework

--exclude=log/ без ведущего слэша матчит любой каталог log/ на любой глубине, а не только корневой. Я добавил это, чтобы не тащить пару гигабайт логов приложения через сеть. Rsync отработал чисто, приложение поднялось — и отдал HTTP 500:

include(/app/vendor/yiisoft/yii2/log/Logger.php):
failed to open stream: No such file or directory

Ошибка ведёт куда угодно, только не к rsync. «Битый vendor» — первая гипотеза, за ней я и погнался: перекачал vendor, проверил композер-lock, сравнил размеры. И на третьей минуте понял, что exclude’ы у меня рекурсивные — и они срезали vendor/yiisoft/yii2/log/ заодно с логами приложения.

Правило в мане rsync проговаривается прямым текстом: «if the pattern starts with a / then it is anchored to a particular spot in the hierarchy of files, otherwise it is matched against the end of the pathname» (rsync(1)). Ключевое слово — «otherwise».

Фикс — один символ:

rsync -a --exclude=/log/ code/ target:/app/

Ведущий слэш якорит паттерн к корню передачи. Второй прогон rsync без изменений прислал только те log-каталоги, что были ошибочно вырезаны — секунды инкрементального трафика.

Тест на боевых интеграциях без сайд-эффектов

Именно очереди и шедулер порождают исходящие эффекты — письма, платежи, запросы в CRM. Web-морда поверх копии БД безопасна. Приложение общалось с боевым платёжным шлюзом, CRM, SMTP и ClickHouse, и тестовая копия должна была подняться, никого не разбудив. Docker-compose был уже разбит на два файла — docker-compose.yml (nginx, php-fpm, api) и docker-compose.queue.yml (пул воркеров очередей и шедулер) — так что весь предохранитель свёлся к одной переменной:

COMPOSE_FILE=docker/docker-compose.yml docker compose up -d

Поднялся только web-контур. Smoke-тест:

API → 200
сайт → 302 на логин
админка → рендерит форму входа

Одна внешняя интеграция всё-таки вылезла. Backend страниц, которые ходят в аналитический ClickHouse, отдавал 503, и в логе:

/dev/tcp/clickhouse.example:31450: Connection refused

Не проблема сети, а allowlist: ClickHouse на удалённом узле фильтрует по IP, и новый узел в белом списке ещё не был. Это общая закономерность: любой сервис на белом списке (БД, mail, аналитика, платёжка) — часть чек-листа миграции, а не сюрприз в момент cutover.

Пошагово

Понять сначала характер отказа диска. «Чтение живо, запись висит» переворачивает все дальнейшие решения — не пробовать дальше писать на источник.
Скопировать /root/.docker/config.json с источника на цель одним scp. Убедиться, что docker compose pull вытягивает все образы.
Стрим дампа: ssh -T source 'docker exec db pg_dump -Fc -U app appdb' > /srv/dumps/appdb.dump на целевом узле. Сторожок — дельта размера, не pgrep.
pg_restore --no-owner -j 4 -d appdb /srv/dumps/appdb.dump. Проверить \dx — расширения на месте.
rsync кода и медиа с якорным exclude’ом: --exclude=/log/, а не --exclude=log/. Второй прогон покажет, что пропущено.
Поднять web-контур через COMPOSE_FILE=docker/docker-compose.yml docker compose up -d — очереди и шедулер лежат.
Smoke-тест: API, публичная морда, админка. Собрать список внешних сервисов, у которых новый IP не в allowlist.
Cutover — позже, в окно тишины: свежий дамп поверх, DNS, IP в белые списки, mail-репутация.

Итог

Умирающее железо меняет правила: источник — только на чтение, хочешь ты этого или нет. Из этого вытекает всё остальное — стримить дамп, а не писать локально; тянуть образы из registry, а не пересобирать EOL-базы; якорить exclude’ы до того, как они срежут vendor/. Копия проекта поднялась за несколько часов, и большая часть потерянного времени — драки с проблемами (архивы Debian, «битый vendor»), которые уже были решены ограничениями задачи.

Что осталось за скобками этой сессии: доступ нового IP к ClickHouse (получить allowlist), финальный cutover со свежим дампом и переключением DNS, репутация mail-IP на новом хосте. Cutover — отдельная история и, кажется, отдельная статья.

Первоисточники, к которым я обращался по дороге:

CrowdSec на Debian 13: пять граблей, которых нет в туториалах

BitPage — Fri, 24 Jul 2026 08:40:00 +0300

Короткий ответ: CrowdSec на Debian 13 (trixie) ставится за вечер, но три вещи ведут себя не так, как в гайдах: OpenSSH 9.8 пишет логи от имени sshd-session, а не sshd; ssh-логи надо забирать из journald, потому что /var/log/auth.log больше не главный источник; бан-таблица nftables создаётся в семействе ip, а не inet — и её легко «не найти». Плюс два организационных правила: whitelist со своими IP — до первого запуска, на боевой прод — сначала режим detect-only без банов.

На хостах у меня много лет жил самодельный слой защиты: nginx-конфиг с блокировкой по User-Agent и крон, который раз в сутки тянул список Tor-exit-нод и вбивал его в nginx через deny. При переезде на Debian 13 я наконец разобрался, чего этот слой стоит, выкинул его и поставил CrowdSec с nftables-bouncer’ом. По дороге собрал пять граблей — ни одной из них нет в туториалах.

Коротко (TL;DR)

Решение: CrowdSec (агент + nftables firewall-bouncer) с acquisition через journald. Bouncer держит собственную nft-таблицу и мирно живёт рядом с уже существующим кастомным firewall.
Альтернатива: fail2ban — если нужен только ssh и не нужны краудсорс-блоклисты. Но с sshd-session из OpenSSH 9.8 наивные regex-фильтры сломаются точно так же.
Грабли: cscli metrics показывает ssh-логи как unparsed (это норма); таблица бана — nft list table ip crowdsec, не inet; смена порта в sshd_config игнорируется при socket-активации; без whitelist забанишь свой же IP; на прод с клиентами — сначала detect-only.

Почему крон с Tor-блоклистом — не защита

Ежедневная выгрузка Tor-нод в nginx deny — ритуал, а не защита, и держать его в 2026 году нет смысла. Разбор моего крона показал три проблемы. Во-первых, он закрывает только Tor, а реальные атаки приходят с VPN, облачных провайдеров и ботнетов — по ним списка нет. Во-вторых, после обновления списка крон делал nginx restart вместо reload — раз в сутки рвались все живые соединения. В-третьих, гигантский deny-список nginx проверяет линейно на каждый запрос.

То есть слой создавал видимость работы: что-то качается, что-то блокируется, в логах движение. А фактическую атаку — перебор паролей ssh, сканирование nginx — он не видел вовсе.

CrowdSec или fail2ban

Я выбрал CrowdSec: он закрывает те же сценарии, что fail2ban, плюс даёт краудсорс-репутацию IP, а риск «вендор умрёт» снимается лицензией и локальной архитектурой. Сравнение по пунктам, которые важны были мне:

	fail2ban	CrowdSec
Механизм детекта	regex по строкам лога	парсеры + сценарии (leaky bucket), многострочная логика
Источники логов	файлы	файлы, journald, docker и другие
Механизм бана	сам пишет правила в iptables/nftables	отдельный bouncer со своей nft-таблицей
Репутация сообщества	нет	краудсорс-блоклисты (обмен сигналами)
Работа без вендора	полная автономия	полная: ядро под MIT, решения принимает локальный LAPI

Последняя строка была для меня решающей. Был страх: CrowdSec — компания, а вдруг она закроется. Проверил: ядро CrowdSec распространяется под MIT, детект и баны работают полностью локально через Local API. Если компания исчезнет, потеряется только краудсорс-репутация — сам IPS продолжит работать.

Как поставить: агент, коллекции, bouncer

Порядок такой: сначала агент с коллекциями и whitelist’ом, обкатка без банов, и только потом bouncer.

Подключить репозиторий CrowdSec и поставить агент: apt install crowdsec.
Поставить коллекции под свой стек: cscli collections install crowdsecurity/sshd crowdsecurity/nginx crowdsecurity/linux.
Настроить acquisition: ssh — через journald, nginx — по glob лог-файлов (ниже).
Добавить whitelist со своими IP и внутренними сетями (ниже, шаг обязательный).
Перезапустить агент и проверить cscli metrics — логи должны читаться.
Обкатать detect-only: агент детектит и пишет решения в cscli decisions list, но банить некому.
Когда ложных срабатываний нет — поставить bouncer: apt install crowdsec-firewall-bouncer-nftables.

Acquisition для ssh на Debian 13 надёжнее делать через journald, а не через файл (документация CrowdSec по journald-источнику):

1
2
3
4
5
6


# /etc/crowdsec/acquis.d/ssh.yaml
source: journalctl
journalctl_filter:
 - "_SYSTEMD_UNIT=ssh.service"
labels:
 type: syslog

Грабли 1: cscli metrics показывает ssh-логи как unparsed

Строки «unparsed» в cscli metrics по ssh — не признак поломки: парсер намеренно не разбирает записи об успешных логинах. Я на это попался: увидел ssh-логи в колонке unparsed и решил, что парсер не работает на свежем стеке.

Причин запутаться сразу две. Первая — в release notes OpenSSH 9.8 сказано прямо: «the server has been split into a listener binary, sshd(8), and a per-session binary “sshd-session”». То есть строки о сессиях в логе теперь идут от процесса sshd-session, и любой фильтр, который ждёт sshd[, молча перестаёт находить их. Вторая — на Debian 13 auth-события живут в journald, и привычки смотреть /var/log/auth.log больше недостаточно.

Проверить, что детект жив, можно за минуту — скормить парсеру строку неудачного логина:

1

cscli explain --type syslog --log "Jul 23 10:00:00 host sshd-session[1234]: Failed password for root from 198.51.100.7 port 44444 ssh2"

В выводе видно всю цепочку: строка парсится и попадает во все ssh-bruteforce-сценарии. Детект работал с самого начала — вводила в заблуждение метрика.

Грабли 2: nft list table inet crowdsec пустой

Bouncer создаёт таблицы в семействах ip и ip6, а не inet — проверять бан надо командой nft list table ip crowdsec. Я после первого бана полез в inet, увидел пустоту и решил, что баны не работают.

Документация firewall-bouncer это подтверждает: для IPv4 создаётся table ip crowdsec с сетом crowdsec-blacklists, для IPv6 — table ip6 crowdsec6. Рабочие команды диагностики:

1
2
3


cscli decisions list # что забанено с точки зрения CrowdSec
nft list table ip crowdsec # что реально в firewall (IPv4)
nft list table ip6 crowdsec6 # то же для IPv6

Отдельная таблица — это и ответ на вопрос «не подерётся ли bouncer с моим кастомным firewall». На моих нодах уже был свой набор nftables-правил, и я боялся, что новый инструмент его сломает. Не подрался: у bouncer’а своя таблица, оба хука input отрабатывают независимо, и DROP в любой из таблиц финален. Существующие правила я не трогал вообще.

Грабли 3: смена порта в sshd_config не работает

Если ssh запущен через socket-активацию systemd, параметр Port в sshd_config игнорируется — слушающий сокет описан в юните ssh.socket, и менять порт надо там либо возвращать классический service-режим. Я в рамках той же чистки решил увести ssh со стандартного порта, поправил конфиг, сделал рестарт — порт не изменился.

Диагноз ставится одной командой: systemctl status ssh.socket. Если сокет активен — правки Port в конфиге бесполезны. Я вернул службу в обычный режим:

1
2


systemctl disable --now ssh.socket
systemctl enable --now ssh.service

После этого sshd_config снова источник правды. Прямого отношения к CrowdSec эти грабли не имеют, но наступил я на них в той же сессии, и в паре с «логи теперь от sshd-session» они складываются в общий вывод: на свежем Debian старые привычки вокруг ssh стоит перепроверять по одной.

Почему whitelist нужен до первого запуска

Без whitelist CrowdSec забанит ваш собственный IP при первой же проверке типа «а задетектит ли он брутфорс» — и вы останетесь без доступа к хосту. Документация CrowdSec определяет их так: «Whitelists are special parsers that allow you to “discard” events» — событие отбрасывается на этапе парсинга и до сценариев не доходит.

Минимальный parser-whitelist:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10


# /etc/crowdsec/parsers/s02-enrich/01-my-whitelist.yaml
name: my/whitelist
description: "Не банить себя и внутренние сети"
whitelist:
 reason: "admin IPs and internal networks"
 ip:
 - "127.0.0.1"
 cidr:
 - "10.0.0.0/8"
 - "198.51.100.0/24" # сюда — свои админские сети

Меня этот файл однажды спас. На одном из хостов я забыл про план «сначала без банов» и поставил bouncer сразу — CrowdSec встал в боевой режим на работающем проде. Обошлось: whitelist не дал системе залочить меня самого, а забанены оказались только реальные сканеры. Но полагаться на такое везение на хосте с клиентским трафиком нельзя.

Как раскатывать на прод: сначала detect-only

На критичный прод CrowdSec ставится в два этапа: сначала агент без bouncer’а — детект есть, банов нет; и только после недели чистых логов — bouncer с реальными банами. «Режим» здесь — просто отсутствие пакета crowdsec-firewall-bouncer-nftables: агент пишет решения в cscli decisions list, а исполнять их некому.

Логика простая. Ложный бан на внутреннем хосте — неприятность для админа. Ложный бан на edge-ноде — заблокированный клиент, то есть деньги. Поэтому раскатку по парку я в Ansible-роли развёл переключателем: некритичные хосты получают агент и bouncer сразу, боевые — сначала только агент. Список хостов под IPS — явным перечнем в плейбуке: попытка вывести «умные» группы под каждый инструмент — лишняя инженерия, которая на десятке хостов ничего не даёт.

Итог

Если ставите CrowdSec на Debian 13 — закладывайте вечер и держите под рукой три команды: cscli explain (проверить, что детект жив, не доверяя колонке unparsed), nft list table ip crowdsec (смотреть баны в правильном семействе) и systemctl status ssh.socket (понять, кто на самом деле слушает порт). Whitelist со своими IP — до первого запуска, bouncer на боевом проде — только после обкатки без банов. А самодельные блоклисты типа «крон с Tor-нодами» спокойно выкидывайте: после разбора оказалось, что мой не защищал ничего — только рестартовал nginx раз в сутки.

Какие нейросети потянет ваш компьютер — проверяем за минуту

BitPage — Sun, 22 Feb 2026 06:30:00 +0300

Короткий ответ: утилита llmfit сканирует ваш CPU, RAM и GPU, затем из базы в 157 моделей показывает, какие реально запустятся и с какой скоростью.

Зачем запускать нейросети локально

Приватность — данные не уходят на сервера
Бесплатно — никаких подписок и лимитов
Офлайн — работает без интернета
Скорость — нет задержек на API

Проблема: непонятно, какую модель выбрать под своё железо. 7B? 13B? 70B? Хватит ли памяти?

llmfit решает эту проблему

Одна команда — и видишь полную картину:

1

curl -fsSL https://llmfit.axjns.dev/install.sh | sh

Или через Homebrew:

1
2


brew tap AlexsJones/llmfit
brew install llmfit

Как использовать

Просто запусти:

1

llmfit

Откроется интерактивное меню. Модели уже отсортированы по совместимости с твоим железом.

Управление:

↑/↓ — навигация
/ — поиск модели
f — фильтр (Perfect / Good / Marginal)
d — скачать через Ollama
q — выход

Что показывает

Для каждой модели — четыре параметра:

Параметр	Что значит
Quality	Качество модели (репутация, бенчмарки)
Speed	Прогноз скорости (токенов/сек)
Fit	Насколько эффективно использует память
Context	Размер контекстного окна

Плюс сразу видно:

Сколько нужно RAM / VRAM
Режим: GPU / CPU+GPU / только CPU
Совместимость: Perfect / Good / Marginal / Too Tight

157 моделей от 30 провайдеров

В базе: Llama, Mistral, Qwen, Gemma, Phi, DeepSeek, Cohere и другие.

Категории:

Общего назначения
Код
Рассуждения (reasoning)
Чат
Мультимодальные

Минимальные требования

Параметры модели	RAM / VRAM
7-8B (Q4)	6-8 GB
13B (Q4)	10-12 GB
30B (Q4)	20-24 GB
70B (Q4)	40+ GB

Q4 — это квантование до 4 бит. Сжимает модель в 4 раза с минимальной потерей качества.

Быстрый старт после llmfit

Если llmfit показал, что модель подходит — качай через Ollama:

1
2
3
4
5


# Установить Ollama
curl -fsSL https://ollama.com/install.sh | sh

# Скачать и запустить модель
ollama run llama3.2

Или прямо из llmfit: нажми d на нужной модели.

Итог

Перед тем как качать 40 GB модель, которая не запустится — проверь через llmfit. Минута на установку, и сразу видно, что реально потянет твоё железо.

GitHub: github.com/AlexsJones/llmfit

Какую нейросеть выбрать в 2026: короткий гайд

BitPage — Sun, 22 Feb 2026 06:00:00 +0300

Короткий ответ: DeepSeek — для кода и экономии. ChatGPT — для текстов и креатива. Qwen — если нужен русский и бесплатно.

Сравнение цен (за 1 млн токенов)

Модель	Ввод	Вывод	Итого дешевле
DeepSeek R1	$0.55	$2.19	в 20-30 раз
Qwen 2.5	бесплатно*	бесплатно*	—
ChatGPT (GPT-5)	$1.25	$10	база
Claude 4.1	$3	$15	дороже

*Qwen бесплатен через чат, API платный но дешёвый

Что для чего

Код → DeepSeek

Лучший выбор для:

Написания кода
Дебага
Алгоритмических задач
Математики

DeepSeek R1 заточен под reasoning — он думает пошагово. Для кода это идеально.

Тексты и креатив → ChatGPT

Лучший выбор для:

Статей и постов
Сторителлинга
Работы с тоном и стилем
Длинных связных текстов

ChatGPT лучше держит стиль, понимает эмоции, пишет естественнее.

Русский язык + бесплатно → Qwen

Лучший выбор для:

Работы на русском без VPN
Быстрых задач без оплаты
Анализа картинок и видео (Qwen-VL)

Qwen 2.5 работает в России без VPN, понимает русский, есть бесплатный чат.

Сложные задачи → Claude

Лучший выбор для:

Анализа больших документов
Работы с контекстом 200K+ токенов
Задач где важна точность

Claude дороже, но у него самое большое окно контекста.

Практический совет

Не выбирай одну модель на всё. Комбинируй:

DeepSeek для кода — экономишь в 20 раз
Qwen для быстрых вопросов — бесплатно
ChatGPT/Claude для важных текстов — когда качество критично

Где пользоваться

DeepSeek: chat.deepseek.com или API
Qwen: qwen.ai (работает в РФ)
ChatGPT: chat.openai.com (нужен VPN)
Claude: claude.ai (нужен VPN)

Или через агрегаторы типа OpenRouter — там все модели в одном месте.

Итог

80% стартапов в Кремниевой долине уже перешли на китайские модели. Не потому что они лучше во всём — а потому что дешевле в 20 раз при сравнимом качестве.

Для большинства задач разницы не заметишь. А бюджет заметишь.

Как я перестал злиться на AI и начал нормально кодить

BitPage — Tue, 17 Feb 2026 08:00:00 +0300

Короткий ответ: AI пишет хороший код, если правильно с ним работать. Проблема не в моделях — проблема в том, как мы даём им задачи.

Полгода назад я думал, что Copilot и Cursor — это хайп. Генерят мусор, приходится всё переписывать. Потом понял: я просто не умел с ними работать.

Коротко: что изменило игру

Перестать винить AI — если код плохой, проблема в задаче
Давать контекст — модель не телепат, ей нужна архитектура
Планировать до кода — сначала план, потом реализация
Тесты вместо ревью — глаз замыливается, тесты нет
Коммиты после каждого шага — иначе откатить невозможно

Главный сдвиг в голове

Раньше я думал: “Cursor написал фигню, тупая модель”.

Сейчас думаю: “Что я сделал не так в промпте?”

Современные модели — это уверенный мидл-разработчик. Он умный, но не экстрасенс. Если дать ему задачу “сделай авторизацию”, получишь что-то абстрактное. Если дать контекст, план и примеры — получишь рабочий код.

Три причины плохого кода от AI:

Контекст не собран или противоречив
Инструкции слишком абстрактные
Нет тестов и критериев “что значит готово”

Контекст — это топливо

AI не видит твой проект целиком. Он видит то, что ты ему показал.

Что работает:

Сверху вниз — начни с архитектуры, потом спускайся к модулям. Не кидай сразу в баг на 500-й строке.
Memory Bank — создай файлы с описанием проекта: структура, правила, зависимости. Я держу ARCHITECTURE.md и CONVENTIONS.md в корне.
Узкий фокус — когда AI понял общую картину, сужай: “теперь работаем только с модулем авторизации”.

План до кода — обязательно

Самая частая ошибка: сразу просить код.

Как правильно:

Попроси AI составить план реализации
Проверь план — всё ли учтено?
Попроси дополнить пробелы
Сохрани план в .md файл
Только потом — реализация по пунктам

Даже топовые модели типа Claude теряют контекст на длинных задачах. Файл с планом — якорь, к которому можно вернуться.

Тесты вместо code review

Читать тысячи строк сгенерированного кода — бесполезно. Глаз замыливается, пропускаешь ошибки.

Что делаю я:

Прошу AI написать e2e тест на фичу — это главное
Запускаю тест
Если падает — даю AI ошибку, он фиксит
Повторяю пока не зелёный

Обратная связь через тесты работает лучше, чем “перепиши, мне не нравится стиль”.

Верификация: не верь “Готово”

AI любит говорить “Готово!”, когда сделано 70%.

Мой чеклист:

Беру файл с планом
Прохожу по каждому пункту
Проверяю: есть код? есть тест?
Если нет — возвращаю AI на доработку

Этот шаг спасает от 80% недоделок.

Git-гигиена

Коммиться после каждого этапа. Серьёзно.

Сформировал план → git commit -m "plan: auth module"
Реализовал пункт → git commit
Тесты прошли → git commit

Если AI пошёл не туда — git reset и пробуем иначе. Без этого откатить изменения в 15 файлах — боль.

Какой инструмент выбрать

Пользуюсь всеми тремя, для разных задач:

Инструмент	Лучше всего для
GitHub Copilot	Повседневный код, автодополнение, бойлерплейт
Cursor	Большие проекты, рефакторинг, работа с несколькими файлами
Claude Code	Сложные задачи, архитектура, объяснения

Copilot для рутины, Cursor для проектов, Claude когда нужно подумать.

Итог

AI coding работает, если:

Даёшь контекст и план
Проверяешь тестами, а не глазами
Коммитишься часто
Не веришь на слово “Готово”

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

Часть инсайтов взял из статьи на Хабре и обсуждений на Reddit. Но проверил всё на своих проектах — работает.

Manus в Телеграме — или как я перестал бояться нейросетей

BitPage — Tue, 17 Feb 2026 07:15:00 +0300

Значит, сижу я вчера вечером, листаю ленту. Жена на диване что-то смотрит, кот орёт — есть хочет. И тут читаю: Manus теперь в Телеграме.

Ну, думаю, опять какой-то бот, который будет отвечать “я вас не понял, уточните запрос”. Таких я уже штук пятнадцать пробовал.

А вот и нет.

Что вообще за Manus?

Если коротко — это ИИ-агент. Не просто чат-бот, который отвечает на вопросы. А штука, которая реально делает дела. Ну, или пытается.

Подключаешь свой аккаунт, даёшь ему доступ к почте, календарю, заметкам — и он начинает в этом всём копаться. Звучит страшно? Мне тоже так показалось. Но любопытство победило.

Что он умеет (из того, что я попробовал)

Голосовые в текст. Вот это прям спасение. Присылает друг голосовое на три минуты — про то, как поругался с начальником, что делать с проектом и куда поехать в отпуск. Всё в одном сообщении, разумеется. Кидаю боту — он выдаёт конспект. С пунктами!

Разбор почты. Подключил рабочую почту (да, было страшно). Говорю: найди письма от Иванова за последнюю неделю и скажи, что он хотел. Нашёл. Сказал. Я в шоке.

Презентации. Это я ещё не до конца освоил, но в теории — говоришь “сделай презентацию про продажи за квартал”, и он делает. Со слайдами. Правда, потом всё равно надо проверять, но черновик — готов.

Картинки. Ну, это уже стандарт для всех ИИ. “Нарисуй кота в космосе” — рисует. Кот странный, но в космосе.

Что меня удивило

Он помнит контекст. Нет, серьёзно. Я ему неделю назад объяснял, что мне нравится короткий стиль ответов, без воды. Сегодня спрашиваю про погоду — отвечает в два слова. Запомнил!

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

Что не понравилось

Ну, во-первых, страшно давать доступ к почте и календарю. Да, я дал. Да, мне всё ещё тревожно. Но пока вроде ничего не сломалось и спам не посыпался.

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

В-третьих, иногда он всё-таки тупит. Но тут уж — а кто не тупит? Я вот тоже иногда захожу на кухню и забываю, зачем пришёл.

Почему ещё и Телеграм?

У Manus и так есть сайт (manus.im) и своё приложение — они с марта 2025 года работают. Два миллиона человек в очереди на бету было, представляете?

Но ребята решили пойти дальше — теперь и в Телеграме можно. Логично: зачем переключаться между приложениями, если можно всё в одном месте? Написал боту, он сделал — красота. Обещают ещё WhatsApp, Slack и Discord подключить.

Итог

Короче, если вы как я — вечно заняты, вечно что-то забываете, вечно тонете в голосовых и письмах — попробуйте. Может, не заменит секретаря полностью (хотя бы потому что секретарь может сходить за кофе), но жизнь упростит.

А мне пора. Кот всё ещё орёт.

Бесплатный стек для стартапа — собираем продукт за $0

BitPage — Tue, 17 Feb 2026 07:00:00 +0300

Короткий ответ: да, в 2026 году можно собрать полноценный стек для продукта за $0. IDE, база, авторизация, AI-модели, деплой — всё бесплатно на старте.

Наткнулся на пост на Reddit, где разработчик оптимизировал свой стек до нуля долларов. Разобрал его подход и добавил свои комментарии.

Коротко: весь стек

Задача	Сервис	Бесплатный лимит
IDE	Google AntiGravity	Полностью бесплатно
База данных	Supabase	Nano-план бесплатный
Авторизация	Stack Auth	До 10K пользователей
AI-модели	OpenRouter / Gemini AI Studio	Есть бесплатные модели
Своя модель	Unsloth AI + Google Colab	Бесплатный файн-тюнинг
Деплой	Vercel	Бесплатный тир для пет-проектов
Git	GitHub / GitLab	Бесплатно
Аналитика	PostHog, Clarity, GA	Всё бесплатно

Разбор по категориям

IDE: Google AntiGravity

Новая бесплатная IDE от Google. Пока в бете, но уже рабочая. Альтернативы: VS Code (бесплатно), Cursor (есть бесплатный тир).

База данных: Supabase

PostgreSQL + авторизация + realtime из коробки. Nano-план бесплатный — для MVP и тестов хватает. Когда вырастешь, можно мигрировать или платить.

Альтернативы: PlanetScale (MySQL), Neon (PostgreSQL), Firebase (NoSQL).

Авторизация: Stack Auth

Бесплатно до 10 000 пользователей. Для старта — более чем достаточно. Если у тебя 10K юзеров, ты уже можешь позволить себе платить.

Альтернативы: Clerk, Auth0 (есть бесплатные тиры), Supabase Auth (если уже используешь Supabase).

AI-модели: OpenRouter + Gemini

OpenRouter — агрегатор моделей, есть бесплатные варианты. Gemini через AI Studio — бесплатно для экспериментов.

Для прода можно файн-тюнить свою модель через Unsloth AI прямо в Google Colab — тоже бесплатно.

Деплой: Vercel

Стандарт для Next.js проектов. Бесплатный тир покрывает пет-проекты и MVP.

Альтернативы: Netlify, Cloudflare Pages, Railway.

Аналитика: три инструмента

PostHog — продуктовая аналитика, фичи-флаги, сессии
Microsoft Clarity — тепловые карты, записи сессий
Google Analytics — трафик, источники, конверсии

Все три бесплатны и решают разные задачи.

Честный взгляд

Собрать стек за $0 — реально. Но есть нюанс:

Бесплатные тиры работают, пока ты маленький. Когда придут пользователи (если придут), начнутся расходы:

Больше запросов к базе
Больше трафика на хостинге
Больше вызовов AI-моделей

И главное: найти пользователей и заставить их платить — вот настоящая задача. Техническая часть сейчас самая дешёвая в истории. Маркетинг и продажи — нет.

Что бы я добавил

Для российских разработчиков есть нюансы:

Vercel может требовать карту при верификации
Некоторые сервисы не работают без VPN
Оплата при росте — отдельная боль

Но для MVP и тестирования идеи — стек рабочий.

Итог

Если хочешь запустить продукт с нулевым бюджетом — это возможно. Supabase + Vercel + бесплатные AI-модели закрывают 90% потребностей на старте. Главное — не застрять в “идеальном стеке” и начать делать продукт.

Стек — это 5% успеха. Остальные 95% — найти тех, кому это нужно.

Какие нейросети работают в России без VPN

BitPage — Wed, 03 Dec 2025 00:00:00 +0000

После того как ChatGPT стал недоступен без VPN, а Claude вообще заблокировал регистрацию из России, пришлось искать альтернативы. Потратил время, потестил разные варианты. Делюсь, что реально работает.

Что важно

Критерии простые:

Работает без VPN
Можно зарегистрироваться с российским номером/почтой
Есть бесплатный доступ или оплата российской картой

DeepSeek

Китайская нейросеть, которая в начале 2025-го наделала шума. Работает на уровне GPT-4, но полностью бесплатна через веб-интерфейс.

Что умеет:

Отвечает на русском нормально
Пишет и анализирует код
Есть режим DeepThink для сложных задач — разбивает запрос на части и думает пошагово

Как пользоваться: Заходишь на chat.deepseek.com, регистрируешься по почте, пользуешься. VPN не нужен, лимитов на запросы нет. Платить нужно только за API, если хочешь интегрировать куда-то.

Минусы: Иногда тупит на специфически российских темах — всё-таки китайская модель.

GigaChat

Нейросеть от Сбера. Логично, что работает в России без проблем.

Что умеет:

Лучше всех понимает российский контекст
Генерирует картинки (Kandinsky встроен)
Интеграция с экосистемой Сбера

Как пользоваться: Входишь через Сбер ID — если есть карта Сбера, уже всё готово. Бесплатный тариф покрывает большинство задач.

Минусы: По качеству ответов уступает DeepSeek и тем более GPT-4. Но для базовых задач хватает.

YandexGPT

Доступен через Алису или напрямую в Яндекс Браузере.

Что умеет:

Хорошо работает с русским языком
Интеграция с поиском Яндекса
Умеет в контекст — помнит, о чём говорили

Как пользоваться: Проще всего через Алису — просто спрашиваешь. Или через ya.ru в браузере.

Минусы: Ограничения на бесплатном тарифе. Для серьёзной работы нужна подписка Яндекс Плюс.

Что выбрать

Если нужен универсальный инструмент для работы — DeepSeek. Бесплатный, мощный, без ограничений.

Если важен российский контекст и простота — GigaChat. Вошёл через Сбер ID и работаешь.

Если уже в экосистеме Яндекса — YandexGPT через Алису.

А что с ChatGPT?

Работает через VPN. Оплатить подписку можно через сервисы-посредники, но это лишние заморочки. Если нет специфических задач, которые решает только GPT-4 — проще взять DeepSeek.

Если знаете ещё варианты, которые нормально работают в России — пишите, добавлю в список.

BitPage

Место на диске съели индексы, а не данные: раздувание b-tree, которое autovacuum не лечит

Коротко (TL;DR)

Почему «база распухла» — это два разных диагноза

Autovacuum не сломан, и это самое контринтуитивное

Как измерить раздувание, а не гадать по размеру

Уникальный индекс с нулём обращений — не мёртвый

Грабли при самой перестройке

Два одинаковых индекса под разными именами

Что сделать, по шагам

Итог

Сервер не отвечает, но работает: беззнаковое вычитание в ZFS и systemd CrashAction=freeze

Коротко (TL;DR)

Как выглядит отказ снаружи

Почему это не битая память, хотя выглядит именно так

Четыре ложных следа, и все четыре через одну функцию

Развязка: длина memset — это ровно минус другой регистр

Что сломано в ZFS: инвариант, который не доживает до релизной сборки

В каких версиях баг живёт и куда обновляться

Почему отказ длится часами, а не секундами

Побочная находка: restart-политика, которая переживает аварию, но не переживает ребут

Что сделать сейчас, по шагам

Итог

PHP теряет сессию после апгрейда: звёздочка в имени cookie превращается в %2A

Коротко (TL;DR)

Как это выглядит снаружи

Пять версий, которые оказались мимо

Что на самом деле: две половинки, которые перестали сходиться

Почему это сломал именно security-фикс

В каких версиях PHP баг живёт

Как проверить это у себя за минуту

Чем чинить: четыре варианта

Итог

Patroni игнорирует правки patroni.yml: почему bootstrap.dcs работает один раз и как вернуть Ansible-роли управление кластером

Коротко (TL;DR)

Почему правка patroni.yml ничего не меняет на живом кластере

Какие параметры нельзя забрать из DCS

Как вернуть Ansible-роли статус источника правды

Как shared_buffers: 4G превращается в 128 МБ без единой ошибки

Почему wal_keep_segments из DCS продолжает работать на PostgreSQL 15

Как найти, откуда на самом деле пришло значение параметра

Сколько ставить wal_keep_size: считать, а не наследовать

Две мелкие ловушки Ansible, съевшие полдня

Пошагово

Итог

PostgreSQL conflict with recovery: почему hot_standby_feedback со слотами опасен, а lag= в Patroni мерит не то

Коротко (TL;DR)

Почему hot_standby_feedback при включённых слотах — плохой размен

Почему поднять max_standby_streaming_delay в схеме с балансировщиком хуже, чем ничего не делать

Что на самом деле выбивает реплику: посекундный замер отставания

Почему порог lag= в health-check Patroni нельзя задать в секундах

Сколько реплика отстаёт во времени — и почему метрика мониторинга врёт

Как посчитать длину всплеска по таймингу самого health-check

Почему «конфликты роняют реплику» оказалось совпадением, а не причиной

Что выкачено: убрать ущерб, если нельзя убрать причину

Грабли по дороге: Ansible, ротация логов и ленивое соединение

Пошагово

Итог

Gmail отбивает всю почту: 550-5.7.26 и три сломанные аутентификации разом

Коротко (TL;DR)

Что Gmail требует с 2024 года и почему сервер сломался «сам»

Почему я начал не с того: собственная заметка врала

Что на самом деле значит 550-5.7.25 про PTR

Почему grep по mail.log ничего не доказывает про DKIM

Три настоящих дефекта, которые ничего не исправили

Почему OpenDKIM молчал: file: против refile:

Почему ручной тест проходил, а почта приложений уходила голой

Что чинил по порядку

Что осталось сломанным: bounce rate — шесть писем из десяти

Итог

Как вывезти живой docker-проект с умирающего диска: стрим pg_dump, pull образов, якорный exclude

Коротко (TL;DR)

Почему pg_dump на умирающем диске виснет, а не падает

Стрим дампа: любую запись — с источника долой

Почему EOL-образы нельзя пересобрать, но можно вытянуть

Как rsync-exclude без слэша съел framework

Тест на боевых интеграциях без сайд-эффектов

Пошагово

Итог

CrowdSec на Debian 13: пять граблей, которых нет в туториалах

Развязка: длина `memset` — это ровно минус другой регистр