Instal Steam
login
|
bahasa
简体中文 (Tionghoa Sederhana)
繁體中文 (Tionghoa Tradisional)
日本語 (Bahasa Jepang)
한국어 (Bahasa Korea)
ไทย (Bahasa Thai)
Български (Bahasa Bulgaria)
Čeština (Bahasa Ceko)
Dansk (Bahasa Denmark)
Deutsch (Bahasa Jerman)
English (Bahasa Inggris)
Español - España (Bahasa Spanyol - Spanyol)
Español - Latinoamérica (Bahasa Spanyol - Amerika Latin)
Ελληνικά (Bahasa Yunani)
Français (Bahasa Prancis)
Italiano (Bahasa Italia)
Magyar (Bahasa Hungaria)
Nederlands (Bahasa Belanda)
Norsk (Bahasa Norwegia)
Polski (Bahasa Polandia)
Português (Portugis - Portugal)
Português-Brasil (Bahasa Portugis-Brasil)
Română (Bahasa Rumania)
Русский (Bahasa Rusia)
Suomi (Bahasa Finlandia)
Svenska (Bahasa Swedia)
Türkçe (Bahasa Turki)
Tiếng Việt (Bahasa Vietnam)
Українська (Bahasa Ukraina)
Laporkan kesalahan penerjemahan
... you can see quite a few, presumably running in a loop. When the game terminated I looked at the last one, which in my case the was /proc/2554/cmdline. Examining that:
Unfortunately I lost the terminal output, but in this case it was Chrome's GPU process. Quitting out of Chrome allowed the game to start without any trouble.
For whatever reason it seems the game mis-identified the wrong process as an already-running instance of the game and terminated. I think in this case it might be related to Chrome's occasional use of /proc/self/exe to spawn child processes, but I wasn't able to get the bug again when I restarted Chrome (its GPU process hadn't been launched via /proc/self/exe for some reason).
If any of the devs see this hopefully it'll help solve the issue, although I think it may be a bug with Unity. The "Player is already running" bug seems to be fairly common for Unity games under Linux, and in the few instances where others have (inadvertently) solved it, its always been by closing Chrome or logging out and back in.
When this happens, what's in the conflicting cmdline file? Was it actually "/proc/self/exe" ?
Killing this process resolves the problem and the game will launch. Unfortunately I could not reproduce the problem; restarting Mattermost led to the instance in question here being launched as a normal electron process, not using /proc/self/exe
/proc/self/exe--type=renderer--field-trial-handle=5509477849240657217,6797439337003870637,131072--disable-features=SpareRendererForSitePerProcess--lang=en-US--app-path=/usr/lib/mattermost-desktop/app.asar--no-sandbox--no-zygote--preload=/usr/lib/mattermost-desktop/app.asar/browser/webview/mattermost_bundle.js--context-isolation--background-color=#fff--guest-instance-id=4--enable-blink-features--disable-blink-features--hidden-page--enable-websql--num-raster-threads=4--enable-main-frame-before-activation--service-request-channel-token=12639844217821139103--renderer-client-id=11--no-v8-untrusted-code-mitigations--shared-files=v8_context_snapshot_data:100,v8_natives_data:101
I think the problem here is that WL2 is resolving `/proc/self/exe` in its own context and finding its own binary.