Probleme mit der Grommunio-admin-api

491810 · 2025-11-13T22:13:58+00:00

Eigentlich lief meine Grommunio fehlerfrei bis ich vor 2-3 Wochen Probleme nach dem Update hatte. Am Ende lies sich alles nach einen Zurücksetzen und einem s...

Andy

WalterH Die Datei /etc/cron.d/grommunio-admin-api anlegen, Inhalt: @reboot root sleep 30; /usr/bin/systemctl restart grommunio-admin-api

Das hat leider nicht funktioniert, ich habe dafür eine Datei angelegt in

/etc/cron.hourly/grommunio_admin-api-restart.sh

/usr/bin/systemctl restart grommunio-admin-api >> /var/log/grommunio-admin-api-restart.txt 2>&1

Damit funktionierts zumindest stündlich. Die /etc/crontab scheint irgendwie nicht brauchbar, ich hatte das schon mal festgestellt. Die Einträge darin, egal was, reagieren irgendwie überhaupt nicht.

WalterH

Andy Das hat leider nicht funktioniert, ich habe dafür eine Datei angelegt in

Was hat nicht funktioniert? Gab es 30 Sek. nach dem Reboot eine Fehlermeldung? Was steht im Mail an den root wenn der Fehler auftritt?

umgfoin

WalterH Ein Restart vom Admin-UI dauert aber recht lange:

Walter, teste mal:

grommunio-admin-api.service: 
KillSignal=SIGTERM

api-config.ini:
die-on-term = true

(daemon-reload)

Eine grundsätzliche Frage:
grommunio-admin-api.service hat eine socket-unit.
D.h.: Der Dienst muß nicht explizit gestartet werden, sondern startet on-demand beim ersten Zugriff auf den socket.
Habt Ihr mal getestet, ob Folgendes die hier geschilderten Reboot-Probleme beheben kann?

systemctl disable grommunio-admin-api.service
systemctl enable grommunio-admin-api.socket
systemctl start grommunio-admin-api.socket

++umgfoin.

Andy

Das brachte auch nichts. Es war dennoch wieder ein sudo systemctl restart grommunio-admin-api erforderlich.

Mister2

I too picked up the 'unable to login to the Admin UI' issue somewhere towards the end of October, as mentioned elsewhere on the forum. However, I have only applied the updates for the CE version as and when available. I stopped needing to run the 'systemctl restart grommunio-admin-api' command sometime early last week. It just stopped happening after an update last week. I didn't document date as was just pleased it was fixed.
I run the CE Appliance from the 25.1.1 ISO as a Proxmox VM, that has been updated as and when updates have become available. I have a second CE VM that also had the login issue but had not been updated since 5/11/25. All outstanding updates, available today, were applied and the server rebooted. Upon restart the server has logged in normally without having to resort to the systemctl fix. It seems odd that this issue is affecting some users more than others.

I am now just waiting for the overworked DEV's to fix the logs issue. I know I can access via the command line but it is easier and quicker to have a quick look via the GUI.

radza

Das Problem mit der Admin API ist bei mir eine klassische Race Condition gewesen..

Ich konnte es lösen indem ich eine override.conf in /etc/systemd/system/grommunio-admin-api.service.d/override.conf angelegt habe

Inhalt:

[Unit]
After=mariadb.service
Requires=mariadb.service

Danach mehrere Reboots. Problem trat nicht wieder auf.

Andy

radza Race Conditio

Ich habe das nun auch mal getestet, keine Änderung.

Andy

radza Race Condition

Ich hatte einen Fehler eingebaut. Mit der Berichtigung geht es jetzt.

Andy

Bei mir geht mit den aktuellen Updates die Admin nach wie vor nicht. Nur wenn ich die Vorkehrungen

radza Ich konnte es lösen indem ich eine override.conf in /etc/systemd/system/grommunio-admin-api.service.d/override.conf angelegt habe

Inhalt:

[Unit]
After=mariadb.service
Requires=mariadb.service

treffe, geht das wieder.

localhost:~ # rpm -qi gromox | head -n 3 && rpm -qa *grom* | sort
Name        : gromox
Version     : 3.2.2.mcf051aa
Release     : lp156.12.1
grommunio-admin-api-1.17.33.0a2d18a-lp156.7.1.noarch
grommunio-admin-common-44.9fd4fb3-lp156.47.1.noarch
grommunio-admin-web-4.0.0.23.19cacc8-lp156.145.1.noarch
grommunio-antispam-3.12.1-lp156.1.2.x86_64
grommunio-archive-1.3.13.g137.d1b0df1b-lp156.9.135.x86_64
grommunio-chat-9.11.17-lp156.10.1.x86_64
grommunio-common-29.5-lp156.10.1.x86_64
grommunio-cui-1.1.3.b0091e0-lp156.6.1.noarch
grommunio-dav-1.5.17.c1122c5-lp156.1.1.noarch
grommunio-dbconf-1.1.1.da20a46-lp156.13.2.x86_64
grommunio-error-pages-1.0.10.bb2df37-lp156.22.1.noarch
grommunio-files-31.0.9-lp156.12.1.noarch
grommunio-imapsync-2.290-lp156.1.1.noarch
grommunio-index-1.3.0.g2bd8a8c-lp156.15.3.x86_64
grommunio-office-7.4.1-lp156.6.35.x86_64
grommunio-office-fonts-7.4.1-lp156.6.35.noarch
grommunio-release-2025.1.2-lp156.3.1.x86_64
grommunio-setup-1.1.14.768d394-lp156.71.1.noarch
grommunio-sync-2.3.5.306a709-lp156.19.1.noarch
grommunio-web-3.15.89.gd1efa6e8f-lp156.363.2.noarch
gromox-3.2.2.mcf051aa-lp156.12.1.x86_64
gromox-debuginfo-3.2.2.mcf051aa-lp156.12.1.x86_64
gromox-debugsource-3.2.2.mcf051aa-lp156.12.1.x86_64
grub2-theme-grommunio-1-lp156.20.1.noarch
patterns-grommunio-1-lp156.9.1.x86_64
plymouth-theme-grommunio-1-lp156.20.1.noarch
systemd-coredump-grommunio-1-lp156.3.1.noarch
systemd-presets-branding-grommunio-2024.06-lp156.2.1.noarch
system-user-grommunio-10-lp156.6.1.noarch
system-user-gromox-9-lp156.6.1.noarch
You have new mail in /var/spool/mail/root
localhost:~ #

Andy

I performed the last update on November 1, and everything was fine after that. I tried to install the updates several times over the next few weeks, but the above error occurred every time. After almost 90 update packages had accumulated by yesterday, I accepted the compromise and updated to the current status. This morning, there was another admin-api, but unfortunately no change in this matter. So it seems that issue comes up in the last 2-3 weeks.

Otherwise, the VM is running perfectly fine.

Andy

WalterH Was hat nicht funktioniert?

Es ist nichts passiert, keine Fehler und keine Änderung. Aber mit dem Tip von @radza geht das jetzt.

WalterH

Andy Aber mit dem Tip von @radza geht das jetzt

Das muss man wieder ausbauen sobald die Entwickler das grundlegende Problem repariert haben. Bleibt das Override im System beeinflusst es dann vermutlich in Zukunft einmal den Startvorgang.

radza

WalterH

Grundsätzlich hast du damit recht. Aber es wäre wünschenswert dass die Entwickler meinen Workaround fest integrieren. Das Dienste, die in Abhängigkeit zu einander stehen, gegenseitig auf sich warten müssen ist ein Grundpfeiler robuster Softwareentwicklung. Dies ist hier nicht der Fall gewesen. Zumindest muss eine Prüfung statt finden oder eine Wiederholungsschleife, wenn die DB noch nicht rechtzeitig da ist beim starten des Admin API Dienstes.

ich habe trotzdem weiterhin dieses Problem. hat jemand eine Idee woran das liegen könnte?

[2025-11-26T08:29:03.213728] [6] (grommunio-admin-api): "ValueError: Invalid match" │ │ [2025-11-26T08:29:03.214593] [6] (grommunio-admin-api): "[WARNING] (grommunio Admin API) GET /api/v1/system/logs/Gromox smtp?n=100 from 172.18.20.129 -> 500 '{"message":"The server encountered an error while processing the request."}\n'" │ │ [2025-11-26T08:29:03.886631] [6] (grommunio-admin-api): "[ERROR] (grommunio Admin API) Traceback (most recent call last):" │ │ [2025-11-26T08:29:03.886631] [6] (grommunio-admin-api): " File "/usr/lib/python3.11/site-packages/flask/app.py", line 1484, in full_dispatch_request" │ │ [2025-11-26T08:29:03.886631] [6] (grommunio-admin-api): " rv = self.dispatch_request()" │ │ [2025-11-26T08:29:03.886631] [6] (grommunio-admin-api): " ^^^^^^^^^^^^^^^^^^^^^^^" │ │ [2025-11-26T08:29:03.886631] [6] (grommunio-admin-api): " File "/usr/lib/python3.11/site-packages/flask/app.py", line 1469, in dispatch_request" │ │ [2025-11-26T08:29:03.886631] [6] (grommunio-admin-api): " return self.ensure_sync(self.view_functions[rule.endpoint])(**view_args)" │ │ [2025-11-26T08:29:03.886631] [6] (grommunio-admin-api): " ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^" │ │ [2025-11-26T08:29:03.886631] [6] (grommunio-admin-api): " File "/usr/share/grommunio-admin-api/api/core.py", line 204, in wrapper" │ │ [2025-11-26T08:29:03.886631] [6] (grommunio-admin-api): " return call()" │ │ [2025-11-26T08:29:03.886631] [6] (grommunio-admin-api): " ^^^^^^" │ │ [2025-11-26T08:29:03.886631] [6] (grommunio-admin-api): " File "/usr/share/grommunio-admin-api/api/core.py", line 169, in call" │ │ [2025-11-26T08:29:03.886631] [6] (grommunio-admin-api): " ret = func(*args, **kwargs)"

WalterH

radza Aber es wäre wünschenswert dass die Entwickler meinen Workaround fest integrieren.

Ich gehe davon aus, das die Entwickler das tun werden, deshalb meine Meinung, das man das Override wieder ausbauen muss.

radza ich habe trotzdem weiterhin dieses Problem.

Das ist das 2. Problem, das gerade gesucht wird, soweit ich weis.

crpb

fwiw,

list files which are probably overrides

find /etc/systemd/system/*.d -type f

list loaded drop-in's

systemctl --state=active show |grep DropInPaths

unless edited with --full only look at the ones in /etc/...

revert to system defaults

systemctl revert foo.service

491810

Viel passiert hier während ich weg war. Wow. Ich habe eben den wievielten Update gemacht. Gab 15 neue Pakete. Nach dem Neustart musste ich zwar den Grommunio-admin-api neu starten (manchmal ja -manchmal nicht nötig). Nach der Anmeldung ging jetzt auch das Laden der Logs in der Überwachung wieder. 🥳

WalterH

491810 Nach der Anmeldung ging jetzt auch das Laden der Logs in der Überwachung wieder.

Aber nur in der Community Edition, ist in der Supported noch nicht repariert.

« Previous Page Next Page »