Probleme im Zusammenhang mit Virenscannern
Wir raten dringend, für Virenscanner generell eine Ausnahme für sämtliche Scanzugriffe auf die SEAL Installationsverzeichnisse (in der Regel D:\SEAL\*) hinzuzufügen.
Eine Ausnahme für einzelne Prozesse ist nicht empfehlenswert, da dieses mehrere Hundert exe Dateien betreffen würde.
Es kann trotz einer derartigen Ausnahme zu Scanzugriffen des Virenscanners auf diese ausgenommenen Unterverzeichnisse kommen, was dann zu folgenden Problemen führen kann:
Performanceprobleme bei der Verarbeitung / Übertragung
Die Datenbank postgreSQL kommt in einen Deadlock
JBoss reagiert nicht mehr, die Jobs werden aus den Eingangsverzeichnissen (gates) entfernt, tauchen aber nicht in der Ocon auf.
Konvertierungen in PLOSSYS 4 und DPF bleiben im Status Konvertierung
PDF Tools wie z.B. pdfprae.exe bleiben hängen
MS Office Konvertierungen beenden sich nicht - die MS Office Applikation wird nicht mehr geschlossen
GNU tar für Windows kann nicht mehr gestartet werden (Exception)
Sollten Sie CheckMK einsetzen, so empfehlen wir, dieses zuerst testweise zu deaktivieren. Sollten dann keine Probleme mehr auftreten, prüfen Sie, ob ein Update für CheckMK bereitsteht. Bei einem Kunden löste ein Update des Check MK Windows Agent auf die Version 1.6.0p22 das Problem.
Für die PLOSSYS Output Engine empfehlen wir, folgende Verzeichnisse von Scans auszunehmen:
%ProgramFiles%\SEAL Systems\PLOSSYS\
C:\Windows\ServiceProfiles\LocalService\AppData\Local\Temp\ghost\
C:\Windows\ServiceProfiles\LocalService\AppData\Local\Temp\pdf2ps\
C:\Windows\ServiceProfiles\LocalService\AppData\Local\Temp\pdfstamp\
C:\Windows\ServiceProfiles\LocalService\AppData\Local\Temp\ps2pdf\
C:\Windows\ServiceProfiles\LocalService\AppData\Local\Temp\sapgof\
Weiter sollten noch die jeweiligen ausführbaren Programmdateien unter "C:\Program Files\SEAL Systems" von Scans ausgenommen werden, z.B. nodejs.exe, mongodb.exe, consul.exe, nssm.exe, etc.
Eine Möglichkeit um zu prüfen ob die Ausnahme von Verzeichnissen beim Virenscan funktioniert, ist das SEAL Testscript am Ende dieses Artikels.
Auch wenn dieser Test negativ ausfällt, ist es weiter möglich, dass die Probleme mit dem Virenscanner zusammenhängen. Hier ein Screenshot bei dem auf dem Server der Virenscanner trotz einer Ausnahme für das entsprechende Verzeichnis aktiv ist. Der EICAR Test war ebenfalls negativ. Zur Analyse wurden die aktiven Windows Prozesse mit dem Process Monitor geprüft. Dieser ist direkt von Microsoft erhältlich.
Um eine gute Übersicht im Process Monitor zu bekommen, ist es empfehlenswert, alle Quellen außer der „File System Activity“ auszuschließen.
Weiter sollte über den Process Monitor Filter (Filter->Filter, <CTRL>-<L> oder klick auf das entsprechende icon) ein Filter auf das ..\data\ Verzeichnis gesetzt werden.
Falls bekannt ist, wie der Virenscanner Prozess heißt, kann selbstverständlich auch nur nach diesem gefiltert werden.
Eine Folge von solchen Virenscanner Aktivitäten können langsame Datenbankzugriffe sein. Dieses ist in den postgresql Logdateien zu sehen.
Wenn die Datenbankabfragen ungewöhnlich lange dauern, kann es dazu führen, dass der watchdog einschreitet. Im Gegensatz zu allen anderen Prozessen verwendet der watchdog eine query mit Timeout um den Prozess nicht zu blockieren.
Wenn dieser Timeout (Default-Wert 10sec) überschritten wird, dann wird die dpf mittels dpfrestart neu gestartet, was zu den Einträgen im postgresql-Log führt (10061 Connection refused, bzw. 10054 Connection reset by peer), da die postgres Verbindungen zum processmanager, workingunitmanager und jobcleaner nicht sauber geschlossen werden, sondern abreißen - dpfrestart ist nicht gerade zimperlich.
Das heißt auch wenn der Fehler im postgresql Logfile steht, handelt es sich bei diesem Eintrag nicht um einen Fehler von postgresql, sondern mehr um einen Hilferuf.
Die Datenbank arbeitet mit WAL-Dateien (Write-Ahead-Log), d.h. um einen COMMIT auszuführen, muss die Information in der WAL geschrieben sein.
Falls auf dieser Datei der Virenscanner aktiv ist, so kann der COMMIT statt weniger Nanosekunden gleich mal ein paar Sekunden dauern.
Dieses bedeutet in Folge dass die Performance der Datenbank bis zur Unbenutzbarkeit (Prozesse brechen ab) stark abfällt, da der Timeout für SQL niemals so hoch eingestellt ist.
Die Kombination wie einige Virenscanner nach Viren suchen und dabei binaries und Dateien sperren und das trügerische Verhalten, ausgenommene Unterverzeichnissen zu ignorieren und dennoch zu scannen, geben uns als Softwarehersteller keinen Lösungsansatz oder Workaround. Nach einem Neustart unserer Systeme tritt bei gleichen Voraussetzungen der Fehler nicht mehr auf, dafür kann ein anderer Prozess einige Tage später betroffen sein. Das Problem tritt sowohl in eigener Software (z.B. DPF, PLOSSYS 4) als auch in Fremdsoftware (z.B. PDF Tools, postgreSQL, JBOSS) auf.
Sollten Sie betroffen sein, melden Sie das Problem bitte dem Hersteller.
Bei den oben beschriebenen sporadischen Problemen also immer prüfen, ob ein Antivirus Programm auf Ihren Servern vorhanden ist und, wenn möglich, dieses mindestens zum Testen deaktivieren.
Stellen Sie auch bitte sicher, dass das Antivirus Programm die neuesten Signaturen verwendet.
Testscript
SEAL Systems stellt ein Script bereit, mit dem geprüft werden kann, ob die von der SEAL Software verwendeten Verzeichnisse von Virenscannern ausgenommen sind.
Installieren Sie das erforderliche Package (unten an dieser FAQ angehängt) wie in folgender FAQ beschrieben: Package über eine SEAL-Shell installieren / deinstallieren
Usage
Öffnen Sie eine SEAL Shell.
Starten Sie den Test mit: testscan -s
Der Test dauert ca. 2 Minuten
Entfernen Sie die Testdateien mit: testscan -x
Folgende Ergebnisse für die Dateien können auftreten:
exists - everything fine
not readable! - file exists, but cannot be active
lost! - file got lost, check installation prerequisites
“Not readable” und “lost” deuten darauf hin, dass der Virenscanner auf den angezeigten Verzeichnissen aktiv ist.