@tenacity @eugenialoli

Alright so I couldn't reproduce much except ending Tenacity from MissionCenter does kill the GNOME Session somehow. I'll dig.

Other than that, Tenacity is behaving perfectly fine so I think we can eliminate the malware suspicion for them 😅

Altough it would be awesome to get those permissions in order. @tenacity Let me know if I can help!

Note that with something like htop the process might show under brwap.

@tenacity @eugenialoli

hehe fun bug - for some reason Mission Center associates gnome-session-binary with Tenacity

I filed a bug here https://gitlab.com/mission-center-devs/mission-center/-/issues/190 - consider subscribing to updates in case they need more info.

@sonny @tenacity Thank you! I have just reinstalled Tenacity and was able to reproduce it as you mentioned (mission control saying that tenacity is open and killing it kills gnome). But I wasn't able to get gjs bloating to 120 MB of RAM. Not sure what was causing that part, might have been coincidental that both things happened around the same time (and resolved together...). I also ran Wireshark just now, didn't see anything out of the ordinary.

@sonny @tenacity I have edited the original post to not be so dramatic. :-)

Thank you for your work!

@sonny @tenacity I was now able to reproduce the gjs bug where it's using lots of ram (currently using 200 MB of RAM). It wasn't Tenacity's problem. The problem is that every time I open the "Dash to Panel Settings" window, it adds about 30 MB of RAM in the main gjs service.

I'll file a bug with dash-to-panel extension, but i wonder if i should do it for gjs too.