- Ubuntu 14.04
- clamav 0.98.7
Le problème est clamav-daemon
redémarré presque quotidiennement:
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".
Cela a causé un problème si clamdscan
est en cours d'exécution:
/etc/cron.daily/clamav_scan:
ERROR: Could not connect to clamd on x.x.x.x: Connection refused
Notez que j'ai dit "presque" au début:
/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.
Comme vous pouvez le voir:
- cela ne s'est pas produit les 29 et 30 août
souvent repris dans le 06:27 qui est le temps
cron.daily
est géré27 6 * * * root nice -n 19 ionice -c3 run-parts --report /etc/cron.daily
Le contenu 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=$?
Il existe un fichier logrotate pour 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
}
mais il suffit de recharger le journal:
Sep 1 02:30:24 uba-master clamd[6778]: SIGHUP caught: re-opening log file.
Je sais que nous pouvons utiliser auditd
pour surveiller le fichier binaire et voici un exemple de journal:
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 est l'UID de ... l' clamav
utilisateur:
getent passwd clamav clamav:x:109:114::/var/lib/clamav:/bin/false
Y a-t-il une autre manière de dépanner dans ce cas?
Répondre à @HBruijn:
Peut-être freshclam après la mise à jour des définitions AV?
J'y ai pensé. Voici le journal:
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)
Je ne suis pas sûr de cela, mais il semble que freshclam dispose d'un "mécanisme interne" pour informer clamd de la mise à jour. Et après cela, il peut simplement recharger la base de données, pas besoin de redémarrer le processus. Pouvez-vous confirmer?
De plus, à partir de l'horodatage, j'ai vu que le démon clamav a redémarré après une heure de mise à jour de la base de données freshclam. Est-ce normal?
MISE À JOUR mar. 1 sept. 22:10:49 ICT 2015
mais il semble que freshclam dispose d'un "mécanisme interne" pour informer clamd de la mise à jour. Et après cela, il peut simplement recharger la base de données, pas besoin de redémarrer le processus.
Je peux confirmer que c'est correct en faisant un test:
- éditez le fichier freshclam.conf pour changer l'intervalle en minutes (
Checks 1440
) - redémarrer clamav-freshclam
- cd / var / lib / clamav
- rm daily.cvd
attendez une 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)
et le clamav-daemon n'est pas redémarré.
la source
Réponses:
Veuillez vérifier si vous utilisez un système de gestion de configuration, par exemple Puppet, Chef, CFEngine, etc. Ils peuvent interférer avec les services à intervalles réguliers. Pour que l'action exacte à prendre pour rectifier cela dépend de la façon dont le service est utilisé dans le système de gestion de configuration.
la source
Note à moi-même.
La sortie du cache de travaux:
Regardez la formule du clamav:
Rien aux
watch
États-Unis n'a été modifié:Pourquoi le service a été redémarré?
À la recherche de
watch_in
, j'ai trouvé un état qui gère le fichier pid et le service sera redémarré si le fichier pid a été modifié:Dans la sortie de
salt-run jobs.lookup_jid <job id number>
, j'ai vu ceci:Ainsi, le propriétaire / groupe de ce fichier pid a été changé en
clamav
. Enfin, j'ai trouvé la raison en est que le démon clamav s'exécute en mode réseau en tantroot
qu'utilisateur. Par conséquent, le fichier pid a été créé en tant queroot
. Ainsi, l'état qui gère le fichier pid doit être changé en quelque chose comme:la source