CCP_Bartender

Hey all, CCP Bartender here!

There’s been a little bit of confusion about what’s happening with EVE and Linux. Let me do a little information dump and clarify some things.

Before we get to that, I want to reiterate that CCP discontinued official support for Linux in early 2009. A combination of some convenient early technical decisions and extra time by Linux-using devs has allowed Linux to remain surprisingly viable for the last decade, but it is not a supported operating system.

A forum post mentioned...

The other thing that might be confusing in this update is that the launcher had a bug where when it closed for update, it didn’t actually close because there was a hanging thread in the background.

That meant the undead launcher had exclusive hold over the settings files and so when the updated launcher started it seems to have forgotten your accounts. If you kill all launcher instances from the task manager and start it again, all your accounts are back.

Unfortunately, because it’s a problem with closing the launcher, and you have to close the launcher to patch, the issue happens one last time in the process of rolling the fix out

Hrmm, I am mad suspicious about those update+innerjoin queries in the wormholeCritical event.

Again, not an expert in innodb and hard to say without the query planner, but according to this gentleman, you might be locking way more of the table rows than you expect: https://stackoverflow.com/questions/6664667/mysql-innodb-locks-on-joined-rows/12251122#12251122

You could try using a with clause, it might help hint the query planner to reduce the amount of rows locked by divorcing the...

My recommendation would be that you start by looking into the query planner explain command. I use the TSQL equivalent a lot when doing these kinds of optimizations to the eve DB. Unfortunately, I know very little about the details of innoDB, but as an example, consider the following query:

UPDATE signatures SET modifiedByID = 0, modifiedByName = "Tripwire" WHERE lifeLeft < NOW() AND lifeLength <> '0' AND type <> 'wormhole';

When executing that query, you’re hinging on the index being created by this key in the signatures table to avoid a whole table scan:
KEY `lifeLeft, lifeLength` (`lifeLeft`,`lifeLength`),

However, it may be buying you less than you expect. You’re about to wander into the deep magic of implementation-specific db engine index construction techniques.

Here are some good links on the topic:

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.

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?

Nah, standard release builds. Very weird problem.

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 ?

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?

This thread is an experience.

The official CCP position on linux: We don’t support linux.

What does that mean: It means that officially, zero thought goes into how things support linux. Hypothetically speaking, if an anti-cheat system started being triggered by linux, that anticheat system would not be adjusted on company time.

Unofficially: I also stripped windows out of my personal life about 5 years ago, and I want to continue playing eve. So under this hypothetical situation I would probably spend some personal time attempting to fix such an issue, but any fix would have to work without undermining robust anti-cheat on our supported platforms, which are mac and windows. So you’ve got an insider, but I have to respect that linux is not supported and be careful not to cause issues on the supported platforms.

Silver lining: linux maintenance has required probably less than 20 hours of my time over the last two or so years, because we use wine on mac as w...

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.

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

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?

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.

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 1732478, containing a fix for the minimise-on-close-issue

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

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?

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.

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