Clamdscan in CentOS 7

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

Regards

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

Hi!

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

I´m actually using Clamscan.

Regards

Loewenhaupt

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)

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

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?

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.

@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!

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.

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.

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.

@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 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.

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.