- Ubuntu 14.04
- Clamav 0,98,7
Das Problem wird clamav-daemon
fast täglich neu gestartet:
Sep 1 06:30:00 x-master clamd[6778]: Pid file removed.
clamd[6778]: --- Stopped at Tue Sep 1 06:30:00 2015
clamd[5979]: clamd daemon 0.98.7 (OS: linux-gnu, ARCH: x86_64, CPU: x86_64)
clamd[5979]: Running as user root (UID 0, GID 0)
clamd[5979]: Log file size limited to 4294967295 bytes.
clamd[5979]: Reading databases from /var/lib/clamav
clamd[5979]: Not loading PUA signatures.
clamd[5979]: Bytecode: Security mode set to "TrustSigned".
Es wurde ein Problem verursacht, wenn ausgeführt clamdscan
wird:
/etc/cron.daily/clamav_scan:
ERROR: Could not connect to clamd on x.x.x.x: Connection refused
Beachten Sie, dass ich am Anfang "fast" gesagt habe:
/var/log/syslog:Sep 1 06:30:00 x-master clamd[6778]: Pid file removed.
/var/log/syslog.1:Aug 31 06:27:54 x-master clamd[20128]: Pid file removed.
/var/log/syslog.4.gz:Aug 28 06:28:34 x-master clamd[4475]: Pid file removed.
/var/log/syslog.5.gz:Aug 27 06:27:47 x-master clamd[21466]: Pid file removed.
Wie du sehen kannst:
- es geschah nicht am 29. und 30. August
es oft um die 6.27 neu gestartet , die die Zeit
cron.daily
ist Lauf27 6 * * * root nice -n 19 ionice -c3 run-parts --report /etc/cron.daily
Der Inhalt von /etc/cron.daily/clamav_scan
:
find / $exclude_string ! \( -path "/tmp/clamav-*.tmp" -prune \) ! \( -path "/var/lib/elasticsearch" -prune \) ! \( -path "/var/lib/mongodb" -prune \) ! \( -path "/var/lib/graylog-server" -prune \) -mtime -1 -type f -print0 | xargs -0 clamdscan --quiet -l "$status_file" || retval=$?
Es gibt eine Logrotate-Datei für clamav-daemon:
/var/log/clamav/clamav.log {
rotate 12
weekly
compress
delaycompress
create 640 clamav adm
postrotate
/etc/init.d/clamav-daemon reload-log > /dev/null
endscript
}
aber es lädt nur das Protokoll neu:
Sep 1 02:30:24 uba-master clamd[6778]: SIGHUP caught: re-opening log file.
Ich weiß, dass wir auditd
die Binärdatei überwachen können , und hier ist ein Beispielprotokoll:
ausearch -f /usr/sbin/clamd [2/178]
----
time->Tue Sep 1 07:56:44 2015
type=PATH msg=audit(1441094204.559:15): item=1 name=(null) inode=2756458 dev=fc:00 mode=0100755 ouid=0 ogid=0 rdev=00:00
type=PATH msg=audit(1441094204.559:15): item=0 name="/usr/sbin/clamd" inode=3428628 dev=fc:00 mode=0100755 ouid=0 ogid=0 rdev=00:00
type=CWD msg=audit(1441094204.559:15): cwd="/"
type=EXECVE msg=audit(1441094204.559:15): argc=1 a0="/usr/sbin/clamd"
type=SYSCALL msg=audit(1441094204.559:15): arch=c000003e syscall=59 success=yes exit=0 a0=7ffd277e03dc a1=7ffd277dfa78 a2=7ffd277dfa88 a3=7ffd277df570 items=2
ppid=5708 pid=5946 auid=4294967295 uid=109 gid=114 euid=109 suid=109 fsuid=109 egid=114 sgid=114 fsgid=114 tty=pts1 ses=4294967295 comm="clamd" exe="/usr/sbin/clamd" key=(null)
109 ist die UID von ... clamav
Benutzer:
getent passwd clamav clamav:x:109:114::/var/lib/clamav:/bin/false
Gibt es in diesem Fall eine andere Möglichkeit zur Fehlerbehebung?
Antwort an @HBruijn:
Möglicherweise Freshclam nach dem Aktualisieren der AV-Definitionen?
Ich habe darüber nachgedacht. Hier ist das Protokoll:
Sep 1 05:31:04 x-master freshclam[16197]: Received signal: wake up
Sep 1 05:31:04 x-master freshclam[16197]: ClamAV update process started at Tue Sep 1 05:31:04 2015
Sep 1 05:31:04 x-master freshclam[16197]: main.cvd is up to date (version: 55, sigs: 2424225, f-level: 60, builder: neo)
Sep 1 05:31:05 x-master freshclam[16197]: Downloading daily-20865.cdiff [100%]
Sep 1 05:31:09 x-master freshclam[16197]: daily.cld updated (version: 20865, sigs: 1555338, f-level: 63, builder: neo)
Sep 1 05:31:10 x-master freshclam[16197]: bytecode.cvd is up to date (version: 268, sigs: 47, f-level: 63, builder: anvilleg)
Sep 1 05:31:13 x-master freshclam[16197]: Database updated (3979610 signatures) from db.local.clamav.net (IP: 168.143.19.95)
Sep 1 05:31:13 x-master freshclam[16197]: Clamd successfully notified about the update.
Sep 1 05:31:13 x-master freshclam[16197]: --------------------------------------
Sep 1 04:34:10 x-master clamd[6778]: SelfCheck: Database status OK.
Sep 1 05:31:13 x-master clamd[6778]: Reading databases from /var/lib/clamav
Sep 1 05:31:22 x-master clamd[6778]: Database correctly reloaded (3974071 signatures)
Ich bin mir nicht sicher, aber es sieht so aus, als hätte freshclam einen "internen Mechanismus", um clamd über das Update zu informieren. Danach kann die Datenbank einfach neu geladen werden, ohne dass der Prozess neu gestartet werden muss. Kannst du bestätigen?
Außerdem habe ich anhand des Zeitstempels gesehen, dass der Clamav-Daemon eine Stunde nach der Aktualisierung der Freshclam-Datenbank neu gestartet wurde. Es ist normal?
UPDATE Di Sep 1 22:10:49 ICT 2015
Es sieht jedoch so aus, als hätte Freshclam einen "internen Mechanismus", um Clamd über das Update zu informieren. Danach kann die Datenbank einfach neu geladen werden, ohne dass der Prozess neu gestartet werden muss.
Ich kann dies durch einen Test bestätigen:
- Bearbeiten Sie die Datei freshclam.conf, um das Intervall auf Minuten zu ändern (
Checks 1440
) - Starten Sie Clamav-Freshclam neu
- cd / var / lib / clamav
- rm daily.cvd
warte eine Minute
Sep 1 14:49:25 p freshclam[7654]: Downloading daily.cvd [100%] Sep 1 14:49:28 p freshclam[7654]: daily.cvd updated (version: 19487, sigs: 1191913, f-level: 63, builder: neo) Sep 1 14:49:28 p freshclam[7654]: Reading CVD header (bytecode.cvd): Sep 1 14:49:28 p freshclam[7654]: OK Sep 1 14:49:28 p freshclam[7654]: bytecode.cvd is up to date (version: 245, sigs: 43, f-level: 63, builder: dgoddard) Sep 1 14:49:31 p freshclam[7654]: Database updated (3616181 signatures) from clamav.local (IP: 10.0.2.2) Sep 1 14:49:31 p freshclam[7654]: Clamd successfully notified about the update. Sep 1 14:49:31 p freshclam[7654]: -------------------------------------- Sep 1 14:49:32 p clamd[6693]: Reading databases from /var/lib/clamav Sep 1 14:49:39 p clamd[6693]: Database correctly reloaded (3610621 signatures)
und der clamav-daemon wird nicht neu gestartet.
quelle
Antworten:
Bitte überprüfen Sie, ob Sie ein Konfigurationsmanagementsystem verwenden, z. B. Puppet, Chef, CFEngine usw. Sie können in regelmäßigen Abständen die Dienste beeinträchtigen. Die genauen Maßnahmen zur Behebung dieses Problems hängen davon ab, wie der Dienst im Konfigurationsverwaltungssystem verwendet wird.
quelle
Notiz an mich.
Die Ausgabe aus dem Job-Cache:
Schauen Sie sich die Clamav-Formel an:
Nichts in den
watch
ed Staaten wurde geändert:Warum wurde der Dienst neu gestartet?
Auf der Suche nach habe
watch_in
ich einen Status gefunden, der die PID-Datei verwaltet, und der Dienst wird neu gestartet, wenn die PID-Datei geändert wurde:In der Ausgabe von habe
salt-run jobs.lookup_jid <job id number>
ich Folgendes gesehen:Daher wurde der Eigentümer / die Gruppe dieser PID-Datei in geändert
clamav
. Schließlich fand ich den Grund dafür, dass der clamav-Daemon alsroot
Benutzer im Netzwerkmodus ausgeführt wird . Daher wurde die PID-Datei als erstelltroot
. Der Status, der die PID-Datei verwaltet, muss also wie folgt geändert werden:quelle