This article about fixing stopped Clam service is more technical than most I post here. It addresses an issue that arose on a server a couple times over the past years. That box has been around for a bit. I’ll be rebuilding and upgrading it in the near future. But servers have to work correctly until that upgrade actually happens. So I thought I’d speak to the issue on the off chance that this article might help someone else out there.

Introduction to ClamAV (Clam Antivirus)

Clam Antivirus (ClamAV) is a free, open-source antivirus tool used widely across various operating systems, including CentOS. It is particularly valuable for scanning emails, web content, and files for malware and viruses, making it an essential tool for maintaining the security and integrity of a production web server. Running such a service on a production server not only ensures the security of the server’s data but also safeguards the users who interact with the server’s resources.

Encountering and Resolving ClamAV Issues

On this DirectAdmin server, I’ve encountered a recurring issue where the ClamAV service, specifically clamd@scan, would intermittently stop running. This service is crucial for scanning files and emails for threats, and its downtime could potentially expose the server to undetected threats. It’s an utmost priority to avoid this.

Identifying the Problem

The first sign of trouble was a notification message from the system indicating that clamd@scan was down. The notifications happen each hour. Confirming this, the Service Monitor within DirectAdmin showed the status of clamd@scan as Stopped.

Steps for Fixing Stopped Clam Service

Resolving this issue involves several steps, executed via SSH (using tools like PuTTY). Then it involves editing files with Nano, (my favorite Linux text editor). Nano is available on CentOS and in most Linux versions.

Ensuring Root Access:
To perform the necessary steps, ensure you have root access. This can typically be achieved by placing your SSH key in the /root/.ssh/authorized_keys file, allowing for secure, password-less login as the root user. Or you can simply log in using your username and password either online or if you have physical access to the box as I have here at CharlesWorks.

Addressing the Issue:
1. Disabling ClamAV in DirectAdmin:

• • Navigate to the /usr/local/directadmin/data/admin/services.status file.
  • Temporarily set the ClamAV lines to off by editing the file with Nano:

    nano /usr/local/directadmin/data/admin/services.status

    Then, change the lines for clamav-freshclam and clamd@scan to OFF.

2. Manually Starting the ClamAV Service:

• • Use the command:

    systemctl start clamd@scan

    This command initiates the ClamAV service manually, allowing it to fully start and load its databases.

3. Monitoring the Service:

• • After manually starting the service, it is advisable to monitor it through DirectAdmin’s Service Monitor to ensure it remains running.

Understanding DirectAdmin and ClamAV Configurations

It’s important to differentiate between CustomBuild settings and the services.status file in DirectAdmin:

• • CustomBuild Settings: These determine if ClamAV is enabled on the server and should include its configurations in other services like Exim.
  • Service Status File: The /usr/local/directadmin/data/admin/services.status file controls process monitoring by DirectAdmin. Setting a service to OFF here means DirectAdmin won’t attempt to restart it automatically, but does not disable the service itself.

Troubleshooting Tips

• • Always ensure your server has enough resources to handle ClamAV’s demands.
  • Regularly check the DirectAdmin Service Monitor for the status of ClamAV services.
  • Keep your server’s SSH access secure and functional for quick interventions.

By following these steps, you can ensure that ClamAV continues to protect your server without causing unnecessary downtime.

Conclusion

Though ClamAV is resource-intensive, proper management and configuration can prevent it from becoming a point of failure. If the server has sufficient resources, like my 32GB RAM setup, ClamAV should run smoothly with minimal intervention. However, unexpected shutdowns or power losses can still lead to service interruptions, necessitating the outlined manual restart procedures. For more information about ClamAV (Clam AntiVirus) there is documentation at the https://docs.clamav.net/ site.

Understanding the Fix

DirectAdmin technicians showed me how to isolate and manually restart the ClamAV service. This method is grounded in system administration best practices. Such a strategy clears any lingering issues by first stopping all ClamAV instances and then carefully restarting the service. It addresses potential problems related to resource contention and improper initialization. These are common when multiple instances of a resource-intensive service like ClamAV attempt to start simultaneously. Or they can happen when the service fails to properly load its extensive virus databases due to interrupted starts or system resource limitations.

“Resource contention” refers to a situation where multiple processes or services simultaneously attempt to use the same resources (such as CPU, memory, disk I/O, or network bandwidth) in a way that the demands exceed the available capacity. This competition for limited resources can lead to various problems, including decreased performance, slower response times, and in extreme cases, service failures or crashes.

In the context of a server running ClamAV (Clam AntiVirus), if multiple instances of the ClamAV service were to start at the same time, they would all try to access the server’s CPU and memory resources concurrently to load their virus databases and perform initializations. Given that ClamAV is known to be resource-intensive, especially during startup when it loads its databases, having multiple instances trying to initialize simultaneously can strain the server’s resources. This strain might not only impede ClamAV’s ability to start properly but could also affect the performance of other services running on the server, leading to a scenario of resource contention where not all processes can be adequately served.

Moreover, adjusting DirectAdmin’s service monitoring to accommodate ClamAV’s unique requirements helps prevent the service from entering a restart loop, a scenario where the service repeatedly attempts to restart without sufficient time to fully initialize. This nuanced understanding of ClamAV’s operational characteristics and the distinction between DirectAdmin’s CustomBuild settings and the services.status configuration ensures that ClamAV can effectively safeguard the server without unnecessary interruptions, providing a stable and secure server environment.