client's Sys::Error messages can't be quit from command line over SSH

[illwieckz]

When I'm testing the game on some specific hardware and driver configuration, I usually build on my workstation, then the build is sent to a target computer hosting the wanted hardware and the wanted environment, and the game is running on that target computer but with the console on my workstation (through SSH) on the same screen I'm running the editor and compiling the game.

When a Sys::Error happens on the client, a pop-up with the error message is displayed, which is good for the end user, but then, there is no way to quit the running process other than reaching the target computer keyboard and press “enter” (or use target computer mouse to click the button).

Hitting Ctrl+C over the remote console just kills the ssh connexion, and the engine is still running on the target host with the pop-up displayed.

So I'm looking for a solution to quit the game from command line when the Sys::Error pop-up is displayed?

We may do a cvar to not display the pop-up, it would address the problem of requiring to physically access the target host, but it would not be possible to test the display of a pop-up with updated message on a target host known to reproduce the error I want to describe with a good-looking message… So that would not be a proper solution.

I've noticed that on an usual terminal, the engine does not quit on Ctrl+C, which is good. Maybe on a remote shell, because Ctrl+C does nothing on the engine, SSH traps it instead ? Maybe if we stop to inhibit Ctrl+C on the engine just before displaying the pop-up would address the issue ?

[slipher]

the engine does not quit on Ctrl+C, which is good.

Why is it good? This is a side effect of Breakpad, not something intentional.

Ctrl+Z works for me, even with Breakpad on.

[illwieckz]

Why is it good?

Hmm, I had the feeling some people asked for this behaviour, maybe I'm wrong… Or maybe the request was about properly intercept that signal to properly shutdown and not leave the terminal in a broken state.

Ctrl+Z just suspend the running processn it's still alive, it's not killing it.

Also I just did a test over ssh, it suspends the remote connection (ssh itself) and the game continues to run on the target host, so that would mean Ctrl+C being caught by ssh is not related to breakpad or any engine mechanism…

What if, when Sys::Error happens, the engine does a simple read on the console (at the same time the pop-up is displayed) and quit the game by pressing return on standard input? Maybe we are not threaded enough for this?

[slipher]

Ctrl+Z just suspend the running processn it's still alive, it's not killing it.

Yes. You can then issue further commands to kill the process.

What if, when Sys::Error happens, the engine does a simple read on the console (at the same time the pop-up is displayed) and quit the game by pressing return on standard input?

Why not just make Ctrl+C work?

[illwieckz]

We have to make sure SSH is not intercepting it before (SSH also intercepts Ctrl+Z). I'm not running an interactive shell.

For example, I'm doing this;

target=targetname
make -j"$(nproc)" \
&& ssh "${target}" "mkdir -p '$(pwd)'" \
&& rsync -av --delete-after --links "$(pwd)/." "${target}:$(pwd)/." \
&& ssh "${target}" "DISPLAY=:0 '$(pwd)/daemon' +devmap plat23 +delay 100f setviewpos 2312 2120 308 68 40"

[illwieckz]

hmm, it looks like I found a ssh option I didn't knew: ssh -t

By using that, it appears to send the signal to the remote process.

So my command is now:

make -j"$(nproc)" \
&& ssh -t "${target}" "mkdir -p '$(pwd)'" \
&& rsync -av --delete-after --links "$(pwd)/." "${target}:$(pwd)/." \
&& ssh "${target}" "DISPLAY=:0 '$(pwd)/daemon' +devmap plat23 +delay 100f setviewpos 2312 2120 308 68 40"

When I do that the daemon engine intercepts the signal when running properly.

But when the Sys::Error pop-up is displayed, doing Ctrl+C just returns to the console without killing the engine…

[illwieckz]

On local terminal I get the same behaviour, hitting Ctrl+C while Sys::Error pop-up is displayed does not kill the pop-up.

Edit: and the terminal is left in broken state.