skip to content

In Selenoid (unmaintained), what must be true before a session's log file is saved?

level: middleimportance: should knowfreq 57%

answer

  1. one side asks, the other side allows
  2. a server flag and a request key
  3. no directory, no file
  4. the operator can decide for everyone
  5. renaming is not the same as enabling

basics

~20 s

Two conditions, not one. Selenoid, unmaintained by its own README, must have been started with a log output directory, and the session must have asked with its log capability, unless the operator switched capture on for every session.

solid answer

~40 s

Selenoid, unmaintained by its own README, gates log capture on a conjunction: the server must have been started with `-log-output-dir`, **and** either the operator passed `-save-all-logs` **or** the session asked with `enableLog`. Both halves are required, and they belong to different people. The directory is the operator's decision and cannot be set from a capability; the per-session request is the tenant's. Miss the flag and a session that sets `enableLog` gets no file and no error, because the condition simply evaluates false and the request proceeds normally. `-save-all-logs` inverts the relationship by making the capability irrelevant: every session is captured whether it asked or not. The separate `logName` capability only replaces the default `<session-id>.log` file name; it never switches capture on by itself. Selenoid also accepts both keys from inside its own `selenoid:options` map.

code

json · 12 lines
json
{
  "capabilities": {
    "alwaysMatch": {
      "browserName": "chrome",
      "selenoid:options": {
        "enableLog": true,
        "logName": "container-tracking-shipment-status.log",
        "name": "port logistics dashboard smoke"
      }
    }
  }
}

go deeper

for a junior

Know that asking for a log in your capabilities is a request, not a guarantee, and that the server has to have been set up to honour it before anything is written.

for a middle

Be ready to state both halves of the condition and say which person owns each. Interviewers at this level want the mechanics, not the recipe.

for a senior

Be ready to explain why the failure is silent and how you would prove which half is missing without access to the server's start-up arguments.

for a principal

Decide whether your estate captures by default or by request, and who carries the consequence: capture-everything buys evidence and spends disk on runs nobody will read.

Log capture on a session-container grid is not one switch. It is a conjunction of a server-side decision and a per-session request, and almost every confused report about "the logs are not there" comes from someone holding only one half of it. ## The condition, stated exactly Aerokube's Selenoid, which its own README declares unmaintained and which is read here as an open model of a mechanism that hosted services implement privately, saves a session's log only when **both** of the following hold: - The server was started with `-log-output-dir <dir>`. Without it, no per-session log file is written at all. - Either the server was started with `-save-all-logs`, or the session's capabilities carried `enableLog` set to true. The first condition is the operator's. Selenoid exposes no capability that names the output directory, and a client has no way to create one. The second condition is shared: `-save-all-logs`, documented as saving all logs "without considering capabilities", lets the operator decide on behalf of every tenant, while `enableLog` lets a tenant opt an individual session in. ## Why a missing flag is silent This is the part that costs an afternoon. When the directory is not configured, the condition evaluates false and the session proceeds normally. The browser starts, the test runs, the session closes, and nothing is written. There is no rejected capability, no warning in the reply, and no error for the client to catch: Selenoid simply does not act on the request. The practical consequence is that **you cannot infer capture from the request**. A suite that sets `enableLog` and then asserts a file exists is asserting something about the server's start-up arguments, which it cannot see. The only sound check is to fetch the artefact and treat its absence as a configuration finding rather than a test failure. ## Who owns which half | the decision | who makes it | how | |---|---|---| | whether logs can be saved at all | the operator | `-log-output-dir` at start-up | | whether every session is captured | the operator | `-save-all-logs` at start-up | | whether this session is captured | the tenant | `enableLog` in the request | | what this session's file is called | the tenant | `logName` in the request | That split is the whole shape of a rented fleet in miniature. The tenant asks; the operator decides whether asking means anything. On a hosted provider you cannot read the start-up arguments at all, so the same asymmetry exists with the server side simply invisible. ## Naming, and what naming does not do `logName` replaces the default file name, which is otherwise the session identifier with a `.log` extension. It is a naming control and nothing more. What it does not do is enable anything: a session that sets `logName` without `enableLog`, on a server without `-save-all-logs`, produces no file with a nice name; it produces no file. Selenoid's documentation warns that the value should carry the `.log` extension, and its retrieval path explains why. The download branch of `/logs/` serves only names ending in `.log`; a file named without that suffix still lands in the directory and still appears in the listing, but a request for it by name is not treated as a file request at all. ## Passing the capability Selenoid reads these as ordinary top-level capabilities or from inside its own `selenoid:options` map, merging the nested map over the top-level one so the namespaced spelling wins where both are present. The namespaced form is the one a W3C-strict client will carry, because the specification requires an extension capability's key to contain a colon. ## Two flags that cannot be combined There is a configuration that Selenoid refuses outright. When it runs without Docker, driving browser drivers as local processes, passing both `-capture-driver-logs` and `-log-output-dir` is fatal at start-up: the first sends driver output to the server's own output, the second wants it in a per-session file, and the two destinations are mutually exclusive for the same stream. The server logs an initialisation failure and exits rather than silently picking one. ## What to check when a log is missing 1. Confirm the server was started with an output directory. If you operate the fleet, read the process arguments; if you do not, fetch the listing and see whether it answers at all. 2. Confirm the session asked, or that the operator captures everything. A suite that sets the capability only on retries will have nothing for the first attempt. 3. Confirm the name you are asking for. If the session set a custom name, the file is under that name, not under the session identifier. 4. Confirm the session actually ended. The saved file is finalised at session close, so a run that is still open, or one still being held open by an idle timeout, has nothing to download yet.

  • What does -save-all-logs change for a tenant that never sets the capability?
    Everything and nothing. Capture happens for that tenant's sessions whether or not they asked, so artefacts appear that the suite did not request and may not expect. The tenant gains evidence it did not plan for and loses the ability to opt a session out, because the flag is documented as saving all logs without considering capabilities.
  • Your suite sets enableLog and the file is missing. How do you tell a server misconfiguration from a test-side bug?
    Separate the two halves. Fetch the listing for the whole directory: if it does not answer at all, the server has no output directory configured and no test-side change can fix it. If it answers but your file is absent, check the name the session asked for and whether the session actually closed, since the file is finalised at session end.

saying these in an interview costs you the question

  • Thinks the log capability alone makes the server save a file
  • Expects an error when the server ignores the request
  • Confuses naming the file with switching capture on
  • Assumes every deployment of a grid saves session logs
  • Believes a client can choose the server's output directory