Launch failed on Linux (game does not start)

[dwd]

Clicking on "Play" button in Steam causes the game to start and immediately terminate with no visible diagnostics or windows opening etc.

A bit of fiddling led me to try running the WL2 executable under strace, which in turn allowed me to find the ~/.config/unity3d/Player.log file it writes, containing:

## STARTS

Player is already running

(Filename: Line: 438)

## ENDS

There seems to be much hunting for a shared data file, too, which it doesn't find (though that's probably a side effect of running it without Steam). The Player.log file is created and written to with the same contents by execution through Steam.

Possibly relevant information:

1) This system is Ubuntu 64-bit. It's up to date and runs other Unity3D Steam games.

2) It has nVidia graphics, two cards and three screens. One of the two 1200x1600 portrait screens is listed first and some games don't observe the "primary" mark in randr, leading to confusion, pain, and anguish. Other games try to run the game across all three. I'd expect either of these cases to cause a window to open "in the wrong place", but I'll try deconfiguring the screens later (though it's annoying).

I don't know much about Mono or Unity3D, but I'm happy to run debuggers, run a screen sharing session, and so on. (I do have reasonable general knowledge of development and sysadmin).

[Blast Hardcheese]

I was having this exact issue and stumbled on this post when I was looking that same Player.log I saw in strace. I ended up fiddling with it a bit more and saw it was opening quite a few /proc/xxxx/cmdline files, presumably looking to see what other apps were running. If you run:

strace ./WL2 | grep grep open\(\"/proc/

... 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:

cat /proc/2554/cmdline; echo

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.

[Tak!]

The reason this will affect some games and not others is that game developers need to choose "Single app instance" in the player build settings to enable this feature.

When this happens, what's in the conflicting cmdline file? Was it actually "/proc/self/exe" ?

[Blast Hardcheese]

Unfortunately I'm not sure, I lost the output and haven't been able to reproduce it since. I believe it was /proc/self/exe with a number of additional arguments.

[sparr]

I am encountering this same problem. Here is a sample cmdline that is the last one WL2 checks before bailing out, which is similar to the behavior reported above in that it's a browser instance using /proc/self/exe but not desktop Chrome this time, instead an electron app (Mattermost).

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.