Clamdscan in CentOS 7

34 posts / 0 new
Last post
#1 Thu, 01/15/2015 - 10:30

Clamdscan in CentOS 7


I have a problem regarding clam scan of our emails. Information about my system:

CentOS Linux release 7.0.1406 (Core) 

In Virtualmin configuration I have clamdscan as active option. It seems that clamdscan (wrapper) try to scan every mail, but in procmail logs I see this line at every incoming mail: ERROR: Could not lookup (null): Servname not supported for ai_socktype

As far I understand this error is regarding clam scan, but I don't know how to solve it.

Thank you for your time, Catalin Bucur.

Thu, 01/15/2015 - 11:29


Is ClamAV working, and just producing that as a notice when it runs? Or is that an error that's preventing it from working properly?


Thu, 01/15/2015 - 12:41

hi, i have the same problem on CentOS 7, at the moment you can choose the standalone (clamscan)

the server (clamdscan) doesn't work, instead

If I click Save on "Spam and Virus Scanning" it returns STDIN: noreply from clamd....

so in procmail there is the error "ERROR: Could not lookup (null): Servname not supported for ai_socktype" while standalone has no issues... and regularly reports "Mode:Virus" as expected instead of "Mode:none"...

Thu, 01/15/2015 - 13:33

@andreychek: clamdscan it's working if I run it from command line. But from procmail (in virtualmin solution) it gives me that error and it's not scanning any message.

@7stars: I'll try later standalone solution.

Thank you

Fri, 01/16/2015 - 10:11 (Reply to #4)

hey, it's not clear why this happens... but try to do this:

1) Spam and Virus Scanning

2) choose "Standalone scanner (clamscan)" and Save...

3) Disable ClamAV Server

4) Reenable ClamAV Server

5) choose "Server scanner (clamdscan)" and Save...

let me know if this works for you to me now it's working and when someone sends a virus you will see this on procmail.log:

procmail: Program failure (1) of "/etc/webmin/virtual-server/" and then the rest with "Mode:Virus"

you can test the EICAR here

hope this helps

Fri, 01/16/2015 - 10:08


We were talking to 7stars in IRC, and I believe he's saying this is working now after restarting ClamAV.

b1cata, could you perhaps restart ClamAV, and/or issue a reboot? I'd be curious if that helps in your case.

If not, what is the output of this command:

ls -l /var/run/clamd.scan

Fri, 01/16/2015 - 10:28

Hello again,

@7stars: I have done the same steps and you are right, now it's working. I hope that procmail error message does not affect anything else. Last night I have tried clamscan option and it's working too.

@andreychek: I have restarted many times, reboot etc, no effect. No I have finished another server in the same configuration. I was curious if I encounter the same error, and yes - it's the same behaviour.

# ls -l /var/run/clamd.scan
total 0
srw-rw-rw- 1 clamscan clamscan 0 Jan 16 18:12 clamd.sock

I guess it's a bug, but thank you for your help to solve this.

Regards, Catalin Bucur.

Sat, 01/17/2015 - 05:21

hi, i did a little php script until someone understands what's the source of the issue

so, if needed, first empty your procmail.log


$string = "ai_socktype";
$file = "/var/log/procmail.log";
$content = file_get_contents($file);

if (strpos($content,$string) != false) {
//echo "yes";
$to = "";
$subject = "ClamAV not working";
$message = "clamd is not working now, please do the steps you know";
$headers = 'From:' . "\r\n" .
    'Reply-To:' . "\r\n" .
    'X-Mailer: PHP/' . phpversion();

mail($to, $subject, $message, $headers);
//alert me by email
//echo "not found";


edit with your email account, save it as e.g. "ifclamerr.php", upload it where you want, put this in crontab to be executed once a day (maybe in early morning, so when you wake up fix it easily...i think that's enough) if you don't want to be emailed by the crontab but from the script only when it finds the error, add >/dev/null 2>&1 at the end of the crontab line...

if clamd is not working you know what to do...


Tue, 02/03/2015 - 08:42

hi, keep attention... it happens after every ClamAV update here on CentOS 7, tested now...

now running clamav-0.98.6-1.el7.x86_64

I was alerted by my script ;-) and had to do again...

Fri, 05/08/2015 - 16:07

I'm having the same problem on my fresh install on centos 7. What I found is that I don't need to do all the steps of the procedure describes by 7stars here , I just need to restart clamAV service and everything works fine ! But if I reboot the whole server, then it's back to the previous behaviour. I'll have to restart clamAV again to get it check emails. What is strange is that everything looks fine after a server reboot, clamd is launched and healthy....

[root@ns1 ~]# ps ax | grep clamd
25029 ?        Ssl    0:36 /usr/sbin/clamd -c /etc/clamd.d/scan.conf --nofork=yes

So I don't know why i get this in procmail log :

From  Wed May  6 22:32:23 2015
Subject: DNSstuff Mail Server Test Center Anti-Virus Test Message [TestID 1]
  Folder: /home/sam/Maildir/new/    2875
Time:1430944345 User:sam Size:2931 Dest:/home/sam/Maildir/new/ Mode:None
ERROR: Could not lookup : Servname not supported for ai_socktype

But after a ClamAV restart I get what it should be :

From  Fri May  8 22:27:44 2015
Subject: DNSstuff Mail Server Test Center Anti-Virus Test Message [TestID 1]
  Folder: /home/sam/Maildir/.Virus/new/    2561
Time:1431116866 User:sam Size:2618 Dest:/home/sam/Maildir/.Virus/new/ Mode:Virus
procmail: Program failure (1) of "/etc/webmin/virtual-server/"

Does anybody found something to solve this ? I'm a bit stuck to this point with my little knowledge, but I can do more investigation if someone can tell me a bit more where to search ;)

Sun, 05/24/2015 - 11:30

ok, I can confirm that's enough to restart the ClamAv server from Status... but the issue is always there, after a clamav update or rebooted server... nobody knows what's the cause?

Sat, 05/30/2015 - 00:42

I think I have resolved this with:

# touch /var/run/clamd.scan/clamd.sock
# chown clamscan: /var/run/clamd.scan/clamd.sock
# chmod 660 /var/run/clamd.virtualmin/clamd.sock

then uncommented these lines in /etc/clamd.d/scan.conf:

PidFile /var/run/clamd.scan/
LocalSocket /var/run/clamd.scan/clamd.sock

this one is more specific: I have a Virtual Server for my server hostname and had to modify on /etc/postfix/ this line:

mydestination = $myhostname, localhost.$mydomain, localhost, servername

('servername' is the short version of your hostname)


mydestination = localhost.$mydomain, localhost, servidor2

This is because "$myhostname" is already present in the Virtual Server so is already a local domain and having it on $mydestination var was causing issues.

for last:

systemctl restart postfix
systemctl restart clamd@scan.service

I could test this with:

clamdscan -c /etc/clamd.d/scan.conf /etc/hosts

prior the fix:

ERROR: Could not lookup (null): Servname not supported for ai_socktype

after the fix:

/etc/hosts: OK



Removing "$myhostname" from $mydestination variable, caused all the incoming messages to bounce back! Actually, I had to revert it to original string. The warning in the postfix logs are just because I had a Virtual Server with the same name of my server's hostname. Since I'm not receiving e-mail on this domain, all I had to do was select the virtual server in Virtual > Edit Virtual Server > disabled Mail, Virus Scan, Spam scan, Mailman, then Save. This removed "" from the virtual alias table and the error in Postfix log gone away, and e-mail remained working fine! I hope it helps.

Fri, 10/02/2015 - 16:27

I had the same problem today, fresh installed system (Centos 7), didn't touch anything, yum update / disable selinux / reboot and I just wget the install file and ran it.

On the step asking about ClamAV it was crashing with the same error. "ERROR: Could not lookup (null): Servname not supported for ai_socktype"

Digging clam conf without luck.

After erasing all lines for ipv6 in /etc/hosts and made something like this: ip-of-server hostname.domain hostname

it worked.

(Of course I don't know which of these two really made the trick, the server line or erasing the IPv6 lines).

Anyway, that's a fix, but I don't know what happens if someone wants ipv6 :-)

Mon, 10/05/2015 - 02:46

This trick doesn't work in my case.... I commented IPV6 lines in /etc/hosts and my line " ns1" was already there...Rebooted and same behaviour : clamd running but not working (ai_socktype error)....Restarted clamd only and then eveything is working fine. So I just need to remember to restart clamd after each reboot, that is my working trick since I have no other idea of what to do ;)

Thu, 10/22/2015 - 13:47

I am bit lost here.... I am on the same boat (Centos7)

Is there a permanent fix for this found or not yet?

Sat, 01/30/2016 - 15:25

Right, I believe I've solved this. I can't guarantee that the root cause of this issue is the same on everyone's server, so the same symptoms may not always require the same cure, but here was what was going on with two of my servers.

The symptom: When you run virus scanning on incoming email, and use clamd to scan rather than the standalone scanner, it fails to scan. You see the following entry in procmail.log: "ERROR: Could not lookup : Servname not supported for ai_socktype"
The trigger: Having fixed the problem, two things cause it to recur - (i) a server reboot, (ii) yum updating clamscan etc to a new version. (Simply restarting clamd@scan.service did not cause the problem, neither did updating the ClamAV signature files).
The way to get it working again: As in a post further up this thread. All in Virtualmin > Email Messages > Spam and Virus Scanning: (i) Set scanning back to the standalone; (ii) disable ClamAV server; (iii) enable ClamAV server; (iv) set scanning to use the "server scanner".
The actual cause: Permissions. The socket for clamd is stored at /var/run/clamd.scan/clamd.sock. When you configure ClamAV for the first time, or reboot the server, the folder /var/run/clamd.scan is set to have permissions of 710. You can set the actual socket permissions in /etc/clam.d/scan.conf, but not the permissions for its containing folder. procmail will pass its scanning process to be run by the user of the mailbox receiving the message (i.e., Linux user username.domain). Unless that user is a member of the clamscan group, it won't be able to enter the /var/run/clamd.scan folder, so it can't access the socket. The painful route would be to add all mailbox users to the clamscan group. But the better solution is to set /var/run/clamd.scan to 755. The trouble is, a server reboot sees the folder permission revert to 710. [Why?]. Re-enabling "server scanner" in VirtualMin will reset the folder permissions to 755, but doing it manually is enough to get scanning working again.

Sat, 01/30/2016 - 16:58
Sun, 01/31/2016 - 03:19

The above lengthy post explained the problem in some detail. For those wanting a TL;DR solution (with the usual warranty that I'm only pointing you in the right direction, and only you are responsible for what you do on your server ;-) ), run these two lines:

chmod 755 /var/run/clamd.scan
sed 's/710/755/' /usr/lib/tmpfiles.d/clamd.scan.conf > /etc/tmpfiles.d/clamd.scan.conf
Thu, 11/17/2016 - 14:45

I have the same problem, during Post-Installation Wizard

I have a fresh latest Centos7.2 installation with the latest Virtualmin, and this problem is under Post-Installation Wizard.

How to fix it? any idea? Above solutions not working.


Sun, 11/20/2016 - 11:12

Just tested Debian with Virtualmin, and there is no problem with clamAV, so why Centos have tham problem? any idea?

Wed, 11/30/2016 - 20:29

sz00gun: I just installed virtualmin on a fresh CentOS 7 box, and this worked for me, as the error in the "post-installation wizard" no longer appears:

systemctl restart postfix
systemctl restart clamd@scan.service

Seems that clamd@scan.service is not on, so you can also do this:

systemctl enable clamd@scan.service

Hope this helps, and hope our friends at VirtualMin fix the script for CentOS7 to include this



Fri, 12/02/2016 - 13:31

@CaeSpock @Carlos well... still not working in my case, after your solution... ;(

Sat, 12/03/2016 - 14:27


Same issue here! Have tried all possible solution found in Forum.. nothing worked. Clamdscan gives the AI socket error.

I´m actually using Clamscan.



Mario Loewenhaupt

Mon, 12/19/2016 - 18:35
litonfiredesign's picture

I have the same issue during post instal when trying to activate it.

A problem occurred testing the ClamAV server scanner :

ERROR: Could not lookup : Servname not supported for ai_socktype

----------- SCAN SUMMARY -----------

Infected files: 0

Time: 0.004 sec (0 m 0 s)

Tue, 12/20/2016 - 20:14

I tested it again, with centos 7.3 Seems that clamd is installed but not enabled. with the following 3 commands it started to work:

systemctl restart postfix
systemctl restart clamd@scan.service
systemctl enable clamd@scan.service

The centos7 script needs to check this, but well, for me this small trick worked


Thu, 01/12/2017 - 07:02

I am having an identical problem to litonfiredesign. I have tried to ignore it but I am also having problems with the MySQL root password (see other thread) and until I get past those I can't try CaeSpock's solution. I wonder if the install script needs to be modified for CentOS perhaps?


Wed, 03/29/2017 - 17:09

This bug is still here. Just confirmed on CentOS 7.3 a few minutes ago and I was able to replicate it over and over again.

This will definitely create more than one headache to new people installing Virtualmin on the initial Wizard get they get stuck.

What CaeSpock posted seems to work.

Maybe this should be reported as bug to the developers because it just gives a bad impression to new people installing the software on RHEL or Variants.

Thu, 03/30/2017 - 00:17

@volk, Indeed, that's very annoying, but I found a solution for this. Do this what I have done, change a distribution for Ubuntu, or Debian. Since that all is working fine, even better... I think.

Never Centos again!

Thu, 03/30/2017 - 00:25 (Reply to #28)

I hope you are not serious. People are dropping Ubuntu like flies lately and Debian while nice does not have the long term support CentOS has, it's a short release OS and changing your server every 2 years because your OS is EOL is not an option for most business unless you want to run an insecure and unpatched operating system on the Internet.

You can like it or not, but CentOS or any other RHEL derivative is the best and number one OS for server softwares and companies for the simple reason that Red Hat is behind it, and the support for each release is between 10 and 20 years. It's the main OS in the data center and cloud providers. Every single thing you find for enterprise or business server platforms is tested and works with RHEL and this is actually as far as I know the preferred OS by cPanel, Plesk and even Virtualmin for that reason or just any other server platform.

Switching the OS to fix a simple bug is a very poor suggestion when it just takes a few lines to fix.

Thu, 03/30/2017 - 00:41

Well, my Ubuntu is LTS, 16.04.2 no problems at all. Don't need upgrade it every couple of weeks. I have better expirence with Ubuntu than with Centos. That's all.

PS. The main reason I changed the OS is not that bug, but server freezes every so often. You can see my previous post about it.

Thu, 03/30/2017 - 00:52

Regular updates are fine, every OS has them. I was talking between major versions. Example, if you are running CentOS 5 you need to do a whole new install for 6. That involves taking a backup of all your data, and having a downtime or spinning a new server and them manually migrating all the changes, configs and data. This may be ok if you have one system but if you have hundreds or thousands of servers you need to migrate it's a nasty thing. Hence companies love LTS supported versions that will be patched and work for years to come.

I was not aware of the freezes you mentioned. Sounds strange. Is this a physical server or a virtual one?

If it's a physical bare metal machine, I can only thing there was some kernel panic going because of missing drivers missing. Ubuntu has better hardware support so that could be an issue and I did had to compile manual drivers for Intel network cards and other things before on CentOS but this is true for Linux in general. Now if you are running server hardware, they are actually better supported on CenOS (what I run) but standard computers may be better off running Ubuntu for that reason. Now if it was a cloud or VM, there is absolutely no reason why it would work better or more stable in Ubuntu unless there was something wrong with your installation.

Thu, 03/30/2017 - 02:03
Diabolico's picture

@volk: This is happening because Centos 7 compared to previous version (6 and 5) brought many changes and looks like Vmin devs never bother too much with this OS. What is happening with ClamAV its just one of many things what Vmin doesnt do good on Centos 7, e.g. ProFTPd failing to start would be another one. Suggestion from @sz00gun doesnt make any sense and instead of changing Centos 7 to some other OS i would rather drop the software not supporting this OS. Ubuntu and Debian could be good for something but i would never use it on production server for hosting.

- I often come to the conclusion that my brain has too many tabs open. -
Failing at desktop publishing & graphic design since 1994.

Thu, 03/30/2017 - 02:21 (Reply to #32)

This is because CentOS 7 comes with systemd instead of the previous service or init.d files. In most cases a symlink solves the problem but they need to start using it and I guess most software will start using that in CentOS now. Otherwise they will fail.

The example of Clam not starting here is exactly that problem, you need to use systemctl now.

Thu, 03/30/2017 - 02:04

I had a dedicated ovh server, using ovh kernel, so I reckon that caused a problem... Or centos... Don't want to test it now, because I'm happy with Ubuntu.

Topic locked