- Ubuntu 14.04
- clamav 0.98.7
Masalahnya clamav-daemon
dimulai ulang hampir setiap hari:
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".
Ini menyebabkan masalah jika clamdscan
dijalankan:
/etc/cron.daily/clamav_scan:
ERROR: Could not connect to clamd on x.x.x.x: Connection refused
Perhatikan bahwa saya mengatakan "hampir" di awal:
/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.
Seperti yang dapat Anda lihat:
- itu tidak terjadi pada 29 dan 30 Agustus
sering dimulai kembali sekitar 06:27 yang waktunya
cron.daily
dijalankan27 6 * * * root nice -n 19 ionice -c3 run-parts --report /etc/cron.daily
Isi dari /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=$?
Ada file logrotate untuk 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
}
tetapi hanya memuat ulang log:
Sep 1 02:30:24 uba-master clamd[6778]: SIGHUP caught: re-opening log file.
Saya tahu bahwa kita dapat menggunakan auditd
untuk memantau file biner dan inilah contoh log:
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 adalah pengguna UID ... clamav
:
getent passwd clamav clamav:x:109:114::/var/lib/clamav:/bin/false
Apakah ada cara lain untuk memecahkan masalah dalam kasus ini?
Balas ke @HBruijn:
Mungkin freshclam setelah memperbarui definisi AV?
Sudah saya pikirkan. Ini lognya:
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)
Saya tidak yakin tentang ini tetapi sepertinya freshclam memiliki "mekanisme internal" untuk memberi tahu clamd tentang pembaruan. Dan setelah itu hanya bisa memuat ulang database, tidak perlu memulai kembali prosesnya. Bisakah kamu mengkonfirmasi?
Selain itu, dari timestamp, saya melihat bahwa clamav-daemon dimulai kembali setelah database pembaruan freshclam satu jam. Apakah ini normal?
PEMBARUAN Selasa, 1 Sep 22:10:49 ICT 2015
tetapi sepertinya freshclam memiliki "mekanisme internal" untuk memberi tahu clamd tentang pembaruan. Dan setelah itu hanya bisa memuat ulang database, tidak perlu memulai kembali prosesnya.
Saya dapat mengkonfirmasi ini benar dengan melakukan tes:
- edit file freshclam.conf untuk mengubah interval ke menit (
Checks 1440
) - restart clamav-freshclam
- cd / var / lib / clamav
- rm daily.cvd
tunggu sebentar
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)
dan clamav-daemon tidak di-restart.
sumber
Jawaban:
Silakan periksa apakah Anda menggunakan sistem manajemen konfigurasi, mis. Boneka, Chef, CFEngine, dll. Mereka dapat mengganggu layanan secara berkala. Untuk tindakan tepat yang harus diambil untuk memperbaiki ini tergantung pada bagaimana layanan digunakan dalam sistem manajemen konfigurasi.
sumber
Catatan untuk diriku sendiri.
Output dari cache pekerjaan:
Lihatlah formula clamav:
Tidak ada di
watch
negara ed yang diubah:Mengapa layanan telah direstart?
Mencari
watch_in
, saya menemukan negara yang mengelola file pid dan layanan akan dimulai kembali jika file pid mendapat perubahan:Dalam output dari
salt-run jobs.lookup_jid <job id number>
, saya melihat ini:Jadi, pemilik / grup file pid itu telah diubah
clamav
. Akhirnya, saya menemukan alasannya adalah bahwa clamav daemon berjalan dalam mode jaringan sebagairoot
pengguna. Oleh karena itu, file pid dibuat sebagairoot
. Jadi, negara yang mengelola file pid harus diubah menjadi sesuatu seperti:sumber