Comment 23 for bug 2026200

Thanks Nathan, I came to the same conclusion as the tickets you provided, as we were trying to run the snap from a shared nfs mount, but glad/sad to know that snap was the ultimate problem - sigh. I can now run the snap directly, without glibc issues so hooray.

I'm now dealing with a different issue after switching to `/snap/bin/chromium.chromedriver` - `error: unknown flag `port'`

Are you able to confirm that there should be no difference in the cli of these binaries?

/snap/chromium/current/usr/lib/chromium-browser/chromedriver
vs
/snap/bin/chromium.chromedriver

I'll investigate further on the selenium side, but if I have to open a different ticket for the driver would I do that here as well? or is there a separate bug repo for that package?

Thanks a bunch! Your support ethos is superb.

edit:

To Nathan - I'm fully past my issues with snap / chromium / selenium and the snap path is working for both chromium and the driver.

To Dalik - sorry for polluting your bug ticket - I was convinced you and I were dealing with the same issue and that cups was just a downstream problem.

To Michaelus - I would generally agree with you except that when it comes to snap, what ya gonna do right? The distinction I think is that when you run /snap/bin/chromium, you aren't running a symbolic link to the actual endpoint, you are running a symbolic link to snap itself, which then does voodoo in a privileged process.

To future googlers who end up here with my specific problem, I simply needed to upgrade selenium-server to 4.x (was on a 3x branch) and 4.x no longer provides a 'port' parameter to the chromium.chromedriver binary.