- Ubuntu 14.04
- clamav 0.98.7
Problem ten clamav-daemon
zostaje wznowiona prawie codziennie:
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".
Spowodowało to problem, jeśli clamdscan
jest uruchomiony:
/etc/cron.daily/clamav_scan:
ERROR: Could not connect to clamd on x.x.x.x: Connection refused
Zauważ, że na początku powiedziałem „prawie”:
/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.
Jak widzisz:
- nie stało się to w dniach 29 i 30 sierpnia
często wznowiona po 06:27 czyli odcinek czasu
cron.daily
jest prowadzony27 6 * * * root nice -n 19 ionice -c3 run-parts --report /etc/cron.daily
Treść /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=$?
Istnieje plik logrotate dla 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
}
ale po prostu przeładowuje dziennik:
Sep 1 02:30:24 uba-master clamd[6778]: SIGHUP caught: re-opening log file.
Wiem, że możemy użyć auditd
do monitorowania pliku binarnego i oto przykładowy dziennik:
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 to UID ... clamav
użytkownika:
getent passwd clamav clamav:x:109:114::/var/lib/clamav:/bin/false
Czy istnieje inny sposób rozwiązania tego problemu?
Odpowiedz na @HBruijn:
Być może freshclam po aktualizacji definicji AV?
Myślałem o tym. Oto dziennik:
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)
Nie jestem tego pewien, ale wygląda na to, że freshclam ma „wewnętrzny mechanizm”, który powiadamia clamd o aktualizacji. A po tym może po prostu ponownie załadować bazę danych, nie trzeba ponownie uruchamiać procesu. Czy możesz potwierdzić?
Co więcej, od znacznika czasu widziałem, że demon clamav uruchomił się ponownie po godzinie aktualizacji bazy danych freshclam. Jest to normalne?
AKTUALIZACJA wtorek 1 września 22:10:49 ICT 2015
ale wygląda na to, że freshclam ma „wewnętrzny mechanizm” powiadamiający clamd o aktualizacji. A po tym może po prostu ponownie załadować bazę danych, nie trzeba ponownie uruchamiać procesu.
Mogę potwierdzić, że jest to poprawne, wykonując test:
- edytuj plik freshclam.conf, aby zmienić interwał na minuty (
Checks 1440
) - uruchom ponownie clamav-freshclam
- cd / var / lib / clamav
- rm daily.cvd
poczekaj minutę
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)
a demon clamav nie zostanie ponownie uruchomiony.
źródło
Odpowiedzi:
Sprawdź, czy korzystasz z systemu zarządzania konfiguracją, np. Puppet, Chef, CFEngine itp. Mogą one zakłócać działanie usług w regularnych odstępach czasu. Dokładne działanie, które należy podjąć, aby to naprawić, zależy od sposobu korzystania z usługi w systemie zarządzania konfiguracją.
źródło
Notka dla siebie.
Dane wyjściowe z pamięci podręcznej zadań:
Spójrz na formułę clamav:
Nic w
watch
stanach ed nie zostało zmienione:Dlaczego usługa została ponownie uruchomiona?
Szukając
watch_in
, znalazłem stan, który zarządza plikiem pid, a usługa zostanie zrestartowana, jeśli plik pid został zmieniony:W wyniku
salt-run jobs.lookup_jid <job id number>
zobaczyłem to:Tak więc właściciel / grupa tego pliku pid została zmieniona na
clamav
. Wreszcie znalazłem przyczynę tego, że demon clamav działa w trybie sieciowym jakoroot
użytkownik. Dlatego plik pid został utworzony jakoroot
. Zatem stan zarządzający plikiem pid musi zostać zmieniony na coś takiego:źródło