Issue metadata
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 descriptionUserAgent: 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" } ]
,
Sep 4 2017
@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 |
|||||||||||||||||||||||
Comment 1 by dvallet@chromium.org
, Sep 4 2017Mergedinto: 754576
Status: Duplicate (was: Unconfirmed)