--database flag is now required for crashpad handler in Chrome 128.0.6613

[davide-alghi]

chrome-php fails with the latest version of Google Chrome (128.0.6613.113)

2024-09-02 07:11:19.3271 [error][] - Chrome process stopped before startup completed. Additional info: mkdir: cannot create directory '/var/www/.local': Permission denied touch: cannot touch '/var/www/.local/share/applications/mimeapps.list': No such file or directory chrome_crashpad_handler: --database is required Try 'chrome_crashpad_handler --help' for more information. [11780:11780:0902/071119.313895:ERROR:socket.cc(120)] recvmsg: Connection reset by peer (104) RuntimeException: Chrome process stopped before startup completed. Additional info: mkdir: cannot create directory '/var/www/.local': Permission denied touch: cannot touch '/var/www/.local/share/applications/mimeapps.list': No such file or directory chrome_crashpad_handler: --database is required Try 'chrome_crashpad_handler --help' for more information.

[siwa-ddiesenreither]

Same issue for me:

Chrome process stopped before startup completed. Additional info: chrome_crashpad_handler: --database is required Try 'chrome_crashpad_handler --help' for more information. [3348:3348:0902/132920.572347:ERROR:socket.cc(120)] recvmsg: Connection reset by peer (104)

Using chromium (128.0.6613.113-1~deb12u1)

[enricodias]

@davide-alghi check issue #401.

@siwa-ddiesenreither check issue #394.

[maxiwheat]

@enricodias I don’t get why the update to Chromium 128 is causing this issue ? We run this in an Alpine docker container since a while without issues, and now with this new version of Chrimium we get the same error message as @siwa-ddiesenreither (which does not help very much)

I tried to do what's suggested in issue #394 and it does not work, those folders/files do not even exists in the container.

[enricodias]

@maxiwheat I don't know what changed on chrome to make this an issue again, but there are a few other solutions in this issue that you can try.

[davide-alghi]

@enricodias ok tnx
maybe here's the prob and the fix

https://indocoding.vesocial.com/dev/new-version-of-chrome-broke-chrom-php-headless-chromium

@siwa-ddiesenreither
@maxiwheat

[enricodias]

Ok, this seems to be a new issue. I'm not sure if we should just mention it in the readme or tweak the code to use a default crashpad path when running on linux, probably inside the /tmp folder 🤔

[maxiwheat]

@enricodias ok tnx maybe here's the prob and the fix

https://indocoding.vesocial.com/dev/new-version-of-chrome-broke-chrom-php-headless-chromium

@siwa-ddiesenreither @maxiwheat

The provided solution in this link does not work for me. The actual fix that finally worked is the one posted previously by @enricodias referirng the comment here: puppeteer/puppeteer#11023 (comment)

[adis0308]

A simple solution that you can do is to create a crashpad folder and disable it with customFlags.

1. Create a crashpad folder:

sudo mkdir -p /home/www/.config/google-chrome/Crashpad
sudo chown -R www-data:www-data /home/www/.config

2. Disable crash reporter with customFlags:
   --no-sandbox --disable-dev-shm-usage --disable-gpu --headless --disable-crash-reporter --no-crashpad

[DenysSokolovBack]

A simple solution that you can do is to create a crashpad folder and disable it with customFlags.

1. Create a crashpad folder:

sudo mkdir -p /home/www/.config/google-chrome/Crashpad
sudo chown -R www-data:www-data /home/www/.config

2. Disable crash reporter with customFlags:
   --no-sandbox --disable-dev-shm-usage --disable-gpu --headless --disable-crash-reporter --no-crashpad

Working for me #394 (comment)

sudo mkdir -p /var/www/.config/google-chrome/Crashpad
sudo chown -R www-data:www-data /var/www/.config

[CrazyVito11]

For some reason it has to specifically be in the /var/www/.config directory, as the directory I set with --crash-dumps-dir=/tmp/chrome-crashpad seems to be ignored.

This used to work fine until the recent Chromium update, so I guess it might be a bug in Chromium itself?

[namosdjoro7]

any news?
How could we configure crashpad database?

$browser = $browserFactory->createBrowser([
                'headless' => true,
                'customFlags' => [
                    '--disable-crashpad',
                    '--disable-dev-shm-usage',
                    '--disable-gpu',
                    '--headless',
                    '--disable-software-rasterizer',
                    '--no-sandbox',
                    '--crash-dumps-dir=/var/www/.config'
                ],
            ]); 

This config does not work

[jeandanyel]

Same issue for me:

/srv/app # chromium-browser --version
Chromium 128.0.6613.119 Alpine Linux

[NJPod]

Discovered this issue this week. What is weird is that running our container image locally doesn't have this issue but in AWS Fargate it craps out. I tried setting the XDG_CONFIG_HOME and XDG_CACHE_HOME env variables to use a tmp folder but it didn't seem to work. In the end I just created the .config folder when building the docker image.

[jeandanyel]

Hello @NJPod,

I’m experiencing the same issue. It works perfectly fine locally but fails in production on DigitalOcean's App Platform.

Could you share the command you added to create the .config folder when building the Docker image?

Thanks!

[NJPod]

Hello @NJPod,

I’m experiencing the same issue. It works perfectly fine locally but fails in production on DigitalOcean's App Platform.

Could you share the command you added to create the .config folder when building the Docker image?

Thanks!

RUN CHROME_DIRS="/var/www/.local /var/www/.config /var/www/.cache /var/www/.pki" && \
    mkdir -p ${CHROME_DIRS} && \
    chown www-data ${CHROME_DIRS}

This also covers some warnings I was seeing whilst debugging.

[zaltysz]

Workaround in my Linux environment:

$browserFactory = new BrowserFactory();  

$options = ['userDataDir' => $temp_user_data_dir,
                     'envVariables' => ['XDG_CONFIG_HOME' => $temp_user_data_dir,
                                                     'XDG_CACHE_HOME'   => $temp_user_data_dir,
                     ],
];
            
$browser = $browserFactory->createBrowser($options);

The downside is you have to clean $temp_user_data_dir yourself in the end. because BrowserProcess does not do that when you explicitly set 'userDataDir' as option.

I would like to propose a fix in the library. BrowserProcess::start() should inspect $options['envVariables'] for XDG_CONFIG_HOME and XDG_CACHE_HOME, and set missing ones to same value as $options['userDataDir'] (given by caller or created temporary by class).