Mails nicht verwerfen, wenn nicht zustellbar

UCS - Univention Corporate Server
, ,
#21

Also irgenwie scheinen die Ausgaben von service kopano-server status nicht zu stimmen, die Meldung nach dem Start passt zum Stoppen, die nach dem Stoppen meldet, ‘failed’ seit 22h. Alle anderen Ausgaben sehen ok aus.

#22

Danke für die Tipps bei der Suche nach der Ursache - aber was kann ich jetzt machen? Irgendwie scheint ja was in den Start/Stop-Scripten nicht zu passen, oder?

Welche Infos wären noch hilfreich von meiner Seite, damit man genauer die Ursache erkennen und (so hoffe ich doch) beheben kann?

#23

Moin,

nochmal systemctl stop kopano-server, mit ps pruefen, ob der Prozess wirklich weg ist. Dann im Logfile nachsehen, ob dort auch der Shutdown korrekt vermerkt ist. Dann nochmal nachsehen, ob der Status immernoch falsch angezeigt wird.

#24

Dieser Befehl stop den Server leider nicht - darum wahrscheinlich auch die Folgefehler.

Ich habe mit ps -C kopano-server überprüft, ob der Dienst noch läuft und bekomme folgende Meldung:

root@ucs002090:~# ps -C kopano-server
  PID TTY          TIME CMD
 4994 ?        00:05:17 kopano-server

Auch das Anmeldun an der Web-UI funktioniert weiterhin. Darum scheint das Problem also das nicht-beenden des Prozesses zu sein.

#25

Moin,

stimmt die mit systemctl status kopano-server angezeigte Pid mit der durch ps ermittelten ueberein?

#26

So wie es aussieht nicht - Irgendwie kann es wohl sein, dass hier “doppeltes” Kopano läuft?

root@ucs002090:~# systemctl status kopano-server
● kopano-server.service - Kopano Core Storage Server
   Loaded: loaded (/lib/systemd/system/kopano-server.service; enabled)
   Active: failed (Result: exit-code) since Mo 2018-04-30 17:43:42 CEST; 3 days ago
     Docs: man:kopano-server(8)
           man:kopano-server.cfg(5)
           man:kopano-admin(8)
  Process: 2529 ExecStart=/usr/sbin/kopano-server -F (code=exited, status=255)
 Main PID: 2529 (code=exited, status=255)

Apr 30 17:43:37 ucs002090 systemd[1]: Starting Kopano Core Storage Server...
Apr 30 17:43:37 ucs002090 systemd[1]: Started Kopano Core Storage Server.
Apr 30 17:43:42 ucs002090 kopano-server[2529]: An error occurred (80000007). Please check logfile "/var/log/kopano/server.log" for details.
Apr 30 17:43:42 ucs002090 systemd[1]: kopano-server.service: main process exited, code=exited, status=255/n/a
Apr 30 17:43:42 ucs002090 systemd[1]: Unit kopano-server.service entered failed state.
Mai 04 14:02:37 ucs002090 systemd[1]: Stopped Kopano Core Storage Server.

Seit dem habe ich Kopano offen und bekomme auch Mails rein - was ja nicht sein kann, da der Storage Server gestoppt ist

Vielleicht noch als Erklärung: Wenn ich den Server (Hardware) neustarte, dann klappt es mit dem Kopano-Server nicht, weil MySQL noch nicht bereit ist - hab zwar schon das eine oder andere versucht, aber leider keine Abhilfe. Danach muss ich also nochmal manuell service kopano-server start eingeben, dann funktioniert alles wie gewohnt. Liegt daran vielleicht der Fehler?

#27

Moin,

die Status Meldung ist wertlos, da sie ja den Fehlversuch, wo schon ein kopano-server Prozess lief, zeigt. Dass es die Pid nicht mehr gibt ist klar.

Nach einem Reboot ist kopano-server sicher nicht da? Auch mit ps geprueft?
Was sagt dann der Status und was nach dem manuellen Start?

#28

Hier die einzelnen Schritte nach einem kompletten Reboot

root@ucs002090:~# ps -C kopano-server
  PID TTY          TIME CMD
root@ucs002090:~# systemctl status kopano-server
● kopano-server.service - Kopano Core Storage Server
   Loaded: loaded (/lib/systemd/system/kopano-server.service; enabled)
   Active: failed (Result: exit-code) since Fr 2018-05-04 17:38:10 CEST; 1min 5s ago
     Docs: man:kopano-server(8)
           man:kopano-server.cfg(5)
           man:kopano-admin(8)
  Process: 2448 ExecStart=/usr/sbin/kopano-server -F (code=exited, status=255)
 Main PID: 2448 (code=exited, status=255)

Mai 04 17:38:19 ucs002090 kopano-server[2448]: An error occurred (80000007). Please check logfile "/var/log/kopano/server.log" for details.
root@ucs002090:~# ps -C kopano-server
  PID TTY          TIME CMD
root@ucs002090:~# service kopano-server start
root@ucs002090:~# ps -C kopano-server
  PID TTY          TIME CMD
 4044 ?        00:00:00 kopano-server
root@ucs002090:~# systemctl status kopano-server
● kopano-server.service - Kopano Core Storage Server
   Loaded: loaded (/lib/systemd/system/kopano-server.service; enabled)
   Active: active (running) since Fr 2018-05-04 17:40:33 CEST; 12s ago
     Docs: man:kopano-server(8)
           man:kopano-server.cfg(5)
           man:kopano-admin(8)
 Main PID: 4044 (kopano-server)
   CGroup: /system.slice/kopano-server.service
           └─4044 /usr/sbin/kopano-server -F

Mai 04 17:40:33 ucs002090 systemd[1]: Started Kopano Core Storage Server.
root@ucs002090:~#
#29

ich glaube Softbounce ist gesucht, auch wenn es natürlich nicht das eigentliche Problem behebt:
https://docs.software-univention.de/handbuch-4.4.html#mail::serverconfig::softbounce

#30

Ja, ich würde Softbounce auch empfehlen und wundere mich, dass es eigentlich nicht Default beim UCS Mailstack (im Zusammenspiel mit nachgelagerter Groupware wie Kopano) ist. Denn ich hatte leider auch schon Situationen, wo Kopano nach einem nicht korrektem / unvollständigem Update keine Mails von Postfix übernahm, Postfix bouncte, aber diese Bounces wegen (sinnvollem) NDN / backscatter Verbot beim Provider-Relay nicht mal beim Sender ankamen.

English translation:
Yes, I would also recommend Softbounce and wonder why it is not the default for the UCS mailstack (in combination with downstream groupware like Kopano). Because I already had situations where Kopano didn’t take over any mails from Postfix after an incorrect / incomplete update, Postfix bounced, but these bounces didn’t even reach the provider relay because of (reasonable) NDN / backscatter prohibition.

VG / regards Robert

Mastodon