[2020] New launcher beta: 1732117

Hey all, the linux launcher release is now quite far behind current windows release, so I’m embarking on a little project to bring it forwards in time somewhat.

The first step of this is to update the linux beta to bleeding edge, so I have released beta 1732117. I’d like to ask people to give this a try and let me know if they encounter issues. Don’t forget to include your distro and version!

Notable changes in 1732117:

• QT version updated to 5.12.0
• Login flow now contained entirely within main window
• fancy splash screen
• Like 9 months of other patches or something IDK there’s a lot of stuff in there

Known issues:

• Steam and facebook login buttons do not work

Looks like the reason mine forgot my accounts might be because the launcher isn’t actually closing properly, so after the patch I had multiple launchers open. Carefully killing all launchers after patch and then relaunching a single instance may restore the account list. Seen on Xubuntu 18.04.

If other people see this issue, please let me know.

The E0523 I’m not particularly worried about. It puts a lot of noise on the console, but I’m not sure it has any ill effects. I’m not sure what that server is, but I’ll check in with the launcher team about it. It’s probably a content server for some part of the UI.

I’m more worried about the crash. Does that happen under any specific circumstances?

Hrm, further investigation suggests this is in some fashion a known problem with flicking between QT versions:

https://bugreports.qt.io/browse/QTBUG-82105

I haven’t looked any further into it, but my guess is that this might just be happening because in this update you moved from qt 5.11 to 5.12. Given that the launcher isn’t exiting properly, the two running versions may have been fighting with each other.

Based on what I’m reading in that bug report, I would guess that provided you stay on the current beta and do not downgrade, you should not see the issue again. Let me know if it does keep showing up

I’ve just pushed beta 1732478, containing a fix for the minimise-on-close-issue

I also am seeing the zombie process on close issue. I’ll poke people about it.

I can’t get a repro on the “closing the launcher kills the clients” issue. Any chance Gentoo is doing something super-weird involving placing the eve instances under the process tree of the launcher, instead of launching them as independent processes?

I’ve just pushed beta 1734683, containing a partial fix for the zombie process issue.

The underlying issue is that there is a background thread that can fail to initialize properly, and if it does fail to initialize it blocks termination of the entire process. That will need to be fixed by the launcher team, and affects all platforms.

However, the elg warning people were seeing was a symptom of a problem which was causing that thread to fail to initialize 100% of the time, and I have fixed that issue. You’ll get one last zombie process when the update to 1734683 happens, as the version it’s upgrading from fails to close properly. After that, for most people the zombie process issue should go away.

Hrm, intriguing behavior.

I do get them placed under the same process tree as you. When I close the launcher, the existance of the eve processes seems to block the launcher process from going away.

However, in my case, it seems that closing the launcher causes the eve clients to lock up a few seconds later. I guess your distro is more aggressive in murdering processes that don’t respond to a kill. It definitely didn’t do this before, but rolling back to current release causes the same behavior. Any idea when it started?

There are many potential causes, in your case you’ll probably have to wait for the underlying issue to get fixed.

If you kill or end the parent process then should the child processes be terminated too, so all works so far as expected.

I’m not sure about that actually. I did some investigation, windows picks up the orphaned processes and lets them keep running. The mac tests weren’t super clear because the mac environment wasn’t totally clean, but it looks like mac also rescues the orphans.

Some research suggests that linux also should adopt the processes, by reparenting them directly under the init process. Maybe this is another systemd thing that I don’t know about?

In any case, could be tricky to solve, given that we’re in OS-dependent behavior here. If anyone knows stuff about how processes are supposed to be adopted or killed based on what happens to the parent process, I’d appreciate any extra info.

Oh yeah, the & thing is dead obvious in retrospect, should be easy to add.

How did you do the testing though? I thought the launch commands were executed from within the c++ qt code?

I did some testing last night, simply adding the ampersand doesn’t work. I presume because QT isn’t really using a shell to do the launching.

Using qprocess::startDetatched kinda works, however the exefile (game client) blocks shutdown of the launcher. Similar symptoms to the thread problem, when the launcher is closed the window disappears, but the actual process remains open until the exefile process also quits. This seems to mean that qprocess::startDetatched doesn’t actually start the process fully…detatched.

Do you see the same thing with the ampersand trick on your system ?

Nah, standard release builds. Very weird problem.

That’s interesting, I wonder if something like that is causing @Ravow’s qt problem as well. The QTDir directive is also unquoted.

@Ravow is there a space in the path to your evelauncher.sh file?

Also, I have just released beta 1747682, which contains a fix for some problems unpacking bulk downloads. These were resulting on clients relying on download-on-demand in some cases where they should have been able to use pre-downloaded assets.