ClamAV service showed up as “down” in Virtualmin after upgrade,
I tried to click on the “start” button but no help, the same, it`s still down…
So I tried to start it manually via CLI (service clamav start) and than log-in back to the virtualmin again
and it still showed “down” and than when I clicked on the “start” it showed service “up” …
any idea why this happens ? any references that are changed perhaps ? since I run YUM UPDATE
and I saw that ClamAV was updated… and it asked me to remove one of the “double” files:
“daily” and “main” and I removed the double files and I have successfully updated its definitions…
ClamAV is up and running now when I start it manually via cli, but if I now restart the server for some reasons, than I have to run the same procedure again as described above, start manually via cli and than click on the “start” button in the webmin …
PS: and I have tested one more thing, and there is another issue related to this, when I started the ClamAV manually via cli, and clicked on the “start” in the Virtualmin than the service is up, but I also tried to stop for example HTTPD Apache in virtualmin and when it was stopped the Virtualmin showed that ClamAV was ALSO stopped EVEN if the ClamAV is still running as I saw it in the cli… so something is wrong here with the references I assume ?? can You please fix it asap ?
And ClamAV is not starting upon CentOS 6.2 boot now after upgraded…
Can You help please ?
I have now configured the ClamAV to start upon CentOS boot in Virtualmin, and when I restart the server now and than log-in back to the Virtualmin I see that all the services are up and running including ClamAv,
so this part seems to be ok.
BUT, I have also tested one more option, I tried to manually STOP and START all of the services in the Virtualmin and everything works just fine EXCEPT the ClamAV, when I tried to STOP it via Virtualmin, it showed up as DOWN but it
s not, its still running as I noticed that in via cli…
so it works just fine for all of the other services to start/stop them except with ClamAV…
I’m seeing this issue too.
yes, I belive others will see it soon once they run latest yum update…
I think I know what is the core problem here not sure 100% but I think this could be a problem
as you can see the ClamAV “service” file name in the “Webmin” - “System” - “Bootup and Shutdown” is now called “clamav” but I noticed that older ClamAV service name in the Webmin was “clamd” so I think ClamAV
developers changed the “service file name” in the latest ClamAV version which brokes the connection between Webmin-Virtualmin and ClamAv service it self…
Webmin is looking for “clamd” but it have a new name which is “clamav”
again, I am not sure 100% if this is the issue, but this is something I noticed…
And this could be a reason why we need to tell the Webmin AGAIN to boot the ClamAv upon CentOS boot…
because after ClamAV upgrade it was configured to NOT boot upon CentOS boot… so I configured it manually in the Webmin: “Webmin” - “System” - “Bootup and Shutdown” choose “clamav” and click “Start on boot”
And this is the reason why I have checked all other services “start” - “stop” in Virtualmin, and it works fine for all the services except the ClamAV… so I hope that they will fix it asap… it`s not a big deal as the service is up and running but it should be fixed…
Sounds like you’re on the right track Amel.
Could it be that we’ve jumped the gun a bit? VM was not reporting a ClamAV update - but when I did yum check-update, there it was. So I went ahead and installed it. perhaps VM is not quite ready for it yet, and so it was suppressed for the time being in the VM updates list?
hm, well when I am updating the server I am always using “yum update” from CLI, and all of the other configurations is done via VM gui… in my case, so once I run “yum update” I saw that ClamAV was ready for updating, so I am not sure if it`s right way to update the server, shell/can we use “yum update” or we should run it from VM… would not harm with some suggestion from Webmin-Virtualmin developers…
Sounds like You
re right about the update, if the VM does not noticed the ClamAV update perhaps its because this issue…
But we still need a suggestion here, shell we use “yum update” from CLI or run it from VM only ?
any progress on this one from Dev team ??
I wonder if perhaps you are installing a new ClamAV version from a different source?
I’d be interested to see the output from the following command on your system :
rpm -qa | grep clamav
I also enabled support access to one of my servers that has the same issue.
Check your email for details:
here is the command output:
rpm -qa | grep clamav
So, this appears to be a buglet in the clamav packages from EPEL (which we use for CentOS 6). There is a ticket about it in the Red Hat bugzilla here:
I’m very hesitant to begin building our own custom packages for this (as we try very hard to stick with OS-standard packages whenever possible, and EPEL is as close to OS-standard as we can get for ClamAV).
In the short-term simply starting the new clamav service manually will allow things to work normally. I’m looking into what I need to change to make this work correctly…I believe it is just a misnamed file in the RPM, and is a regression from the prior packages, which worked fine.
And as a heads-up, ClamAV can be manually started by logging into your server as root over SSH, and running this command:
Ok, I see…
and yes it`s working fine to start the server manually via CLI, so this is not “SO” critical but would be nice to
fix as soon as possible…
there is almost never need for restarting the ClamAV service via Virtualmin, but it`s nice to have that option if needed just as for all of the other services…
So I hope that You will fix this issue and let us know when it`s fixed…
and as I mentioned before it`s working fine to restart all of the other services in the Virtualmin except the ClamAV…
Thank You all for reply !
I’ve just rolled out a new version of clamav which reportedly fixes this issue. The new 0.97.3-3 version is in the CentOS 6 repos now. I haven’t tested it thoroughly, so I’m not entirely sure it resolves this issue, but we’ll see.
Fixed, but after the first reboot the the service did not start, I had to manually start. After a couple more reboot it start every time.
just installed it, works like a charm, I restarted the server in order to check it again and no problems at all
it started upon a server boot first time and no need to start it manually in my case…
in addition to this I have also tested manual start stop via Virtualmin and it works just fine as other services…
Thank You very much Joe !!