You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
refactor(linux): audit cef.Initialize defaults; drop dead switches and stale workarounds
- Drop dead/no-op code: duplicate ozone-platform setdefault, sw alias,
wayland-branch's setdefault, redundant GDK_BACKEND set (already in
_linux_gtk_init), and the WAYLAND_DISPLAY pop (--ozone-platform=x11
in argv already wins).
- Drop empirically-unnecessary switches: disable-zygote, disable-gpu,
profile-directory, disable-features=ProfilePicker..., and six noise
switches (no-first-run, disable-sync, no-startup-window,
disable-background-networking, password-store, disable-dev-shm-usage).
Verified across hello_world.py / pysdl2.py / qt.py / native Wayland.
- Remove _linux_setup_profile() and its call site; the profile-picker
keepalive workaround does not reproduce on current CEF/Chromium even
with a fresh user-data-dir.
- Make VK_ICD_FILENAMES SwiftShader fallback conditional on no system
Vulkan ICD being installed (glob /usr/share/vulkan/icd.d/), so
bare-metal users keep hardware Vulkan instead of being silently
swapped to software rendering.
- Replace version-tagged comments with current-tense rationale; add
upstream history blocks for the no-sandbox default (CEF commit
f5bc72b23 / branch 2357, Ubuntu 23.10 AppArmor regression) and for
the absent CefCurrentlyOn(TID_UI) assert in CreateBrowserSync.
- Knowledge-Base.md: add troubleshooting entry for the
"kTransientFailure: CreateCommandBuffer" log line, and an opt-in
walkthrough for enabling the Chromium sandbox by installing
chrome-sandbox SUID-root manually.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Copy file name to clipboardExpand all lines: docs/Knowledge-Base.md
+85Lines changed: 85 additions & 0 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -13,10 +13,12 @@ Table of contents:
13
13
*[How to capture Audio and Video in HTML5?](#how-to-capture-audio-and-video-in-html5)
14
14
*[Touch and multi-touch support](#touch-and-multi-touch-support)
15
15
*[Black or white browser screen](#black-or-white-browser-screen)
16
+
*["kTransientFailure: Failed to send GpuControl.CreateCommandBuffer" on Linux](#ktransientfailure-failed-to-send-gpucontrolcreatecommandbuffer-on-linux)
16
17
*[Python crashes with "Segmentation fault" - how to debug?](#python-crashes-with-segmentation-fault---how-to-debug)
17
18
*[Windows XP support](#windows-xp-support)
18
19
*[Mac 32-bit support](#mac-32-bit-support)
19
20
*[Security](#security)
21
+
*[Linux: enabling the Chromium sandbox (advanced)](#linux-enabling-the-chromium-sandbox-advanced)
20
22
21
23
22
24
## Notifications about new releases / commits
@@ -264,6 +266,33 @@ appear even after disabling GPU hardware acceleration. This is normal
264
266
because GPU was disabled so WebGL cannot work.
265
267
266
268
269
+
## "kTransientFailure: Failed to send GpuControl.CreateCommandBuffer" on Linux
270
+
271
+
You may see a log line like this during startup, especially on Linux
272
+
VMs and other systems without a working GPU. On VMs the line appears in
273
+
nearly every run; on bare metal with a real GPU it is rarer:
274
+
275
+
```
276
+
ERROR:gpu/ipc/client/command_buffer_proxy_impl.cc:285] ContextResult::kTransientFailure: Failed to send GpuControl.CreateCommandBuffer.
277
+
```
278
+
279
+
**This is a Chromium-recoverable transient and can be ignored.** It is
280
+
emitted by the renderer process when it tries to create a GPU command
281
+
buffer before the GPU process has finished binding its IPC endpoint —
282
+
typically a millisecond-scale race during startup, more likely on slow
283
+
disks or when Chromium falls back from real-GL to SwiftShader. The
284
+
compositor retries automatically; pages still render and
285
+
`OnContextInitialized` still fires. The `kTransientFailure` label is
286
+
Chromium's own classification — Chromium expects callers to retry, and
287
+
they do.
288
+
289
+
If a clean log is more important than hardware acceleration in your
290
+
deployment, you can opt in to disabling the GPU process by passing
291
+
`switches={"disable-gpu": ""}` to `cef.Initialize()`. Do not enable
292
+
`in-process-gpu` to silence this line — it is not stable across
293
+
multiple browser windows.
294
+
295
+
267
296
## Python crashes with "Segmentation fault" - how to debug?
268
297
269
298
Install gdb:
@@ -347,3 +376,59 @@ A quote by Marshall Greenblatt:
347
376
Reference: [Question on browser security](http://magpcss.org/ceforum/viewtopic.php?f=10&t=10222)
348
377
on the CEF Forum.
349
378
379
+
380
+
### Linux: enabling the Chromium sandbox (advanced)
381
+
382
+
cefpython on Linux passes `--no-sandbox` by default
383
+
(`_linux_apply_initialize_defaults` in `src/window_utils_linux.pyx`).
384
+
385
+
Reasons for the default:
386
+
1. cefpython does not bundle the SUID-root `chrome-sandbox` helper that
387
+
Chromium's namespace sandbox needs to bypass AppArmor's
388
+
`apparmor_restrict_unprivileged_userns=1` (the default on Ubuntu
389
+
23.10+, Debian 12+, and other modern distros).
390
+
2. Without the helper, Chromium aborts at startup with
391
+
`FATAL: No usable sandbox!` — every cefpython app would fail to
392
+
launch out of the box.
393
+
3. The most common cefpython use case is rendering the application's
394
+
own trusted HTML/JS as a UI surface, where the sandbox provides
395
+
defense-in-depth rather than primary security.
396
+
397
+
If your app loads untrusted web content and you want the Chromium
398
+
sandbox enabled, three steps are required:
399
+
400
+
**1. Install the SUID-root `chrome-sandbox` helper.**
401
+
The binary ships in the CEF binary distribution under
402
+
`Release/chrome-sandbox`. Copy it to a stable path and set it up:
0 commit comments