我已经四处搜索，但到目前为止还没有找到可能的解决方案。我有一个正在进行的扫描，我认为它会在某个时间完成，但不幸的是它没有。所以我想知道是否有办法检查这个正在进行的进度的扫描进度。
我正在尝试让 Clamav-daemon 在 Debian 8 系统上运行，以便它侦听 TCP 端口 3310。我已完成以下操作：
aptitude install clamav-daemon
然后进行修改/etc/clamav/clamd.conf，使其现在在顶部具有以下内容：
# Added by me
TCPSocket 3310
TCPAddr localhost
# Already existed
LocalSocket /var/run/clamav/clamd.ctl
FixStaleSocket true
LocalSocketGroup clamav
LocalSocketMode 666
使用重新启动服务service clamav-daemon restart。
我发现它netstat -tap | grep clam没有返回任何东西。运行ps aux | grep clam返回：
clamav 18559 11.4 10.3 649212 399604 ? Ssl 14:38 0:15 /usr/sbin/clamd --foreground=true
有一个自动生成的文件/etc/systemd/system/clamav-daemon.socket.d/extend.conf，其中包含：
[Socket]
ListenStream=
SocketUser=clamav
ListenStream=/var/run/clamav/clamd.ctl
SocketGroup=clamav
SocketMode=666
我在日志中唯一能看到的是：
TCP: No tcp AF_INET/AF_INET6 SOCK_STREAM socket …在 fc29 上，我安装了 clamd 并且 clamd@scan.service 运行良好。clamdscan 可以为 root 运行，但不能为普通用户运行，即使添加到“clamscan”组后也是如此。
dnf list installed | grep clam
clamav.x86_64 0.101.0-3.fc29 @updates
clamav-filesystem.noarch 0.101.0-3.fc29 @updates
clamav-lib.x86_64 0.101.0-3.fc29 @updates
clamav-update.x86_64 0.101.0-3.fc29 @updates
clamd.x86_64 0.101.0-3.fc29 @updates
以 root 身份运行 clamdscan 效果很好
clamdscan --fdpass .
gpasswd -a reg_user clamscan
当以 clamscan 组中的用户身份运行时 -
clamdscan --fdpass .
ERROR: Could not connect to clamd on LocalSocket /var/run/clamd.scan/clamd.sock: Permission denied
仍然没有-
sudo -u reg_user clamdscan --fdpass .
ERROR: Could not connect to clamd on LocalSocket /var/run/clamd.scan/clamd.sock: Permission denied
不出所料- …
我已经使用 apt 从官方存储库在 Debian Wheezy 上安装了 ClamAV。系统是最新的，我没有通过 获得任何更新apt-get upgrade，但我仍然在日志中收到此消息：
Your ClamAV installation is OUTDATED!
我的版本是：
$ clamscan -V
ClamAV 0.98.1/19186/Sun Jul 13 00:34:56 2014
在官方页面上：
最新的 ClamAV® 稳定版本是：0.98.4
看起来 Wheezy 的官方稳定存储库不是最新的。我找到的唯一信息是有关 Debian Volatile 项目的官方信息，该项目自 Squeeze 以来已关闭。
有没有替代的存储库？
如何让 ClamAV 始终保持最新状态并确保系统稳定？
编辑：
我的/etc/apt/sources.list：
deb http://ftp.ru.debian.org/debian/ wheezy main non-free contrib
deb http://security.debian.org/ wheezy/updates main contrib non-free
deb http://ftp.ru.debian.org/debian/ wheezy-updates main contrib non-free
$ dpkg -l 'clamav*'
||/ Name Version Architecture Description
+++-========================================-=========================-=========================-======================================================================================
ii clamav …我的服务器是centos 7.4，clamav 0.101.1-1.el7。
当我运行clamscan -r --infected --exclude-dir="^/sys" /终端时，我总是等待 6 个多小时才能获得输出。
如果我关闭终端，clamscan就会停止。
然后我想用来clamdscan在后台扫描。
我的问题是：
1.How to --exclude-dir="^/sys" /with clamdscan？
2.如何clamdscan只做日志--infected？
我在同一个磁盘上有两个虚拟机，每个虚拟机都安装了 clamav。两者定期同时运行相同病毒扫描特征的更新，这导致每次都对磁盘性能造成不必要的压力。由于这些签名与下载的签名相同，因此我想减少这种情况下的冗余。
最初的想法是让他们共享一个虚拟磁盘，这些签名在其中下载一次，因此 VM 只需从那里读取它们。因此，只有一个 VM 需要对磁盘进行写访问以进行下载，而另一个 VM 具有只读访问权限。
我使用以下命令将虚拟磁盘附加到第一个 VM：
$ virsh attach-disk <VM1> <virtDisk> vdb --cache none
但是，在尝试将同一个虚拟磁盘附加到第二个虚拟机时，在成功附加到第一个虚拟磁盘后，使用：
$ virsh attach-disk <VM2> <virtDisk> vdb --cache none --mode readonly
unable to execute QEMU command 'device-add': Failed to get shared "write" lock
发生错误
。这是不可能的，还是我错过了一个选择？
为此目的，在 VM 之间共享这些签名的最佳方法是什么？
我有一个 Postfix 邮件服务器，使用 Amavis 和 Spamassassin 来检查不需要的电子邮件。我已经删除了 ClamAV，因为它基本上会在每次有人收到电子邮件时冻结整个服务器，并且服务器端病毒扫描对我的用例来说似乎并不重要。
Spamassassin 仍然由 Amavis 触发，我想保持这种状态。
基本上我想要的是 Amavis 停止尝试为每封电子邮件触发病毒扫描。
May 29 07:49:14 robinj amavis[19859]: (19859-01) (!)connect to /tmp/clamd.socket failed, attempt #1: Can't connect to UNIX socket /tmp/clamd.socket: No such file or directory
May 29 07:49:15 robinj amavis[19859]: (19859-01) (!)connect to /tmp/clamd.socket failed, attempt #1: Can't connect to UNIX socket /tmp/clamd.socket: No such file or directory
May 29 07:49:15 robinj amavis[19859]: (19859-01) (!)ClamAV-clamd: All attempts (1) failed connecting to /tmp/clamd.socket, retrying (2)
May 29 07:49:21 …我将以下 Milters 与 Postfix 一起使用：
ClamAV、OpenDKIM、OpenDMARC、Rspamd
这也是通过 调用它们的顺序smtpd_milters。
对于他们来说，关于性能、资源和垃圾邮件防护的最佳顺序是什么？
在学习强化 VPS 的过程中，我安装了 ClamAV 和 MalDet，并使用了几个月。今晚，我决定，与其只是在家检查，我还要检查除“/sys”之外的整个 VPS。
这是结果：
/usr/local/maldetect.bk11949/sigs/rfxn.ndb: YARA.Safe0ver_Shell__Safe_Mod_Bypass_By_Evilc0der_php.UNOFFICIAL FOUND
/usr/local/maldetect.bk11949/sigs/hex.dat: YARA.Safe0ver_Shell__Safe_Mod_Bypass_By_Evilc0der_php.UNOFFICIAL FOUND
/usr/local/maldetect.bk11949/sigs/rfxn.hdb: YARA.Safe0ver_Shell__Safe_Mod_Bypass_By_Evilc0der_php.UNOFFICIAL FOUND
/usr/local/maldetect.bk11949/sigs/md5.dat: YARA.Safe0ver_Shell__Safe_Mod_Bypass_By_Evilc0der_php.UNOFFICIAL FOUND
/usr/local/maldetect.bk11949/sigs/rfxn.yara: {HEX}gzbase64.inject.unclassed.15.UNOFFICIAL FOUND
/usr/local/maldetect.bk11949/sigs/md5v2.dat: YARA.Safe0ver_Shell__Safe_Mod_Bypass_By_Evilc0der_php.UNOFFICIAL FOUND
/usr/local/maldetect.bk11949/tmp/.lmdup.666.11852/maldetect-current.tar.gz: YARA.Safe0ver_Shell__Safe_Mod_Bypass_By_Evilc0der_php.UNOFFICIAL FOUND
/usr/local/maldetect.bk11949/tmp/.lmdup.666.11852/maldetect-1.6/files/sigs/rfxn.ndb: YARA.Safe0ver_Shell__Safe_Mod_Bypass_By_Evilc0der_php.UNOFFICIAL FOUND
/usr/local/maldetect.bk11949/tmp/.lmdup.666.11852/maldetect-1.6/files/sigs/hex.dat: YARA.Safe0ver_Shell__Safe_Mod_Bypass_By_Evilc0der_php.UNOFFICIAL FOUND
/usr/local/maldetect.bk11949/tmp/.lmdup.666.11852/maldetect-1.6/files/sigs/rfxn.hdb: YARA.Safe0ver_Shell__Safe_Mod_Bypass_By_Evilc0der_php.UNOFFICIAL FOUND
/usr/local/maldetect.bk11949/tmp/.lmdup.666.11852/maldetect-1.6/files/sigs/md5.dat: YARA.Safe0ver_Shell__Safe_Mod_Bypass_By_Evilc0der_php.UNOFFICIAL FOUND
/usr/local/maldetect.bk11949/tmp/.lmdup.666.11852/maldetect-1.6/files/sigs/rfxn.yara: {HEX}gzbase64.inject.unclassed.15.UNOFFICIAL FOUND
/usr/local/maldetect.bk11949/tmp/.lmdup.666.11852/maldetect-1.6/files/sigs/md5v2.dat: YARA.Safe0ver_Shell__Safe_Mod_Bypass_By_Evilc0der_php.UNOFFICIAL FOUND
/usr/local/maldetect.bk11949/tmp/.lmdup.666.11852/maldetect-1.6/files/clean/gzbase64.inject.unclassed: {HEX}gzbase64.inject.unclassed.15.UNOFFICIAL FOUND
/usr/local/maldetect.bk11949/clean/gzbase64.inject.unclassed: {HEX}gzbase64.inject.unclassed.15.UNOFFICIAL FOUND
/usr/local/maldetect.bk11949/sigs.old/rfxn.ndb: YARA.Safe0ver_Shell__Safe_Mod_Bypass_By_Evilc0der_php.UNOFFICIAL FOUND
/usr/local/maldetect.bk11949/sigs.old/hex.dat: YARA.Safe0ver_Shell__Safe_Mod_Bypass_By_Evilc0der_php.UNOFFICIAL FOUND
/usr/local/maldetect.bk11949/sigs.old/rfxn.hdb: YARA.Safe0ver_Shell__Safe_Mod_Bypass_By_Evilc0der_php.UNOFFICIAL FOUND
/usr/local/maldetect.bk11949/sigs.old/md5.dat: YARA.Safe0ver_Shell__Safe_Mod_Bypass_By_Evilc0der_php.UNOFFICIAL FOUND
/usr/local/maldetect.bk11949/sigs.old/rfxn.yara: {HEX}gzbase64.inject.unclassed.15.UNOFFICIAL FOUND
/usr/local/maldetect.bk11949/sigs.old/md5v2.dat: YARA.Safe0ver_Shell__Safe_Mod_Bypass_By_Evilc0der_php.UNOFFICIAL FOUND
/usr/local/maldetect/sigs/rfxn.ndb: YARA.Safe0ver_Shell__Safe_Mod_Bypass_By_Evilc0der_php.UNOFFICIAL FOUND
/usr/local/maldetect/sigs/hex.dat: YARA.Safe0ver_Shell__Safe_Mod_Bypass_By_Evilc0der_php.UNOFFICIAL FOUND
/usr/local/maldetect/sigs/rfxn.hdb: YARA.Safe0ver_Shell__Safe_Mod_Bypass_By_Evilc0der_php.UNOFFICIAL FOUND …我正在摆弄一些超时设置，并试图找出为 systemd/系统守护进程设置内容的正确方法。具体来说，这是一个动力不足的服务器，并且我在启动 clamd 时总是超时，因此我试图弄清楚需要将 TimeoutStartSec 参数设置为多高。我试过
systemctl edit --full clamd@.service
并编辑它说
TimeoutStartSec=20min
然后做了systemctl daemon-reload
但7分钟后它就神秘地超时了。最终，我发现/usr/lib/systemd/system/clamd@.service有TimeoutStartSec=420。
可能违背了所有正确的做法，我编辑了/usr/lib文件的版本，并注释掉了该行。果然，这改变了事情，但它似乎仍然没有读取版本/etc/systemd。一旦我将其注释掉，它就会在 90 秒后开始超时，我想这一定是默认值。
作为临时解决方法，我已将/usr/lib版本编辑为我想要的 20 分钟，但是......这似乎不是正确的做事方式。
应该systemctl edit编辑版本吗/etc/systemd/system？这是公认的正确做事方式吗？我还需要做更多的事情吗systemctl daemon-reload？
对有关正确方法的任何和所有建议持开放态度。
TIA