Что на самом деле копирует fork() — и почему ваш пул соединений ломается

Все воркеры Celery одновременно перестали получать соединения с базой. Ни один. Ни ошибок подключения, ни таймаутов запросов — просто тишина. Метрики пула показывали норму. Инфраструктура была в порядке. Но каждая задача падала через 20 секунд с одним и тем же сообщением:

			PoolTimeout: couldn't get a connection after 20.00 sec
		

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

Ключевые выводы:
— fork() копирует память процесса (copy-on-write), но разделяет файловые дескрипторы с ядром
— TCP-сокеты после fork() указывают на один и тот же объект ядра — два процесса пишут в один поток
— threading.Lock ломается: futex-ключ привязан к физическому адресу памяти, который меняется при copy-on-write
— Фоновые потоки пула просто не существуют в дочернем процессе — fork() копирует только вызывающий поток
— Правило: никогда не держите открытые соединения перед fork()

Инцидент — что случилось

За несколько дней до инцидента в конфигурации изменился один флаг. Нужно было, чтобы обработчики сигналов Django регистрировались внутри воркеров Celery. Существующая настройка пропускала регистрацию, если флаг не был установлен в true.

Флаг установили. Сигналы заработали. Фича уехала в прод.

QA был быстрым. Изменение выглядело изолированным: переключить флаг, убедиться, что сигналы регистрируются в Celery, готово. Никто не искал побочных эффектов, спрятанных в AppConfig.ready().

А потом тихо начало выполняться кое-что ещё. Несколько методов AppConfig.ready(), которые теперь стали активны, делали ORM-запросы при старте: создавали расписания периодических задач, проверяли записи crontab. Рутинные вещи. Ничего опасного на вид.

Но эти запросы открыли пул соединений с базой данных. В мастер-процессе. До fork().

Модель конкурентности Celery по умолчанию — prefork. Не потоки, не async-воркеры. Celery использует fork() — системный вызов POSIX — для создания пула рабочих процессов. Эту деталь легко забыть, когда смотришь на код приложения. Но она становится критически важной, когда открываешь соединения с базой при старте.

В этом и была проблема.

Что копирует fork()

Большинство разработчиков знают поверхностный ответ: fork() создаёт дочерний процесс, который является копией родительского. Но слово «копия» скрывает важное различие, которое ядро проводит между двумя типами ресурсов.

Память — copy-on-write

Когда fork() выполняется, ядро не дублирует RAM немедленно. Вместо этого оно помечает таблицы страниц обоих процессов как read-only, указывая на одни и те же физические страницы. Фактическое копирование происходит только когда один из процессов пишет в страницу: ядро перехватывает page fault, выделяет новую физическую страницу, копирует содержимое и обновляет таблицу страниц. До этого момента оба процесса разделяют физическую память, не зная об этом.

Это эффективно. И именно поэтому Python-объекты, включая внутреннее состояние пула соединений, выглядят целыми в дочернем процессе. Дочерний процесс получает свою копию pool._pool, pool._lock, pool._sched. Байты на месте. Структура на месте.

Но некоторые из этих байтов указывают на ресурсы ядра. А ресурсы ядра не копируются.

Файловые дескрипторы — общие

TCP-сокет — это не Python-объект. Это объект ядра: struct file со счётчиком ссылок, за которым стоит struct sock с буферами отправки и получения, состоянием TCP, sequence numbers. Когда fork() выполняется, ядро вызывает dup_fd() для таблицы файловых дескрипторов родителя: каждый открытый fd дублируется в дочерний процесс, а счётчик ссылок на struct file увеличивается.

Оба процесса теперь держат fd=12. Оба указывают на один и тот же объект сокета в ядре. Один TCP-поток, два читателя и два писателя — без координации между ними.

			Parent  fd=12 ──────┐
                    ├──► TCP socket (kernel) ──► PostgreSQL
Child   fd=12 ──────┘
		

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

Блокировки — сломанный futex

threading.Lock построен на pthread_mutex_t, который внутри опирается на futex — механизм ядра Linux, использующий физический адрес памяти целого числа как ключ для очереди ожидания. После fork() copy-on-write может переместить страницу дочернего процесса на новый физический адрес при записи. Futex-ключ дочернего процесса расходится с родительским. futex_wake из одного процесса не будит никого в другом.

POSIX явно говорит об этом: поведение мьютекса после fork() не определено, если он не был создан с атрибутом process-shared. Python-овский Lock этот атрибут не использует.

Фоновые потоки — просто не существуют

fork() дублирует только вызывающий поток. Внутренний планировщик пула — отвечающий за поддержание минимального числа соединений, проверки здоровья, уведомление ожидающих — копируется как Python-объект, но не имеет соответствующего потока ОС. Его TID не существует. Любой путь кода, который зависит от его ожидания или сигнализации, заблокируется навсегда.

Дочерние процессы унаследовали пул, который выглядел целым, но был мёртв. Они вызывали pool.getconn(), пытались захватить сломанный лок, ждали 20 секунд notify, который никогда не придёт, и получали таймаут.

Почему пул соединений ломается после fork()

Пул соединений psycopg (ConnectionPool) хранит три вида ресурсов. Каждый ломается по-своему после fork().

TCP-сокеты разделяются на уровне ядра. Любая попытка использовать их из двух процессов одновременно разрушает поток протокола. На практике дочерние процессы до этого даже не доходили.

threading.Lock опирается на futex, привязанный к физическому адресу. После copy-on-write ключ дрейфует. futex_wake будит очередь по старому адресу — никого в дочернем процессе там нет.

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

Вот почему раньше всё работало:

			До:     fork() → чистый дочерний процесс → первый запрос → свежий пул (корректно)
После:  пул открывается → fork() → сломанный дочерний процесс → PoolTimeout
		

До изменения флага AppConfig.ready() пропускал регистрацию периодических задач. ORM не вызывался при старте. Нет запросов — нет пула. Нет пула — нечего наследовать. Каждый дочерний процесс начинал с чистого состояния и лениво создавал собственный пул при первом обращении к базе: собственные сокеты, собственный лок, собственный фоновый поток.

Решение — чистый fork без наследства

Два хука сигналов Celery.

worker_before_create_process срабатывает в родительском процессе после ready(), перед каждым fork(). Он закрывает все соединения с базой по всем алиасам и уничтожает пулы соединений. К моменту выполнения fork() нет открытых TCP-сокетов, нет локов, нет фоновых потоков для наследования.

worker_process_init срабатывает в каждом дочернем процессе после fork() как второй уровень защиты — defense-in-depth, на случай если что-то было пропущено.

После обоих хуков каждый дочерний процесс пуст. Первый ORM-запрос создаёт свежий пул, который целиком принадлежит этому процессу.

			ready() выполняется → пул открывается → worker_before_create_process → пул уничтожен
           → fork() → worker_process_init → первый запрос → свежий пул
		

Принцип простой: никогда не держите открытые соединения перед fork() — или явно закройте и уничтожьте их до форка. Это правило применимо к любому пулу соединений на основе TCP: psycopg, SQLAlchemy, redis-py. Технология не важна. Важно поведение ядра.

Диаграммы — до и после

До изменения флага: чистый fork, каждый воркер создаёт свой пул

			MASTER PROCESS
==============

  AppConfig.ready()
    - signal listeners: SKIPPED
    - ORM queries:      SKIPPED
    - pool state:       never opened

  +----------------------------------+
  |  pool._pool  = []  (empty)       |
  |  pool._lock  = None              |
  |  pool._sched = None              |
  |  open TCP fds: none              |
  +----------------------------------+
              |
           fork() x4
              |
    +---------+---------+---------+
    |         |         |         |
    v         v         v         v
 Worker-1  Worker-2  Worker-3  Worker-4
 (clean)   (clean)   (clean)   (clean)
    |         |         |         |
    v         v         v         v
 1st ORM   1st ORM   1st ORM   1st ORM
 query     query     query     query
    |         |         |         |
    v         v         v         v
 owns its  owns its  owns its  owns its
 own pool  own pool  own pool  own pool
 own fds   own fds   own fds   own fds
 own lock  own lock  own lock  own lock
 own thread own thread own thread own thread

 Each worker is fully independent. No sharing. Works correctly.
		

После изменения флага: пул открыт в мастере, fork() распространяет повреждение

			MASTER PROCESS
==============

  AppConfig.ready()
    - signal listeners: REGISTERED
    - ORM queries:      RUN  <-- pool forced open here
    - pool state:       open, 4 connections

  +------------------------------------------+
  |  pool._pool  = [conn-A, conn-B,           |
  |                 conn-C, conn-D]            |
  |  pool._lock  = Lock()  (initialized)      |
  |  pool._sched = Thread  (alive, TID=1002)  |
  |  fd=12, fd=13, fd=14, fd=15 open          |
  +------------------------------------------+
              |
           fork() x4   <-- copies memory, shares kernel fds
              |
    +---------+---------+---------+---------+
    |         |         |         |         |
    v         v         v         v         v
  Master   Worker-1  Worker-2  Worker-3  Worker-4

  All 4 workers inherit:

  pool._pool  = [conn-A, conn-B, conn-C, conn-D]  (CoW copy)
  pool._lock  = Lock() -- bytes copied, futex key broken
  pool._sched = Thread -- object exists, OS thread does not
  fd=12..15   = pointing at SAME kernel TCP sockets

              |
              |  task arrives, worker calls pool.getconn()
              v

  Worker-1: acquire pool._lock
    --> lock state undefined (futex broken after CoW)
    --> OR: lock acquired, waits for _sched.notify()
    --> _sched thread doesn't exist in this process
    --> nobody calls _cond.notify()
    --> wait 20 seconds
    --> PoolTimeout

  Same result in Worker-2, Worker-3, Worker-4.
  All workers fail. No tasks execute.


  Meanwhile, if any worker DID reach a connection:

  Worker-1  fd=12 ──┐
                    ├──► SAME TCP socket ──► PostgreSQL
  Worker-2  fd=12 ──┘

  Both writing on the same stream.
  PostgreSQL receives interleaved bytes from two workers.
  Wire protocol corrupted.
		

После исправления: пул уничтожен перед fork(), каждый воркер стартует чисто

			MASTER PROCESS
==============

  AppConfig.ready()
    - signal listeners: REGISTERED  (intended behavior preserved)
    - ORM queries:      RUN          (pool opens here)
    - pool state:       open

          |
          v

  worker_before_create_process()   <-- fires before each fork()
    - close all DB connections
    - destroy pool (close_pool())
    - join pool._sched thread

  +----------------------------------+
  |  pool._pool  = []  (destroyed)   |
  |  pool._lock  = None              |
  |  pool._sched = None              |
  |  open TCP fds: none              |
  +----------------------------------+
              |
           fork() x4   <-- nothing harmful to inherit
              |
    +---------+---------+---------+---------+
    |         |         |         |         |
    v         v         v         v         v
  Master   Worker-1  Worker-2  Worker-3  Worker-4

  Each worker runs worker_process_init()   <-- defense-in-depth
    - closes any remaining inherited state

              |
              v

  Each worker: 1st ORM query --> creates its own fresh pool
               own TCP fds, own lock, own background thread
               fully isolated

  Signal listeners still registered. Feature still works.
  Workers fully independent. No PoolTimeout.
		

Выводы

Настоящий урок — не в конкретном фиксе. Он в понимании того, почему пул сломался. Что fork() на самом деле копирует. Что он разделяет. Почему лок, который выглядит целым, может заблокировать дочерний процесс. Почему поток, существующий как Python-объект, может полностью отсутствовать в ОС.

Правила, которые стоит запомнить:

• Никогда не открывайте пул соединений до fork() — или явно уничтожьте его перед форком
• fork() копирует память (лениво), но разделяет файловые дескрипторы на уровне ядра
• threading.Lock после fork() — undefined behavior: futex привязан к физическому адресу, который дрейфует при copy-on-write
• Фоновые потоки не дублируются — fork() копирует только вызывающий поток
• Это правило касается любого пула TCP-соединений: psycopg, SQLAlchemy, redis-py — поведение ядра одинаково

Невидимая часть — это взаимодействие между последовательностью запуска Django и моделью процессов Celery. Две системы, каждая из которых хорошо понятна по отдельности, делают неожиданное на стыке.

Адаптированный перевод статьи What fork() Actually Copies Даниэля Бастоса (Daniel Bastos).