New issue
Advanced search Search tips

Issue 761653 link

Starred by 1 user

Issue metadata

Status: Duplicate
Merged: issue 754576
Owner: ----
Closed: Sep 2017
Components:
EstimatedDays: ----
NextAction: ----
OS: Linux
Pri: 2
Type: Bug



Sign in to add a comment

In headless chrome, if --user-data-dir is set, then creating browser context throws lot of errors about user data directory being Locked

Reported by mail.jib...@gmail.com, Sep 3 2017

Issue description

UserAgent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_12_6) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/60.0.3112.113 Safari/537.36

Steps to reproduce the problem:
1. Start chrome headless shell with --user-data-dir set to a proper directory
2. Create a new browser context and a target inside the context. 
3. Everything looks good
4. Create another new browser context and a target inside the context
5. Now chrome headless shell starts throwing a lot of errors saying the user data directory is already locked

What is the expected behavior?
chrome headless shell should properly store the user data information for multiple contexts and it should be available for reloading the contexts if browser cashes.

What went wrong?
rome_1   | CHROME STDERR >>  [0903/041820.752267:ERROR:service_worker_storage.cc(1465)] Failed to open the serviceworker diskcache: net::ERR_ABORTED
chrome_1   | CHROME STDERR >>  [0903/041820.756881:INFO:CONSOLE(0)] "Uncaught (in promise) AbortError: Failed to register a ServiceWorker: Operation has been aborted", source: https://web.whatsapp.com/ (0)
chrome_1   | CHROME STDERR >>  [0903/041826.458966:ERROR:leveldb_database.cc(319)] Failed to open LevelDB database from /opt/container/chrome-user-data/IndexedDB/https_web.whatsapp.com_0.indexeddb.leveldb,IO error: /opt/container/chrome-user-data/IndexedDB/https_web.whatsapp.com_0.indexeddb.leveldb/LOCK: Lock file already locked. (ChromeMethodOnly: 15::LockFile)

Did this work before? No 

Chrome version: 62.0.3200.0  Channel: stable
OS Version: Ubuntu jessie
Flash Version: 

http://localhost:9222/json/version

{
Browser: "HeadlessChrome/62.0.3200.0",
Protocol-Version: "1.2",
User-Agent: "'Mozilla/5.0 (Macintosh; Intel Mac OS X 10_12_5) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/60.0.3112.78 Safari/537.36'",
V8-Version: "6.2.396",
WebKit-Version: "537.36 (@2044a85df703188ab8183a6f8f0fa7970dbf0cb9)",
webSocketDebuggerUrl: "ws://localhost:9222/devtools/browser/999b266e-a943-4c2e-8f15-bcbd9f4e114b"
}

http://localhost:9222/json

[
{
description: "",
devtoolsFrontendUrl: "/devtools/inspector.html?ws=localhost:9222/devtools/page/ed2595bb-2a3f-4d31-8aab-ba0556909083",
id: "ed2595bb-2a3f-4d31-8aab-ba0556909083",
title: "WhatsApp",
type: "page",
url: "https://web.whatsapp.com/",
webSocketDebuggerUrl: "ws://localhost:9222/devtools/page/ed2595bb-2a3f-4d31-8aab-ba0556909083"
},
{
description: "",
devtoolsFrontendUrl: "/devtools/inspector.html?ws=localhost:9222/devtools/page/480e2517-ef64-45b9-84d9-f9159878b7a8",
id: "480e2517-ef64-45b9-84d9-f9159878b7a8",
title: "WhatsApp",
type: "page",
url: "https://web.whatsapp.com/",
webSocketDebuggerUrl: "ws://localhost:9222/devtools/page/480e2517-ef64-45b9-84d9-f9159878b7a8"
},
{
description: "",
devtoolsFrontendUrl: "/devtools/inspector.html?ws=localhost:9222/devtools/page/6db93334-692b-4ba0-94b4-b2eca39ea030",
id: "6db93334-692b-4ba0-94b4-b2eca39ea030",
title: "about:blank",
type: "page",
url: "about:blank",
webSocketDebuggerUrl: "ws://localhost:9222/devtools/page/6db93334-692b-4ba0-94b4-b2eca39ea030"
}
]
 
Components: -Platform>DevTools Internals>Headless
Mergedinto: 754576
Status: Duplicate (was: Unconfirmed)
Thanks for the report, I'm going to merge it with https://bugs.chromium.org/p/chromium/issues/detail?id=754576 since it looks like is the same problem regarding browser context isolation
@dvallet@chromium.org unfortunately they are not the same issue. For me isolation works, and even for cookies. So for me i cannot reproduce https://bugs.chromium.org/p/chromium/issues/detail?id=754576 at all.

The issue reported here, is not that session isolation doesn't work, but that setting a `--user-data-dir` does not work together with session isolation.

What i can guess from the errors is that when user data directory is set, the first browser context locks the directory, and subsequent browser contexts throw errors as it cannot use the user data directory as it is already being locked.

Sign in to add a comment