skip to content

Toolchain Seams

3 roadmaps6 questions

The two places a browser suite meets other tooling: the runner hooks that open and close a driver, and the pipeline environment the same suite has to survive.

on this pageshow

explore

questions

6

In Selenium, what do the Chrome arguments --no-sandbox and --disable-dev-shm-usage do on a CI container?

level: juniorimportance: should knowfreq 55%

answer

  1. Browser switches, not Selenium settings
  2. One is about process isolation
  3. One is about shared memory
  4. Will not start versus crashes later
  5. Both work around a constrained container

basics

~20 s

Both are Chromium switches Selenium passes to the browser. The first turns off Chrome's process sandbox so it can start in a container without the needed kernel privileges. The second moves shared memory off a small /dev/shm.

solid answer

~40 s

They are browser command-line switches, not Selenium settings; Selenium forwards them when the session starts. `--no-sandbox` disables Chrome's renderer sandbox, which needs kernel privileges a locked-down CI container often withholds — without the flag the browser refuses to start at all. `--disable-dev-shm-usage` makes Chrome write its shared-memory files to an ordinary temporary directory instead of `/dev/shm`, because container runtimes usually mount a small one and renderer processes crash part-way through a run when it fills. Both are workarounds for a constrained container, and both have a proper fix outside Selenium: grant the privileges, or enlarge the shared-memory mount. Add them where the driver is built, not in individual tests.

code

java · 10 lines
java
ChromeOptions options = new ChromeOptions();
options.addArguments(
    "--no-sandbox",
    "--disable-dev-shm-usage",
    "--window-size=1600,1200");

WebDriver driver = new ChromeDriver(options);
driver.get("https://irrigation.example.internal/schedule");
System.out.println(driver.getTitle());
driver.quit();

go deeper

for a junior

Recognise both arguments and be able to say, in one sentence each, what they turn off and why a container needs them. Know that Selenium passes them straight to the browser.

for a middle

Explain the mechanism behind each: which kernel privileges the sandbox wants, and what fills up in a small shared-memory mount. Say what the non-Selenium fix would be for both.

for a senior

Show that you distinguish the symptoms in a real pipeline log and that you would remove a flag once the container it worked around is fixed, rather than carrying it forever.

for a principal

Own the standard: which browser arguments every pipeline gets, why each is on the list, who may add one, and how the security trade of disabling the sandbox is scoped to disposable agents only.

## The two arguments, one at a time Both are **Chromium command-line switches**. Selenium does not interpret them; it forwards them to the browser process when the session starts, which is why they read the same whether you are running locally or on a build agent. `--no-sandbox` turns off Chrome's sandbox, the mechanism that confines each renderer process so a compromised web page cannot reach the rest of the machine. Chrome's sandbox needs privileges from the kernel, and a locked-down CI container often does not grant them. Without the privileges Chrome refuses to start at all; with the flag it starts, minus that isolation layer. `--disable-dev-shm-usage` changes where Chrome puts its shared-memory files. By default they go in `/dev/shm`, the shared-memory filesystem. Container runtimes commonly mount a small `/dev/shm`, and when it fills, Chrome's renderer processes die mid-test — which surfaces as tabs crashing, sessions dying, and a suite that fails differently on every run. The flag tells Chrome to use an ordinary temporary directory on disk instead, which is slower but does not run out. ## Why they show up together in CI They travel as a pair because they answer the same question — *what does this container refuse to give the browser?* — from two directions. | | `--no-sandbox` | `--disable-dev-shm-usage` | |---|---|---| | What it turns off | the renderer sandbox | use of `/dev/shm` for shared memory | | Symptom without it | the browser will not start | renderers crash part-way through a run | | What it trades away | process isolation | some speed | | The alternative fix | grant the container the privileges | give the container a bigger `/dev/shm` | | Where the fix lives | the container platform | the container platform | The right-hand column of that table matters: both flags are **workarounds for a container that is too small or too restricted**, and both have a proper fix that lives outside Selenium, in whatever runs the container. Selenium's own browser images ask for a larger shared-memory mount at run time for exactly this reason. ## Passing them from a Selenium suite They are added as browser arguments on the options object, alongside anything else the job needs: - Set them where the driver is built, not in individual tests. - Keep them together with the other CI-only arguments so it is obvious they are environmental. - Do not scatter copies through page objects or fixtures; one factory, one list. Concretely, the nightly suite for a farm irrigation-schedule panel builds one `ChromeOptions`, adds the container flags and the window size, and every session inherits them. ## Where people go wrong 1. **Adding `--no-sandbox` everywhere, including local development.** On a disposable CI container running your own application it is a defensible trade. On a laptop that also browses the web it removes a real security boundary for no benefit, since the laptop's kernel grants Chrome what it needs anyway. 2. **Treating `--disable-dev-shm-usage` as a performance flag.** It is not. It moves shared memory from a memory-backed filesystem to disk, which is the slower option; you accept that because crashing is worse. 3. **Copying a whole block of flags from an internet answer.** Each argument should be there because a symptom made it necessary. A list nobody can explain is a list nobody can safely shorten later. 4. **Assuming these fix flaky tests generally.** They fix two specific environment problems. A wait that is racing, or a viewport that is the wrong width, is untouched by either of them. ## How to tell which one you actually needed The symptoms are distinguishable, and it is worth learning them rather than pasting both by reflex: - If the **session never opens** — the browser process exits immediately and no page is ever loaded — that is the sandbox. - If the session opens, some tests pass, and then the browser **dies part-way through a longer run**, especially one with several tabs or heavy pages, that is shared memory. - If the session opens and the page loads but the *layout* is wrong, neither flag is involved; look at the window size instead. Knowing which flag answered which symptom is what lets you remove one later, when the container it was working around has been fixed.

  • If both flags are workarounds, what are the proper fixes?
    Give the container the kernel privileges Chrome's sandbox needs so the sandbox can stay on, and mount a larger shared-memory filesystem so `/dev/shm` does not fill. Both levers belong to whoever configures the container, not to the Selenium suite. Selenium's own browser images ask for a larger shared-memory mount for exactly this reason.
  • How would you tell which of the two flags a failing job actually needed?
    Look at when it fails. A browser that exits immediately and never loads a page points at the sandbox. A session that opens, passes a few tests and then dies part-way through a longer run points at shared memory. A session that runs fine but renders the wrong layout points at neither.

saying these in an interview costs you the question

  • Calls them Selenium options rather than browser switches
  • Adds --no-sandbox on a laptop that browses the web
  • Thinks --disable-dev-shm-usage makes the browser faster
  • Pastes a whole flag block nobody on the team can explain
  • Expects these flags to fix timing-related test flakiness
open as a page

In a Selenium test class, why is the WebDriver started in the runner's setup hook rather than inside each test method?

level: juniorimportance: should knowfreq 64%

basics

~20 s

The setup hook runs automatically before every test, so each test gets a ready browser session without repeating the start-up code, and the matching teardown hook still runs after a test that failed part-way, closing the browser.

open as a page

In Selenium, why can a page render narrower under headless on a build agent than on a developer's machine?

level: middleimportance: should knowfreq 62%

basics

~20 s

Headless has no desktop to size itself against, so the browser opens at its own small fixed default window rather than at monitor size. Responsive breakpoints then fire and the page lays out as if on a small screen.

open as a page

In a Selenium suite, what breaks when the WebDriver is created in a per-test setup hook but quit in a class-level teardown hook?

level: middleimportance: should knowfreq 48%

basics

~20 s

Every test after the first orphans a browser session. The class-level teardown quits only the last driver the field still holds, so the earlier sessions stay alive, holding browser processes and Grid slots until something else reaps them.

open as a page

In Selenium 4, how would you decide between Selenium Manager resolving a driver per CI job and a pinned driver baked into the image?

level: principalimportance: should knowfreq 38%

basics

~20 s

Decide by what the job must guarantee. Selenium Manager resolves and downloads a matching driver at run time, which is convenient but depends on the network. A driver baked into the image and pinned makes the job repeatable offline.

open as a page

A Selenium suite's failure listener finds a dead session when it tries to capture evidence — why, and where must that listener sit?

level: seniorimportance: nice to knowfreq 34%

basics

~20 s

Because the teardown hook already called quit, which deletes the session. Any command after that throws, so the capture step has to run before the quit, against the driver instance the failing test was actually using.

open as a page