Unvanquished does not load properly if updater runs in a terminal on Linux

[illwieckz]

Hi, it's probably related to some stdio stuff, but Unvanquished hangs at startup when launched by from the updater if the updater runs in a terminal.

If I start the updater from my desktop launcher using [Alt+F2] key combination or if y run the updater without attaching it to my terminal stdios using nohup (doing nohup ./updater), I'm able to successfully start Unvanquished from the updater. Otherwise don't.

You can see these logs: http://pastebin.com/T4qFZjda

You get more logs if you try to restart unvanquished from updater after crashing it before (started from updater too).

Warn: Error writing to the terminal: Resource temporarily unavailable
Warn: Error writing to the terminal: Resource temporarily unavailable
Warn: Error writing to the terminal: Resource temporarily unavailable
Warn: Error writing to the terminal: Resource temporarily unavailable
Loading pak '/data/unvanquished/pkg/unvanquished_0.39.0.pk3'...
 Error: Crashed with signal 11: Segmentation fault

[illwieckz]

This is the error I got the second time I tried to run unvanquished from the updater. I mean I tried to start unvanquished from the updater, it hangs, I killed it, I tried to restart unvanquished from the updater, then I got that:

It says:

Could not acquire singleton lock, Resource temporarily unavailable
If you are sure no other instance is running, delete /home/illwieckz/.unvanquished/lock

You can read similar things in the paste I linked in the previous message:

Warn: Could not connect to existing instance: Connection refused

It looks like if you kill unvanquished while it hangs when started from the updater, it does not release properly some resources. But thanks to that we get more logs on second runs.

[illwieckz]

new updater fixed this

[illwieckz]

Latest master branch of QML updater reproduces the bug.

[illwieckz]

Another way to workaround the bug is to run the updater this way:

</dev/null ./updater2

[slipher]

Haha, I did not notice the bug before because I used the original 0.51.1 daemon which crashes immediately on the distro I'm testing on.

[slipher]

The situation that arises is actually identical to that when you start daemon from a Windows command prompt: stdout is connected to the terminal, but not stdin, and the user can freely run other commands in the meanwhile. Maybe there is something here that should be fixed on the Daemon side - perhaps it is wrongly assuming that if stdout is connected to a terminal, then stdin is also.

We could also consider launching the game with exec instead of in a daemonized process.

[slipher]

Reopening because I still need to check the case of launching the game after an updater update.

[ghost]

What kind of update? A big one? Because I don't remember having been used anything else than the updater to play online (and I do it a lot) while have spot no problems.

[slipher]

The updater update case is still broken. In my test the game did not respond to inputs of any kind when launched after an updater update.