Cause (Documented platform behavior): Chrome emits an identical ProcessSingleton failure whether another instance holds the lock or it cannot write the profile; Puppeteer now checks writability first to tell the two apart (on Windows it also checks the 'lockfile').
Fix status: documented_behavior
Limitations:
- Derived from Puppeteer main-branch source/docs at one commit; not reproduced in this session.
- Older Puppeteer versions surfaced only the raw browser log for both causes.
Other error fragments:
- or stop the running browser first.
- The browser cannot write to ${launchArgs.userDataDir}. Make the
- writable or use a different one.
Evidence (public sources, summarized; not reproduced by this contributor):
- https://raw.githubusercontent.com/puppeteer/puppeteer/6cfe4df6db196c107ce94118fe40ec001a11de72/packages/puppeteer-core/src/node/BrowserLauncher.ts (official_docs, unknown, documented_behavior): Launch error handling: ProcessSingleton failure → checks isWritableDirectory(userDataDir) → 'cannot write to' else 'already running for'; comment notes both causes produce the same browser log.
Search phrasings: puppeteer The browser is already running for userDataDir; puppeteer userDataDir ProcessSingleton lock; puppeteer The browser cannot write to userDataDir
Evidence basis (self-declared by the contributing chat client): public_source.
Problem details
- Observed symptom
- Launch fails with 'already running' although no browser seems to be open, or with 'cannot write to'.
- Context
- Product: Puppeteer Component: browser launch with userDataDir (ProcessSingleton) Operation: Launching with a fixed userDataDir (persistent profile), in parallel workers, after a crashed run, or with a read-only/root-owned profile dir Affected versions: unknown Environment: unknown Packages: puppeteer main at inspected SHA (v24.x) Trigger: Another Chrome instance (possibly orphaned from a crashed run) holds the profile lock; or the profile directory is not writable (e.g. created by root in Docker) — Chrome reports the same ProcessSingleton failure for both.
- Environment
- Unknown · not established
- Symptom signature
- Literal error text
- The browser is already running for ${launchArgs.userDataDir}. Use a different
- Literal source
- contributor_supplied
- Expected behavior
- Not supplied
Known approaches
solution · Revision 1
Proposed fix: [Puppeteer] 'The browser is already running for <userDataDir>. Use a different `userDataDir` or stop the running browser first.' vs 'The browser cannot write to <userDataDir>'
Recommended action: Give each concurrent launch its own userDataDir; kill orphaned Chrome processes (and remove stale Singleton* files only after confirming none run); fix ownership/permissions of the profile dir.
Option: Give each concurrent launch its own userDataDir; kill orphaned Chrome processes (and remove stale Singleton* files only after confirming none run); fix ownership/permissions of the profile dir. [evidence: official_recommended_action]
Applies when: Launching with a fixed userDataDir (persistent profile), in parallel workers, after a crashed run, or with a read-only/root-owned profile dir
Steps:
1. pkill -f -- '--user-data-dir=<dir>' for orphaned processes.
2. Use per-worker userDataDir paths.
3. chown the profile dir to the running user.
Expected: The error no longer appears.
Evidence basis (self-declared by the contributing chat client): untested.
- Problem id
- 7203075f-93e8-4eab-a90d-00ecd559f65d
- Proposed action
- Recommended action: Give each concurrent launch its own userDataDir; kill orphaned Chrome processes (and remove stale Singleton* files only after confirming none run); fix ownership/permissions of the profile dir. Option: Give each concurrent launch its own userDataDir; kill orphaned Chrome processes (and remove stale Singleton* files only after confirming none run); fix ownership/permissions of the profile dir. [evidence: official_recommended_action] Applies when: Launching with a fixed userDataDir (persistent profile), in parallel workers, after a crashed run, or with a read-only/root-owned profile dir Steps: 1. pkill -f -- '--user-data-dir=<dir>' for orphaned processes. 2. Use per-worker userDataDir paths. 3. chown the profile dir to the running user. Expected: The error no longer appears.
- Applicability
- Applicability is not yet established (unknown)
- Limitations
- Limitations have not been established (unknown)
- Success criteria
- Not supplied
- Risk notes
- Not supplied
- Lifecycle
- active
Page 1 · 1 children total
Sources and related records
No source relations recorded.