Updated: 2020-10-10

• Firefox multi-process in Docker containers
  • Introduction
  • Using multi-process in containers
    • What causes crashing
    • How to set shared memory size
      • Setting shared memory size from command line
      • Setting shared memory size in docker-compose files
      • Setting default shared memory size on Linux
      • Setting default shared memory size on Windows
  • Swapping process modes in releases since June 2020
    • Releases till Firefox 76.0.1
    • Releases since Firefox 77.0.1
    • Releases since Firefox 81.0
  • Hints about how to check
    • How to check multi-process in Firefox
    • How to check shared memory size in containers

Firefox multi-process (also known as Electrolysis or just E10S) can cause heavy crashing in Docker containers (Gah. Your tab just crashed.).

In Firefox versions till 67.0.4 it was possible to disable multi-process by setting the Firefox preferences browser.tabs.remote.autostart and browser.tabs.remote.autostart.2 to false.

Mozilla has removed this possibility in Firefox 68.0. Since than it could be done only by setting the environment variable MOZ_FORCE_DISABLE_E10S to some non-empty value.

However, disabling multi-process in Firefox 77.0.1 caused ugly scrambling of almost all web pages, because they were not decompressed.

Mozilla has fixed the problem in the next release, but they warned about not supporting the MOZ_FORCE_DISABLE_E10S switch in future. Indeed, by Firefox 81.0 I've noticed, that the environment variable has no effect any more.

Considering that Mozilla plans to stop supporting the MOZ_FORCE_DISABLE_E10S switch completely, there is no way around multi-process any more. The trick is to solve the stability problem.

It seems, that the heavy crashing of Firefox tabs in containers is caused by setting the shared memory size (/dev/shm) too low. Indeed, Docker sets it to only 64MB by default.

According my testing, setting the shared memory size to 256MB or more solves the problem. The optimal value will probably vary in different environments, but the default value seems to be definitely too low.

The shared memory size must be set before containers are created.

Actually, that is not completely true. There is also one scenario, when /dev/shm is mounted to an external volume, which could be then resized ad-hoc, but we'll not discuss that case here.

If a container is created from the Docker command line, then the parameter --shm-size should be used.

For example, the following container will have its shared memory size set to 256MB:

docker run -d -P --shm-size=256m accetto/xubuntu-vnc-firefox

If containers are created by docker-compose files, then there are two possible cases.

If the docker-compose file does not build the image, then the parameter shm_size should be used at the service level.

For example, the containers of the following browser service will have their shared memory size set to 256MB:

services:
    browser:
        image: accetto/xubuntu-vnc-firefox
        shm_size: '256m'

If the docker-compose file would also build the image, then the parameter shm_size would be part of build. For example:

services:
    browser:
        build:
            context: .
            shm_size: '256m'

If you use Linux, then the parameter default-shm-size should be put into the file /etc/docker/daemon.json:

{
  "default-shm-size": "256m"
}

After modifying the file you have to restart the Docker service:

sudo systemctl restart docker

If you use Docker for Desktop on Windows, then the parameter default-shm-size would be part of Docker Engine settings:

{
  "registry-mirrors": [],
  "insecure-registries": [],
  "debug": true,
  "experimental": false,
  "default-shm-size": "256m"
}

Previous image releases till Firefox 76.0.1 have forced single-process by default.

The images tagged latest and default had set the variable MOZ_FORCE_DISABLE_E10S to 1 by using the build argument ARG_MOZ_FORCE_DISABLE_E10S.

Note that any non-empty value actually worked, so the following settings both had the same effect:

MOZ_FORCE_DISABLE_E10S=1
MOZ_FORCE_DISABLE_E10S=0

Building an image without the build argument ARG_MOZ_FORCE_DISABLE_E10S enabled the Firefox multi-process feature.

There was always also an image tagged multiprocess, which was built that way.

In images containing Firefox 77.0.1 and newer the process modes have been swapped.

The images tagged latest and default used multi-process and therefore they require larger shared memory then the default 64MB set by Docker.

For some time I've maintained also singleprocess images intended for scenarios, where increasing the shared memory size is not possible or not wanted.

By Firefox 81.0 I've noticed, that the environment variable MOZ_FORCE_DISABLE_E10S has no effect any more. Since then all images run Firefox in multi-process mode and there are no singleprocess images.

To check whether the Firefox multi-process is enabled or disabled, navigate the web browser to the following URL:

about:support

To check the shared memory size, execute the following line in terminal:

df -h /dev/shm