- Ubuntu 14.04
- clamav 0.98.7
El problema se clamav-daemon
reinicia casi a diario:
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".
Causó un problema si se clamdscan
está ejecutando:
/etc/cron.daily/clamav_scan:
ERROR: Could not connect to clamd on x.x.x.x: Connection refused
Tenga en cuenta que dije "casi" al principio:
/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.
Como puedes ver:
- no sucedió a los 29 y 30 de agosto
a menudo se reinicia alrededor de las 06:27, que es el momento en que
cron.daily
se ejecuta27 6 * * * root nice -n 19 ionice -c3 run-parts --report /etc/cron.daily
El contenido de /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=$?
Hay un archivo logrotate para 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
}
pero solo vuelve a cargar el registro:
Sep 1 02:30:24 uba-master clamd[6778]: SIGHUP caught: re-opening log file.
Sé que podemos usar auditd
para monitorear el archivo binario y aquí hay un registro de ejemplo:
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 es el UID de ... clamav
usuario:
getent passwd clamav clamav:x:109:114::/var/lib/clamav:/bin/false
¿Hay otra forma de solucionar problemas en este caso?
Responder a @HBruijn:
¿Posiblemente freshclam después de actualizar las definiciones AV?
He pensado en ello. Aquí está el registro:
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)
No estoy seguro de esto, pero parece que freshclam tiene un "mecanismo interno" para notificar a clamd sobre la actualización. Y después de eso, solo puede volver a cargar la base de datos, sin necesidad de reiniciar el proceso. ¿Puedes confirmar?
Además, desde la marca de tiempo, vi que clamav-daemon se reinició después de la actualización de la base de datos de freshclam una hora. ¿Es normal?
ACTUALIZACIÓN Mar 1 de septiembre 22:10:49 TIC 2015
pero parece que freshclam tiene un "mecanismo interno" para notificar a clamd sobre la actualización. Y después de eso, solo puede volver a cargar la base de datos, sin necesidad de reiniciar el proceso.
Puedo confirmar que esto es correcto haciendo una prueba:
- edite el archivo freshclam.conf para cambiar el intervalo a minutos (
Checks 1440
) - reiniciar clamav-freshclam
- cd / var / lib / clamav
- rm daily.cvd
espera un minuto
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)
y el clamav-daemon no se reinicia.
fuente
Respuestas:
Compruebe si está utilizando algún sistema de gestión de configuración, por ejemplo, Puppet, Chef, CFEngine, etc. Pueden interferir con los servicios a intervalos regulares. Para que la acción exacta que se tome para rectificar esto dependa de cómo se usa el servicio en el sistema de administración de configuración.
fuente
Nota para mi.
La salida de la memoria caché del trabajo:
Mira la fórmula clamav:
Nada en los
watch
estados ed fue cambiado:¿Por qué se ha reiniciado el servicio?
Buscando el
watch_in
, encontré un estado que administra el archivo pid y el servicio se reiniciará si el archivo pid cambia:En la salida de
salt-run jobs.lookup_jid <job id number>
, vi esto:Entonces, el propietario / grupo de ese archivo pid se ha cambiado a
clamav
. Finalmente, encontré que la razón es que clamav daemon se está ejecutando en el modo de red comoroot
usuario. Por lo tanto, el archivo pid se creó comoroot
. Entonces, el estado que administra el archivo pid debe cambiarse a algo como:fuente