Weird crashes of the MGMT Interface after editing groups

ckd · 2024-12-16T16:58:21+00:00

When adding / editing groups and then switching between domains, the MGMT interface becomes unresponsive and eventually I get logged out and can no longer ge...

ckd

crpb
When restarting nginx everything seems working again. Thanks for the suggestion!
Actually all services were running just fine, none was stopped / throwing any error.

Steakie

Very interesting. I will look into the matter immediately

Steakie

I was not able to reproduce this issue, however i did notice that it is currently possible to create recursive and/or looping groups, which we will fix asap

ckd

Steakie
In the MGM interface go to a domain and edit some groups. It's sufficient to open the group and hit save. Do it with two groups, then switch to another domain and edit another group there. After hitting save, the MGMT interface will stop working.

Steakie

ckd I did exactly that and had no issues. I feel like this has to do with the specific parameters of the group. Can you share an image?

ckd

Steakie

And similar groups with identical settings for another domain. When I edit the groups of both domains within a short time, the issue occurs. I can also grant you access, if you want to see yourself.

The problem occurs that moment, when I still see the groups of Domain A, even though I requested to list all groups of Domain B.

Steakie

ckd huh....interesting. Since the groups i tested with do not have any aliases, i assume this might be problem. From a frontend perspective i cannot really do much about that though, especially because the api seems to be having troubles.
Forwarding this to my colleagues.

Edit: I just found something very peculiar. The backend won't let me set aliases from foreign domains... how and/or when did you set them?

ckd

Steakie
Thanks! I am looking forward hearing you from you guys in the New Year. Happy Holidays! 🙂

ckd

Steakie
I was first creating the groups for my primary domain and then later I was adding all the aliases for my other domains. They also were properly showing in the WebApp and working fine from what I have seen. Is there anything else you want me to test?

Steakie

ckd Did you do this recently? How did you set them? (Because i literally can't because of backend restrictions 😃)

ckd

Steakie

You need an organization with multiple domains. I found the problem on the supported repository using the official ISO (with OpenSuse Leap). Simply edit multiple groups of a domain, then go to another domain within the same organization and edit the groups there. Now the GUI will become unresponsive and you will be logged out after 30 seconds.

Steakie

ckd i am still not able to reproduce this...(which is annoying). To be quite honest, i have no idea how you would even manage to do that, other than........ a state update loop........

Huh....i will have a look at the code again, maybe i can find something without reproduction of the issue

ckd

I still can reproduce this problem on the most recent stable/supported version (fresh installation) using the official ISO. What do you want me to do so you get useful logs / information in order to reproduce and fix this? Thanks.

ckd

@Steakie At your service when you find time to have a look at it. I can now reproduce it every time. Thanks.

Steakie

ckd Hello again, i just reread the thread.
When you say that everything freezes and everything becomes unresponsive: Do you mean loadingtimes or like visual lag in the app?
I feel like you meant loading times, which indicates an API bug. And i think i have an idea: Could it be that your groups are referencing each other in some way? If so, there might be another module on your system which causes a feedback loop, after an update of a group.

ckd

Steakie
That's correct, the group contains aliases of other domains in the same organization. Now you mention it, the problem occurs after editing any of those groups! As stated in my last post, I can reproduce this problem every time.

Steakie

ckd Must be some recursion in the backend going on then....

crpb

@Steakie i think i have similiar problems with mlist's currently -> Ticket#813537

ckd

crpb
Before the MGMT GUI crashes, it will list all users, groups in the current view, even though it should only display groups of Domain A. Ten seconds later I get logged out from the MGMT GUI and no logins are possible. I have to restart all grom* services, which are all still running though, they won't crash. In most cases I reboot, as it's still a test environment.

My problem is still, that I am not getting any useful logs, therefore my question, what you want me to do.

[2025-06-30 15:52:26.226251]: SIGINT/SIGQUIT received...killing workers...

[2025-06-30 15:52:27.225732]: worker 1 buried after 1 seconds

[2025-06-30 15:52:27.225732]: goodbye to uWSGI.

[2025-06-30 15:53:04.974875]: [uWSGI] getting INI configuration from /usr/share/grommunio-admin-api/api-config.ini

[2025-06-30 15:53:04.982269]: *** Starting uWSGI 2.0.19.1 (64bit) on [Mon Jun 30 15:53:04 2025] ***

[2025-06-30 15:53:04.982269]: compiled with version: 7.5.0 on 30 October 2024 12:00:00

[2025-06-30 15:53:04.982269]: os: Linux-6.4.0-150600.23.53-default #1 SMP PREEMPT_DYNAMIC Wed Jun  4 05:37:40 UTC 2025 (2d991ff)

[2025-06-30 15:53:04.982269]: nodename: gr

[2025-06-30 15:53:04.982269]: machine: x86_64

[2025-06-30 15:53:04.982269]: clock source: unix

[2025-06-30 15:53:04.982269]: pcre jit disabled

[2025-06-30 15:53:04.982269]: detected number of CPU cores: 2

[2025-06-30 15:53:04.982269]: current working directory: /usr/share/grommunio-admin-api

[2025-06-30 15:53:04.982269]: detected binary path: /usr/sbin/uwsgi

[2025-06-30 15:53:04.982269]: chdir() to /usr/share/grommunio-admin-api

[2025-06-30 15:53:04.982269]: your processes number limit is 15547

[2025-06-30 15:53:04.982269]: your memory page size is 4096 bytes

[2025-06-30 15:53:04.982269]: detected max file descriptor number: 1024

[2025-06-30 15:53:04.982269]: lock engine: pthread robust mutexes

[2025-06-30 15:53:04.982269]: thunder lock: disabled (you can enable it with --thunder-lock)

[2025-06-30 15:53:04.982269]: - SystemD socket activation detected -

[2025-06-30 15:53:04.982269]: uwsgi socket 1 attached to UNIX address /run/grommunio/admin-api.socket fd 3

[2025-06-30 15:53:04.982269]: Python version: 3.6.15 (default, Sep 23 2021, 15:41:43) [GCC]

[2025-06-30 15:53:05.084844]: Python main interpreter initialized at 0x56097b37d200

[2025-06-30 15:53:05.084844]: python threads support enabled

[2025-06-30 15:53:05.084844]: your server socket listen backlog is limited to 100 connections

[2025-06-30 15:53:05.084844]: your mercy for graceful operations on workers is 60 seconds

[2025-06-30 15:53:05.084844]: mapped 208576 bytes (203 KB) for 4 cores

[2025-06-30 15:53:05.084844]: *** Operational MODE: threaded ***

[2025-06-30 15:53:06.560874]: Failed to detect schema version, assuming up-to-date schema

[2025-06-30 15:53:06.561653]: Database connection failed with error 2002: Can't connect to local MySQL server through socket '/run/mysql/mysql.sock' (2)

[2025-06-30 15:53:08.479760]: WSGI app 0 (mountpoint='') ready in 3 seconds on interpreter 0x56097b37d200 pid: 764 (default app)

[2025-06-30 15:53:08.479760]: *** uWSGI is running in multiple interpreter mode ***

[2025-06-30 15:53:08.479760]: spawned uWSGI master process (pid: 764)

[2025-06-30 15:53:08.481309]: spawned uWSGI worker 1 (pid: 1327, cores: 4)

[2025-06-30 15:53:08.484230]: [WARNING] (tasq) Schema version too old (n102 required) - falling back to offline mode.

[2025-06-30 15:54:36.646603]: [WARNING] (flask.app) Database schema version updated detected - reloading ORM

crpb

@ckd do you get something similiar?

Jun 26 15:28:57 gromail uwsgi[1565]: sqlalchemy.exc.InvalidRequestError: One or more mappers failed to initialize - can't proceed with initialization of other mappers. Triggering mapper: 'mapped class MLists->mlists'. Original exception was: reverse_property 'mlist' on relationship MLists.user references relationship Users.mlist, which does not reference mapper mapped class MLists->mlists

ckd

crpb
I don't have that one in my log files.