Браузер в Docker падает с SIGBUS: проверяем размер /dev/shm

Скриншотный тест запускает несколько вкладок браузера и иногда завершается с SIGBUS. Контейнеру выделено достаточно обычной памяти, OOMKilled равен false, а повторный запуск проходит. Один из следующих кандидатов — разделяемая память в /dev/shm. Её доступная ёмкость задаётся отдельно от привычного лимита памяти контейнера.

Браузеры и некоторые вычислительные библиотеки используют shared memory для обмена между процессами. Поэтому приложение может упереться в /dev/shm раньше, чем исчерпает общий лимит. По одной строке SIGBUS причину установить нельзя, но измерить заполнение конкретной файловой системы полезнее, чем сразу удваивать все ресурсы контейнера.

Сопоставить симптом с использованием shm

Во время воспроизведения посмотрите df -h /dev/shm внутри контейнера и параметры его создания. Размер в конфигурации должен соответствовать действительно запущенному контейнеру. Для локального Compose-стенда можно явно установить бюджет:

services:
  browser-tests:
    build: .
    shm_size: '512m'

Значение 512m — отправная точка для измерения конкретного тестового набора, а не рекомендуемый размер для любого браузера. Увеличение ёмкости даёт процессам возможность использовать больше shared memory; хосту всё равно нужно иметь ресурсы для этой нагрузки. Если одновременно запускаются десятки контейнеров, проверяйте суммарное потребление и общий запас машины.

После изменения пересоздайте только тестовый сервис и повторно посмотрите df. Обычный restart не меняет параметры создания контейнера. Если /dev/shm стал больше, но падение осталось при низком заполнении, гипотеза не подтвердилась. Продолжайте исследовать стек ошибки, использование mmap и версию браузера, не выдавая настройку за универсальное лечение SIGBUS.

Сохранить одинаковую нагрузку

Для сравнения фиксируйте число параллельных workers, набор страниц и число вкладок. Если одновременно уменьшить параллелизм и увеличить shm, исчезновение ошибки не покажет, какое изменение помогло. Удобно сначала воспроизвести сбой на прежнем размере с записью пика, затем повторить тот же набор на новом.

Некоторые инструкции предлагают отключить использование /dev/shm флагом браузера. Такой обход переносит нагрузку на другие механизмы и может менять скорость. Его стоит оценивать как отдельное решение с измерением, а не скрывать причину в длинном списке аргументов запуска. Явный ресурс в Compose проще увидеть при review и согласовать с мощностью CI runner.

В отчёте тестовой инфраструктуры полезно сохранять не только текст падения, но и параметры памяти контейнера, ёмкость shm и параллелизм. Эти три числа позволяют воспроизвести среду. После исправления тест должен устойчиво проходить тот же сценарий, а ресурсы должны оставаться достаточными для соседних jobs, которые делят машину с браузером.

Продолжить практику

Эту настройку проще понимать в составе приложения, у которого есть сеть, данные и понятная процедура обновления. На курсе «Docker и Docker Compose: контейнеризация приложений» вы упакуете HTTP-сервис с PostgreSQL, разберёте конфигурацию, хранение данных и диагностику сбоев. В программе есть локальные лабораторные, работа с registry и версиями образов; итоговый проект включает передачу окружения другому разработчику и проверку восстановления базы.

Посмотреть программу курса

Источник: официальная документация.

Другие задачи по теме: Процессы, сеть, тома и сборка контейнера.