Aether backend process duplication and slow computer

  • Operating System (Windows 10 Enterprise):
  • App version (dev12)

Expected Behavior
By opening the task manager i must see only one instance of aether backend

Actual behavior
Some times multiple istances of aether backend appear in task manager and the PC become very slow

To Reproduce
I didn’t find a specific cause
EDIT: maybe is a conflict with MATLAB 2017b…when i opened this software multiple instances of aether backend appeared and the pc become slow!

Screenshots


Can became dozens!!!

After some clicks on MATLAB icon…

Additional Information
If you want i can give you my aether dir

Thank you!

1 Like

Interesting — that sounds like something non-ordinary is happening with your system because Aether normally prevents the run of multiple instances by checking whether there are other copies are running, and if so it terminates itself.

One more interesting thing is - I’m looking at the logos of the 3 Aether apps you’re running and they’re slightly different. Is there any chance you actually have multiple different versions of Aether installed somehow, and all of them are trying to run at the same time? That’s the only way I know of where you can have multiple versions working together. If you go to Add / Remove Programs, how many installations of Aether do you see? There should be just one.

1 Like

I controlled the control panel… i’ve dev12 only. There is also another weird bug that i found. i’m opening another post for this but maybe is the same bug

Yes, it’s the same bug, I think. I think the best way to make sure of the issue is to delete the app, restart the computer and make sure that there are no more instances, and then reinstall it. I remember you are using Italian, and non-English languages have been a problem in another bug in the past, that’s the only thing I can think of that could cause it.

Let me know if you are still seeing this after a delete > restart > reinstall. This might be a bug in Electron’s ‘detect duplicate running instances’ code that is failing.

By uninstalling the software and removing all related directories i stopped the resending of the same message of the other post…but the duplication of backend bug persist and when i try to post something new it reappear with the multiplication the new post :frowning: This seems not related to MATLAB (now turned off)

B i unistalled the software, deleted all Aether’s folder in /local and /roaming and deleted the old aether installation folder in C:// but the problem persist. There are others place where Aether files is stored? Maybe if i delete these others files completely the software will run correctly.

Apologies for the quiet. So I don’t think there are any others, but this is really weird. There are no other directories, you’ve found all of them. The only one that matters is the one that goes by Air Labs / Aether ... that is your profile. For the app to start multiple times, I would need to have something like either there are multiple binaries somewhere that is starting on the application boot, or the app spawns the multiple binaries on its own, thinking that it has crashed.

Could you answer these questions?

Q1: When you disable the start at boot, and restart your computer, does the multiple backends thing happen?

If yes, you have multiple records on your Start menu > Startup programs (I don’t know exactly what is called in Italian, but something similar)

  • If no, and the multiple processes start when you only start Aether, that means the app is thinking that the backend or the frontend has crashed, and is spawning.

Q2: When you start the app, does the multiple processes start immediately, or 2nd, 3rd… etc processes come a while after? Especially when you are doing something like posting or upvoting.

  • If immediately, the app is thinking that the backend or frontend has crashed, and restarting it, and the backend/frontend becoming unresponsive happens right after launch.

  • If later, the backend/frontend does something that goes into the unresponsive state, and after a while the client decides that they are gone and ‘restarts’ them, and links itself to the newly spawned be/fe. The issue is, the old be/fe was busy, not crashed, and it comes back online after doing its job, to find out that it is now orphaned.

  • My suspicion is that, considering that you also have slowness problems, the frontend compilation thing (the part that you have slowness issues with) is taking so long on your computer that the client (the UI app) is deciding that the frontend hasn’t been responding for a long time, and it is probably dead. To be fair, this is not a bug, the client needs to be able to spawn a new frontend when the old one goes dead so as to not break the app and most of the time this happens it’s actually the right choice. In your case though, it’s the rare case where the frontend isn’t dead but actually doing work, but the client waits so long that it decides it is dead.

So my impression is that your two issues (speed and this multiplication) are actually the same issue, repsesenting itself in different ways. I’m currently working on an intermediate caching layer between disk and the app to be added to the app so that the app can use much less disk, and reduce reads and writes. I know that you use your computer for other things so maybe until I actually push the new version you might want to keep the app closed. I’m currently working on this, this is a fairly complex backend thing so I need to fully test that it actually compiles correctly. But I suspect when it comes it’s going to fix both of your problems. I’d expect, a few days, a week if everything goes right? I’m also having long compile times on my computer and I want to fix it, so I’m investigating a couple ways of improving this. No guarantees, but this is on top of my todo list and I’m currently actively working on this because it’s going to improve it for everybody.

Q1: the problem persist also after disabling the start at boot

Q2: multiple processes appear only when post new things or make votes

i shut down my node and i’m aaiting for updates… as soon as i can i try to build a new node on a virtual system using virtualbox

Hey there, I just pushed a new version (dev.13) that might be able to fix your issues. Let me know if you end up giving it a shot. It has a lot of improvements to make the app use much less disk reads and writes, which I suspect was the reason you were having Matlab problems. Here’s some more details: https://blog.getaether.net/post/185689269152/aether-dev13-released-up-to-30x-faster-updates

version dev13 works perfectly for me if i create a new user…but after the paste my old user profile (frontend_config.json) in the frontend folder the system get stuck… maybe is a problem of old user keys?

Glad it helped!

There has been no difference in the configs between dev.12 and dev.13 so one that works for one should also work for the other. I would copy the old and new configs to a Diff checker like this and see what gets highlighted as the difference. If there are more keys in the new one vs. the old one, you should be able to just copy those to the old one and have it work.

i found that the old frontend_config.json file had a bad sintax in the SFW communities list…fixing that part of the file copyng the one of a new user profile seems to fix the problem

I was having the same problem with process duplication. The frontend process was starting, spawning a backend process and then stopping, orphaning the backend process and repeating. This happened once every ~30 seconds or so. I tried reinstalling without success. This started happening at the beginning of September after returning from a vacation, my computer was off for roughly a week.

At that time (~2 weeks ago), I found this thread and did the following:

I archived my …\Roaming\AirLabs\Aether directory, generated a new profile (this fixed the process duplication but my profile was gone), copied my old frontend_config.json into the new …\Roaming\AirLabs\Aether\frontend directory and restarted Aether. The process duplication persisted after restoring my old profile.

Today, I saw the email that Aether had an update and decided to try it out. After updating, the process duplication was still occurring with that old frontend_config file. I attempted the same process described above and it looks like it worked this time. I have my old profile and the process duplication isn’t happening anymore.

Great to hear. I’m not sure what specific thing fixed since there was no change related to this in this new version, however I updated a lot of the dependencies to their current versions on this one. It is possible that the issue was in one of our dependencies and it got fixed via the dependency updates.

That said, I’d rather be cautious about this since we did nothing to fix it directly. I’d suggest keeping an eye on it and if you see it start to happen again, let me know.

I also see 2 aether-backend-linux-x64 processes spawn, then 1 shuts down… after 10 seconds, 2 more spawn, repeat until OOM.

Same here.

It isn’t happening with a clean profile, so I’ll diff them and see what happens.

This is fishy… Splicing in the important bits of my old profile, I seem to be running happily on dev.14, without runaway processes.

-    "UserDirectory": "/home/me/snap/aether/x9/.config/Air Labs/Aether",
+    "UserDirectory": "/home/me/snap/aether/x1/.config/Air Labs/Aether",

same issue here, I let it run for 1-2 mins and i had over 20 aether backend processes in the task manager, happenend on the last version and the new version as well. (Im using windows btw)

The reason the flash in / out is happening is that the backend is starting, but crashing - so the frontend tries to spawn another one.

To figure out what it logs when it crashes, you can find the backend executable and run it in a command line to have it log the results. That would give us the reason why it’s crashing.

It’s usually some config file incompatibility with the backend-config.json, or because the backend config file got corrupted due to some unclean exit, either when computer crashed or some other type of write to file got interrupted in the middle.

@jazzyjellyfish would you be able to go into the snap file, find the aether-backend binary and run it? You’re on linux, so it should spawn a shell by default. You can then see why the backend is crashing.

I was in a shell for snap run aether, I see the frontend was in a panic loop…

panic: runtime error: index out of range [0] with length 0

goroutine 72 [running]:
aether-core/aether/frontend/refresher.DeleteStaleData(0x5d868945)
	/Users/Helios/CloudStation/DropboxExpats/Aether_Catchall/Aether_Main_Repo/Aether_2/aether-core/aether/frontend/refresher/refresher.go:118 +0xa86
aether-core/aether/frontend/refresher.Refresh()
	/Users/Helios/CloudStation/DropboxExpats/Aether_Catchall/Aether_Main_Repo/Aether_2/aether-core/aether/frontend/refresher/refresher.go:80 +0x31e
aether-core/aether/frontend/fecmd.startSchedules.func1()
	/Users/Helios/CloudStation/DropboxExpats/Aether_Catchall/Aether_Main_Repo/Aether_2/aether-core/aether/frontend/fecmd/run.go:130 +0x48
aether-core/aether/services/scheduling.ScheduleRepeat.func1(0xc0002e16f0, 0x0, 0x0, 0x1bf08eb000, 0xc000044de0, 0xd693a8)
	/Users/Helios/CloudStation/DropboxExpats/Aether_Catchall/Aether_Main_Repo/Aether_2/aether-core/aether/services/scheduling/scheduling.go:35 +0x4d
created by aether-core/aether/services/scheduling.ScheduleRepeat
	/Users/Helios/CloudStation/DropboxExpats/Aether_Catchall/Aether_Main_Repo/Aether_2/aether-core/aether/services/scheduling/scheduling.go:
21 +0xad

Frontend process exited with code 2 and signal null
We will reattempt to start the frontend daemon in 10 seconds.

It’s OK now, I think UserDirectory being x1 was my problem.

Now I just can’t post – “The insertion for this entity has failed.” I would bet that has to do with copying over my old frontend keys?

Yes, that last ‘failed insertion’ happens because the backend refuses the post that the user has created because they keys don’t match or it has otherwise failed verification. The keys are present in your frontend config in two places, one of them is the key pair and the other is the marshaled pubkey, did you move both?

I brought over my old UserKeyPair, MarshaledUserPublicKey, FrontendKeyPair, MarshaledFrontendPublicKey.

Er – I thought I did, I must have gotten the diff backwards :sweat: All good now.