Cron <root@ucs3> test -x /usr/sbin/anacron || ( cd / && run-parts --report /etc/cron.daily )

Hallo seit einiger Zeit bekomme ich jeden Morgen (Zeiten variieren - jedoch immer in den Morgenstunden zuwischen 5 und 7) die folgende Meldung von einem UCS System. Auf dem System läuft läuft Kopano Core. Von den anderen UCS Systemen erhalte ich keine Meldungen.

Subject:
Cron <root@ucs3> test -x /usr/sbin/anacron || ( cd / && run-parts --report /etc/cron.daily )

Body:
/etc/cron.daily/spamassassin:
Job for spamassassin.service failed. See 'systemctl status spamassassin.service' and 'journalctl -xn' for details.
invoke-rc.d: initscript spamassassin, action "reload" failed.

xxx

Vielleicht hilft diese Information noch:

kopanobackup@ucs3:~# systemctl status spamassassin.service
● spamassassin.service - Perl-based spam filter using text analysis
   Loaded: loaded (/lib/systemd/system/spamassassin.service; disabled)
   Active: inactive (dead)

Dec 22 07:21:27 ucs3 systemd[1]: Unit spamassassin.service cannot be ....
Dec 23 07:04:47 ucs3 systemd[1]: Unit spamassassin.service cannot be ....
Dec 24 07:22:54 ucs3 systemd[1]: Unit spamassassin.service cannot be ....
Dec 25 06:50:42 ucs3 systemd[1]: Unit spamassassin.service cannot be ....
Dec 26 06:48:30 ucs3 systemd[1]: Unit spamassassin.service cannot be ....
Dec 27 06:33:56 ucs3 systemd[1]: Unit spamassassin.service cannot be ....
Hint: Some lines were ellipsized, use -l to show in full.

Oder diese Info:

kopanobackup@ucs3:~# systemctl status spamassassin.service -l
● spamassassin.service - Perl-based spam filter using text analysis
   Loaded: loaded (/lib/systemd/system/spamassassin.service; disabled)
   Active: inactive (dead)

Dec 27 06:33:56 ucs3 systemd[1]: Unit spamassassin.service cannot be reloaded because it is inactive.

Der Spamassassin Dienst ist auf dem System - unter Systemdiensten - als gestoppt (automatisch) markiert. Da ich das selber nicht verändert habe, gehe ich mal davon aus, dass dies so sein muss - oder ein Patch hier etwas verändert hat, wenn denn der Dienst nicht auf gestoppt/automatisch stehen soll.

Wie sieht dnn hier die richtige Einstellung aus - oder was muss ich tun damitz diese täglichen Meldungen nicht mehr kommen?

Vielen Dank vorab

Pepe

ucs3 --> 4.2-3 errata254 (Lesum)

Hallo @Pepe

wurde das System nach dem Upgrade auf 4.2 schon einmal neu gestartet?
Ist SpamAssassin überhaupt richtig installiert?

root@ucs:~# dpkg -l spamassassin
root@ucs:~# dpkg --audit

Läuft vlt. noch ein Prozess?

root@ucs:~# pgrep spamassassin
root@ucs:~# ps aufx | grep [s]pamassassin

root@ucs:~# pkill spamassassin

Gruß Nico

Danke Nico für die schnelle Rückmeldung.

Folgendes Feedback auf Deine Fragen:

Ja das System wird regelmäßig neu gestartet - vor jedem und nach jedem Patchen.

root@vmucs42-rd4:~# dpkg -l spamassassin
Desired=Unknown/Install/Remove/Purge/Hold
| Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend
|/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad)
||/ Name           Version      Architecture Description
+++-==============-============-============-=================================
un  spamassassin   <none>       <none>       (no description available)
root@vmucs42-rd4:~#
root@vmucs42-rd4:~#
root@vmucs42-rd4:~# dpkg --audit
root@vmucs42-rd4:~#

Gehe ich recht in der Annahme, dass die Meldungen vom System darauf hindeuten, dass Spamassassin gar nicht installiert ist?

Wenn das so ist, bleibt die Frage - ist das so richtig das das Tool fehlt - wenn ja, warum erhalte ich denn erst seit einigen Wochen diese Fehlermeldung?

Anyway - ich denke wir sind einen Schritt weiter - und dafür schon mal Danke.

Beste Grüße
Pepe

Hallo,

habe hier auf zwei UCS-Systemen die gleiche Meldung.

root@server2:~# dpkg -l spamassassin
Gewünscht=Unbekannt/Installieren/R=Entfernen/P=Vollständig Löschen/Halten
| Status=Nicht/Installiert/Config/U=Entpackt/halb konFiguriert/
         Halb installiert/Trigger erWartet/Trigger anhängig
|/ Fehler?=(kein)/R=Neuinstallation notwendig (Status, Fehler: GROSS=schlecht)
||/ Name                                              Version                       Architektur                   Beschreibung
+++-=================================================-=============================-=============================-=======================================================================================================
ii  spamassassin                                      3.4.0-6                       all                           Perl-based spam filter using text analysis

Bei mir ist Spamassassin also sauber installiert.

root@server2:/var/log# systemctl status spamassassin.service
● spamassassin.service - Perl-based spam filter using text analysis
   Loaded: loaded (/lib/systemd/system/spamassassin.service; disabled)
   Active: inactive (dead)

Dez 28 07:14:20 server2 systemd[1]: Unit spamassassin.service cannot be reloaded because it is inactive.
Dez 29 07:06:45 server2 systemd[1]: Unit spamassassin.service cannot be reloaded because it is inactive.
Dez 30 07:18:50 server2 systemd[1]: Unit spamassassin.service cannot be reloaded because it is inactive.
Dez 31 06:43:27 server2 systemd[1]: Unit spamassassin.service cannot be reloaded because it is inactive.
Jan 01 06:43:03 server2 systemd[1]: Unit spamassassin.service cannot be reloaded because it is inactive.
Jan 02 06:57:48 server2 systemd[1]: Unit spamassassin.service cannot be reloaded because it is inactive.

So wie ich das aus anderen Meldungen im Internet entnommen habe, läuft Spamassassin nicht als Dienst, sondern ist direkt in Amavis eingebunden. In /etc/cron.daily/spamassassin müsste quasi der Reload des Spamassassin-Dienstes entfernt werden. Das Problem müsste damit doch bei allen UCS 4.2 Servern mit installiertem Spamassassin auftreten.

Tschüss,
Daniel

Wie ist die Meinung von Seiten Univention?
Was ist die richtige Lösung, um diese nervige Mail loszuwerden?

Vielen Dank für die Antwort im Voraus,
Daniel

Uns würde auch interessieren ob nicht der Amavis neu gestartet werden muss, wenn der SpamAssasin neue Regeln bekommt. vgl: Spamd Dienst notwendig?

Guten Tag,

ich möchte nur melden, dass wir hier seit dem Upgrade auf UCS 4.2.-x exakt dasselbe Problem haben.
Zunächst bin ich davon ausgegangen, dass dies an unserer geänderten Konfiguration liegt, welche auch Office-Dokumente mit VBA/Makros filtert. Dem ist aber nicht so - es ist ein Problem, welches wohl auf allen Systemen nach dem Upgrade bestehen dürfte.

MBG,
TP

SpamAssassin wird von Amavis gestartet und läuft nicht selbstständig als Dienst. Der Reload im default-Script ist daher nicht korrekt und kann in Restart geändert werden. Es ist aber letztlich nur eine kosmetische Sache, weil der SpamAssassin diesen Reload gar nicht benötigt - er läuft ja eben nur on demand.

Mit folgendem Patch kann das Verhalten geändert werden.

root@ucs:~# patch -d /etc/cron.daily/ spamassassin spamassassin.patch
Hier der Patch
--- spamassassin.orig	2018-01-15 10:23:21.418661347 +0100
+++ spamassassin	2018-01-15 10:24:51.230641496 +0100
@@ -49,9 +49,9 @@
 reload() {
     # Reload
     if which invoke-rc.d >/dev/null 2>&1; then
-        invoke-rc.d spamassassin reload > /dev/null
+        invoke-rc.d spamassassin restart > /dev/null
     else
-        /etc/init.d/spamassassin reload > /dev/null
+        /etc/init.d/spamassassin restart > /dev/null
     fi
     if [ -d /etc/spamassassin/sa-update-hooks.d ]; then
         run-parts --lsbsysinit /etc/spamassassin/sa-update-hooks.d

Jetzt wird der SpamAssassin neu gestartet und direkt wieder beendet anstatt dass ein erfolgloser Reload auf einen nicht laufenden Dienst versucht wird.

1 Like

Hi @Pepe,

SpamAssassin sollte eigentlich™ nicht deinstalliert sein, mir ist auch nicht bekannt, dass das bei einem Update/Upgrade schon mal passiert sei. Wie Du ja aus dem weiteren Threadverlauf entnehmen kannst liegt die Meldung nicht am entfernten Paket. Solltest Du den SpamCheck für Postfix verwenden wollen solltest Du SpamAssassin wieder installieren. Dabei besteht folgende Paketfolge:

(univention-mail-server), univention-antivir-mail → univention-spamassassin → spamassassin

Prüf doch bitte zunächst den Paketstatus

root@ucs:~# dpkg -l spamassassin univention-spamassassin univention-antivir-mail univention-mail-server

Über folgenden Aufruf kann SpamAssassin dann wieder sauber nachinstalliert werden:

root@ucs:~# univention-install univention-spamassassin

Hallo,
laut meiner Kontrolle der Datei wird der Patch korrekt geschrieben, auch wenn diese

root@ucs:~# patch -d /etc/cron.daily/ spamassassin spamassassin.patch
(Stripping trailing CRs from patch; use --binary to disable.)
patching file spamassassin
patch unexpectedly ends in middle of line
Hunk #1 succeeded at 49 with fuzz 1.
root@ucs:~#

Meldung ausgeworfen wird.

MBG,
TP

Hallo @stoeckigt,

ich sehe das in diesem Thread beschriebene Problem auch auf einem System.
Kommt die Lösung ins Produkt oder sollen wir manuell patchen?
Im Bugzilla habe ich keinen passenden Eintrag gefunden.

Viele Grüße,
Dirk Ahrnke

Sorry das ich mich erst jetzt selber zurückmelde - aber es gibt ja “zum Glück” noch ein paar andere die auch dieses Problem haben :wink:

Anyhow - weder installiere noch deinstalliere ich von Hand einzelne Pakete. Das System wurde mit Hilfe des ISOs so neu installiert - und nur um das Paket Kopano Core ergänzt.

Möchte also auch ungerne etwas von Hand nachinstallieren, wenn es nicht in ein Paket gehört das als Update von Univention gestellt wird.

Ich habe einmal den Befehl “dpkg -l spamassassin univention-spamassassi” eingegeben

kopanobackup@ucs3:~# dpkg -l spamassassin univention-spamassassin
Desired=Unknown/Install/Remove/Purge/Hold
| Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend
|/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad)
||/ Name Version Architecture Description
++±==============-============-============-=================================
ii spamassassin 3.4.0-6 all Perl-based spam filter using text
ii univention-spa 8.0.0-2A~4.2 all UCS - mail antispam

Würde mich also wie dei anderen acuh über einen Fix über die Updateverteilung freuen.

Vielen Dank vorab
Pepe

Ich bin jetzt nicht zu 100% sicher, aber es sieht für mich danach aus, als wäre das Problem in Upstream.
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=774380
Damit käme dann der eigentliche Fix mit Debian 9 / UCS 4.3.

Mastodon