skip to content

Selenium Manager cannot reach the internet on the locked-down host running your bank statement-download suite. How do you make the run succeed?

level: seniorimportance: should knowfreq 38%

answer

  1. Only one step needs the network
  2. Resolution is local before it is remote
  3. An environment variable can forbid downloads
  4. SE_OFFLINE plus a pre-populated cache
  5. Or configure the executable and skip resolution

basics

~20 s

Give Selenium Manager a driver it already has. Set SE_OFFLINE so it never attempts a download, pre-place the matching driver under the folder named by SE_CACHE_PATH, or configure an explicit driver executable so it is never consulted.

solid answer

~40 s

In Selenium 4, Selenium Manager only downloads when it cannot resolve a driver locally, so the fix is to make local resolution succeed. `SE_OFFLINE=true` (or `--offline` on the binary) forbids every network call, turning a blocked download into an immediate, readable failure instead of a hang. The driver cache defaults to `~/.cache/selenium` and moves with `SE_CACHE_PATH`, so a host that already holds the right driver there resolves in milliseconds. The escape hatch is to bypass resolution altogether: a `ChromeDriverService` built with `usingDriverExecutable(...)`, or the `webdriver.chrome.driver` system property, configures the path before Selenium Manager would ever be asked. Run the bundled binary by hand with `--debug` to see which of those paths the host actually took.

code

bash · 7 lines
bash
# What would Selenium Manager resolve on this host, and why?
./selenium-manager --browser chrome --debug

# The same question with the network forbidden and a relocated cache
export SE_OFFLINE=true
export SE_CACHE_PATH=/opt/selenium-cache
./selenium-manager --browser chrome --debug

go deeper

for a junior

Know that Selenium 4 fetches drivers for you and that the fetch needs a network. Being able to say a machine without internet needs the driver supplied some other way is enough at this stage.

for a middle

Be ready to explain the resolution sequence and name the switches: SE_OFFLINE forbids network calls, SE_CACHE_PATH moves the cache, and an explicitly configured executable skips resolution entirely.

for a senior

An interviewer expects you to diagnose it on the host: run the bundled binary with --debug as the build user, prove whether the cache or the network was used, then choose between a pre-populated cache and an explicitly provisioned driver.

for a principal

Own the policy. Decide whether hosts resolve drivers automatically or receive a provisioned binary, who keeps that binary current, and how the organisation demonstrates that a restricted host made no outbound request during a run.

## Why the locked-down host is the interesting case **Selenium Manager** is a small binary shipped *inside* the Selenium client from **Selenium 4.6** onward. It is not something a team installs, adds to a build file, or upgrades separately; it is already inside the client the bank statement-download suite depends on. When the suite constructs a driver and no driver executable has been configured, the client runs that binary as a short-lived subprocess and asks it one question: what is the absolute path of a driver that can drive the browser installed on this machine? On a laptop with open internet the answer often involves a download and nobody notices it happening. On a hardened build host that download is the one step with no route out, so the suite fails before its first navigation to the statement page — usually surfaced by the client as a `NoSuchDriverException` naming the browser it could not resolve a driver for. It reads like a Selenium bug and is really a provisioning question. ## What Selenium Manager tries, in order 1. **Detect the installed browser** and the version it reports. 2. Work out which **driver build** matches that browser. 3. Look for that driver in the local **driver cache**. 4. **Download** it, but only when the cache holds no matching copy. 5. Print the resolved absolute path back to the client, which starts the driver process. Only step 4 touches the network; everything else is local file and process work. The whole senior answer is therefore: arrange for step 3 to succeed, or skip the sequence entirely. ## The `SE_` overrides that decide the outcome Selenium Manager reads environment variables prefixed `SE_`, each mirroring a flag on the binary itself. | Variable | Binary flag | What it changes | |---|---|---| | `SE_CACHE_PATH` | `--cache-path` | Moves the cache off its default `~/.cache/selenium` | | `SE_OFFLINE` | `--offline` | Forbids every network call; resolution must succeed locally | | `SE_BROWSER_PATH` | `--browser-path` | Names the browser binary instead of discovering it | | `SE_DRIVER_VERSION` | `--driver-version` | Fixes the driver build rather than deriving one | | `SE_BROWSER_VERSION` | `--browser-version` | States the browser version to resolve against | | `SE_AVOID_BROWSER_DOWNLOAD` | `--avoid-browser-download` | Stops it fetching a browser as well as a driver | `SE_OFFLINE` is the switch to reach for first, and not only because it stops a doomed download. It converts a slow, blocked, ambiguous hang into an immediate and readable failure, and it *proves* the run never depended on the network — a claim a security review will ask you to demonstrate rather than assert. ## Making the cache the answer instead of the network - The cache is a **per-user folder**, `~/.cache/selenium` by default, holding drivers under a versioned layout Selenium Manager created itself. - A matching cached driver is reused on every later run, so a warm cache reduces resolution to a file lookup. - `SE_CACHE_PATH` points that folder somewhere the service account can actually write — the usual cause of a "works for me, fails as the build user" report. - The reliable way to produce a valid cache is to let Selenium Manager populate one on a connected machine and copy that folder across, rather than hand-building the directory layout. - A cache missing the needed driver behaves under `SE_OFFLINE` exactly as it should: it fails at resolution time, loudly, rather than halfway through the suite. ## Removing Selenium Manager from the run Sometimes the right answer is that the driver should not be resolved at all — it should be an artefact the machine's own provisioning places. - Build the service with an explicit executable (`ChromeDriverService.Builder().usingDriverExecutable(...)`), or set the `webdriver.chrome.driver` system property; either configures the path before the client would ask Selenium Manager. - With a path configured, nothing is detected, nothing is downloaded, nothing is cached: you have traded convenience for provenance. - The cost is upkeep. That executable is yours to keep current, and the suite hard-fails on a host where the file is absent instead of quietly recovering. - The judgment is environmental. Across a fleet of developer laptops, automatic resolution deletes a whole class of setup tickets; on a host where an unexpected outbound request is a compliance event, an explicit path is cheaper. ## Proving which path the host took The binary can be run by hand, which turns guesswork into evidence: ```bash # What would Selenium Manager resolve here, and why? ./selenium-manager --browser chrome --debug # The same question with downloads forbidden and the cache relocated SE_OFFLINE=true SE_CACHE_PATH=/opt/selenium-cache \ ./selenium-manager --browser chrome --debug ``` `--debug` reports the browser it detected, whether the driver came from the cache or from a download, and the path it settled on. Running it on the failing host, as the build user, answers in seconds what a day of suite-level log reading will not.

  • With SE_OFFLINE set and no matching driver in the cache, what does the run do?
    It fails at resolution, before any browser starts. Selenium Manager will not fall back to a download, so the client reports that it could not locate a driver for the browser. That is the intended behaviour: an immediate, attributable failure beats a blocked network call that eventually times out somewhere inside the suite.
  • Why run the bundled binary by hand instead of reading the suite's own logs?
    The suite reports that a session could not be created; the binary reports why. Run with `--debug` it names the browser it detected, whether the driver came from the cache or a download, and the final path. It also runs as whatever user you invoke it as, which exposes cache-permission problems the suite hides.
  • What do you give up by configuring an explicit driver executable instead?
    Automatic resolution. Nothing detects the browser, nothing downloads, nothing caches, so the driver becomes an artefact somebody must place and keep current on every host. In exchange the run makes no outbound request and its driver provenance is auditable, which is often the point on a restricted machine.

saying these in an interview costs you the question

  • Claims Selenium Manager cannot be influenced or turned off at all
  • Thinks SE_OFFLINE means download once and reuse forever
  • Offers adding the driver to PATH as the only conceivable fix
  • Cannot say where the driver cache lives or how to relocate it
  • Believes an explicitly configured driver path is still overridden by Selenium Manager