Disable clamav services

[Eugene Sobolev]

Hello.
We are using Proxmox Mail Gateway in conjunction with another antivirus solution via custom script.
Even though the clamav parameter in the admin section of /etc/pmg/pmg.conf is set to 0, and the clamav-daemon service is disabled, it starts every hour.

This happens because

PMG::Utils::service_cmd('clamav-daemon', 'start');

is executed in /usr/lib/pmg/bin/pmg-hourly

Masking clamav-daemon.service is a bad idea - pmg-hourly.service will fail. Among other things, it is responsible for synchronization with LDAP, and in monitoring it will be unclear what exactly broke

I suggest a simple patch

--- /usr/lib/pmg/bin/pmg-hourly.orig    2026-05-15 13:22:45.705069057 +0300
+++ /usr/lib/pmg/bin/pmg-hourly 2026-05-14 19:33:18.882627092 +0300
@@ -52,7 +52,10 @@
 system('sa-learn --sync >/dev/null 2>&1');
 
 # make sure clamav-daemon is running
-PMG::Utils::service_cmd('clamav-daemon', 'start');
+my $use_clamav = $cfg->get ('admin', 'clamav');
+if (!defined($use_clamav) || $use_clamav!=0){
+    PMG::Utils::service_cmd('clamav-daemon', 'start');
+}
 
 exit(0);

PS: Restarting the clamav-freshclam and clamav-daemon services can also occur in /usr/share/perl5/PMG/Config.pm when changing antivirus settings via the web gui.

 

[Sviat]

HI,

could you post an enhancement request in PMG bugzilla?

 

[waltar]

Yeah, clamav, one of the coolest fileserver I/O benchmark programs ... run with xargs to the number of available host cores and see what your filesystem can or not can do ...

 

[pedalblouse]

Hello.
We are using Proxmox Mail Gateway in conjunction with another antivirus solution via custom script.
Even though the clamav parameter in the admin section of /etc/pmg/pmg.conf is set to 0, and the clamav-daemon service is disabled, it starts every hour.

This happens because

PMG::Utils::service_cmd('clamav-daemon', 'start');

is executed in /usr/lib/pmg/bin/pmg-hourly

Masking clamav-daemon.service is a bad idea - pmg-hourly.service will fail. Among other things, it is responsible for synchronization with LDAP, and in monitoring it will be unclear what exactly broke
dordle
I suggest a simple patch

--- /usr/lib/pmg/bin/pmg-hourly.orig    2026-05-15 13:22:45.705069057 +0300
+++ /usr/lib/pmg/bin/pmg-hourly 2026-05-14 19:33:18.882627092 +0300
@@ -52,7 +52,10 @@
 system('sa-learn --sync >/dev/null 2>&1'); [URL='https://dordle.io/']dordle[/URL]
 
 # make sure clamav-daemon is running
-PMG::Utils::service_cmd('clamav-daemon', 'start');
+my $use_clamav = $cfg->get ('admin', 'clamav');
+if (!defined($use_clamav) || $use_clamav!=0){
+    PMG::Utils::service_cmd('clamav-daemon', 'start');
+}
 
 exit(0);

PS: Restarting the clamav-freshclam and clamav-daemon services can also occur in /usr/share/perl5/PMG/Config.pm when changing antivirus settings via the web gui.

That is a brilliant catch and a super clean patch. We're running a similar setup with a third-party AV scanner and it's been driving me absolutely crazy watching clamav-daemon blindly resurrect itself every hour despite being explicitly disabled in the GUI and config! Masking the service completely breaks pmg-hourly and clogs up the monitoring logs with false alerts, so checking the actual admin configuration object before running the service command is 100% the right way to handle this. You should definitely push this diff over to the Proxmox Bugzilla or their developer mailing list; it's a legitimate oversight in how PMG respects its own configuration variables, especially since Config.pm also likes to step on it during GUI changes. Thanks for sharing the fix!