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

crpb

Andy Das ist klar, dennoch ist ein Updaten und Feststellen, dass etwas faul ist, meist Minutensache. Und weil ich nicht sicher bin, dass eine neue Version funktioniert, mache ich das mit klonen, dann habe ich immer einen kompletten Bestand. Klar ist der Zeitpunkt wichtig, wenn am wenigsten oder ggf. unwichtiger Mailverkehr ist.

Der Fehler mit der admin-api ist mir schon seit nem halben jahr bekannt. Seitdem gab es schon mehrere updates also bringt dein snapshot/upgrade/zurückrollen hier nur so viel das es da gerade funktioniert aber eigtl. den selben fehler schon inne haben sollte und du glück hast das es nicht ständig auftritt.

high

crpb
du hast recht. der Fehler ist aber auch nicht Kritsch, wenn ich an die aktuelle Themen denke wird der auch nicht priorisiert da der Restart ja hilft..

Andy

high der Fehler ist aber auch nicht Kritsch

Wenn ich aktuell sehe, wieviel Updates von SuSE und Grommunio aufgelaufen sind, sehe ich das anders. Dieser Mist hält doch alles nur auf.

491810 Dann hilft nur noch Dienst stoppen und wieder starten

Das ist keine Lösung.

491810

Also. Meine Endgeräte gehen (wieder). An der Admin-Api kann man sich manchmal nach einen Reboot nicht mehr anmelden. Dann hilft nur noch Dienst stoppen und wieder starten.

Die Basisfrage dieses Postings ist aber noch offen. Hat jemand eine Lösung für den Error in der Überwachung gefunden (ja, man kann die Logs auch im Terminal abrufen)? Ich habe jetzt schon x-Updates seitdem durch. Noch keine Verbesserung. Weiß jemand, ob das Problem a.) gemeldet ist und b.) ob bzw. wann Grommunio eine Lösung bereitstellt? Vielen Dank.

WalterH

a, es gibt Tickets dazu, b. die Entwickler arbeiten daran,

WalterH

Ich habe das bei mir auf 2 Servern kontrolliert. Beide Server sind auf 3.1.40 Supported Edition. Nach dem Reboot starten alle Dienste wie erwartet und auch über das Web Interface https://server:8443 kann ich in das Admin-UI einloggen.

Ein Restart vom Admin-UI dauert aber recht lange: systemctl restart grommunio-admin-api

Das einzige was das Update nicht installieren will, sind diese Pakete:

The following 4 package updates will NOT be installed:
systemd systemd-coredump systemd-sysvcompat udev

Das muss ich noch untersuchen, wieso diese Pakete geblockt werden.

Andy

WalterH systemctl restart grommunio-admin-api

Wie und wo müsste ein cron Eintrag erfolgen, der nach dem Boot der VM systemctl restart grommunio-admin-api ausführt, dann hätte man zumindest eine Möglichkeit, damit umzugehen. Im Zweifel wärs in der /etc/crontab

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.

DVCon

Von den drei Servern, bei denen Admin-UI und Monitoring das Update auf 3.1 überlebt hatten, ist nach den Folge-Updates nur noch einer übrig geblieben.

WalterH

Im Zweifelsfall das uwsgi-2.0.19.1-150400.8.3.1.x86_64.rpm manuell auf die Server laden und als oldpackage darüber installieren. Dann läuft das Admin-UI wieder.

DVCon

WalterH
Danke.
Ich habe es mal mit einem Test-Server versucht. Es scheint aber nicht ganz so einfach zu sein

localhost:~ # rpm -Uvh --oldpackage uwsgi-2.0.19.1-150400.8.3.1.x86_64.rpm error: Failed dependencies: uwsgi = 2.0.31 is needed by (installed) python311-uwsgi-python3-2.0.31-lp156.1.3.x86_64 localhost:~ # rpm -e --nodeps python311-uwsgi-python3-2.0.31-lp156.1.3.x86_64 localhost:~ # rpm -Uvh --oldpackage uwsgi-2.0.19.1-150400.8.3.1.x86_64.rpm Preparing... ################################# [100%] Updating / installing... 1:uwsgi-2.0.19.1-150400.8.3.1 ################################# [ 50%] Cleaning up / removing... 2:uwsgi-2.0.31-lp156.1.3 ################################# [100%] localhost:~ # rpm -i uwsgi-python3-2.0.19.1-150400.8.3.1.x86_64.rpm error: Failed dependencies: uwsgi-python3 is obsoleted by (installed) grommunio-admin-api-1.17.32.021a23c-lp156.2.1.noarch localhost:~ # rpm -i --nodeps uwsgi-python3-2.0.19.1-150400.8.3.1.x86_64.rpm

Danach endet das Experiment mit "Could not connect to backend" beim Anmelden am Admin-UI.

WalterH

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

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

Sollte dann so aussehen:

# cat /etc/cron.d/grommunio-admin-api
@reboot root sleep 30; /usr/bin/systemctl restart grommunio-admin-api

WalterH

Heute wurde die grommunio-admin-api-1.17.33.0a2d18a freigegeben, muss man testen ob die hilft.

Andy

Leider nicht, keine Änderung. Ich werde aber mal den cron testen.

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?

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.

« Previous Page Next Page »