Virus Blocker not in rack -- ClamAV still runs?

[Polydwarf]

I'm trying to track down why ClamAV is running when I don't have virus blocking even installed in the rack, let alone turned on. It is running and restarting itself every two minutes (Not due to freshclam updates, as in a prior post I made; that issue seems to have resolved itself). It doesn't need to be running at all, from what I can see.

When I tried an apt-get remove clamav, though, a lot of stuff came up that makes me a little cautious.

/var/log/clamav # apt-get -s remove clamav                                                                                                                        [root @ gateway]
Reading package lists... Done
Building dependency tree
Reading state information... Done
The following packages were automatically installed and are no longer required:
  untangle-libitem-shield libnet-ident-perl untangle-webfilter-init unrar untangle-node-cpd giflib-tools liblua5.1-logging untangle-libitem-spamassassin libwmf0.2-7
  libdjvulibre21 djvulibre-desktop libimage-exiftool-perl libilmbase6 liburi-perl re2c untangle-node-ips liblua5.1-filesystem0 libungif-bin untangle-casing-http libmail-spf-perl
  clamav-freshclam untangle-node-firewall untangle-casing-mail libfont-afm-perl libmailtools-perl untangle-libitem-firewall liblua5.1-cgi0 libsocket6-perl libmagick10
  untangle-snort-rules libhtml-parser-perl liblua5.1-socket2 untangle-libitem-cpd liberror-perl libnetaddr-ip-perl clamav-base transfig untangle-libitem-protofilter
  untangle-fuzzyocr libclamav6 spamassassin untangle-libitem-ips libgd2-noxpm liblua5.1-sql-sqlite3-2 libjson0 lua5.1 liblua5.1-md5-0 arj untangle-node-openvpn
  libimage-exif-perl php5-curl liblua5.1-expat0 razor untangle-node-spyware untangle-libitem-openvpn libopenexr6 clamav-daemon lha libnet-ip-perl untangle-node-spamassassin
  libnet-dns-perl untangle-libitem-spyware php5-pgsql netpbm libmicrohttpd4 untangle-base-webfilter untangle-cpd libpkcs11-helper1 libjasper1 untangle-node-protofilter
  untangle-spamassassin-update gocr libhtml-format-perl zoo untangle-libitem-reporting untangle-libitem-webfilter libnetpbm10 libtommath0 untangle-shield libstring-approx-perl
  imagemagick libhtml-tree-perl untangle-base-spam arping openvpn libwww-perl libdigest-hmac-perl libjpeg-progs libgraphviz4 libhtml-tagset-perl untangle-node-reporting
  untangle-node-webfilter libnet1 libsys-hostname-long-perl libjson-ruby liblua5.1-sql-postgres-2 untangle-base-virus openvpn-blacklist gsfonts untangle-node-shield
  libdigest-sha1-perl
Use 'apt-get autoremove' to remove them.
The following packages will be REMOVED:
  clamav untangle-clamav-config untangle-libitem-clam untangle-libitem-lite-package untangle-libitem-phish untangle-node-clam untangle-node-phish
0 upgraded, 0 newly installed, 7 to remove and 0 not upgraded.
Remv untangle-libitem-lite-package [9.0.2~svn20101208r28039release9.0-1lenny]
Remv untangle-libitem-phish [9.0.2~svn20101208r28039release9.0-1lenny]
Remv untangle-node-phish [9.0.2~svn20110815r29485release9.0-1lenny]
Remv untangle-libitem-clam [9.0.2~svn20101208r28039release9.0-1lenny]
Remv untangle-node-clam [9.0.2~svn20110815r29485release9.0-1lenny]
Remv untangle-clamav-config [9.0.2~svn20100713r27098release9.0-1lenny]
Remv clamav [0.96.3+dfsg-2~volatile1]
root@gateway#                                                                                                                                                                      /var/log/clamav #                                                                                                                                                 [root @ gateway]

I'm not at all tempted to do an autoremove as I see things in the autoremove list that look wrong. For instance.. OpenVPN is in the rack, but turned off.. however, autoremove thinks it isn't used anymore anyways; maybe because I used the lite pacakge to install everything, so I'm removing something, it wants to remove the lite package, and thus everything else?

In any event... The question remains : Why is clamav running when it is not in the rack? And then, what is the best way to turn clamav off? It has shown itself to be touchy, and since it is not needed, I'd rather remove that moving part from the system so it can't break.

[dmorris]

Originally Posted by Polydwarf

In any event... The question remains : Why is clamav running when it is not in the rack? And then, what is the best way to turn clamav off? It has shown itself to be touchy, and since it is not needed, I'd rather remove that moving part from the system so it can't break.

because its installed.

you can safely just apt-get remove it if you don't want it.
it will also remove everything that depends on it.

[AdamB]

Originally Posted by dmorris

because its installed.

you can safely just apt-get remove it if you don't want it.
it will also remove everything that depends on it.

So just to clarify this a bit. Your saying if the AV module is uninstalled clamAV is still installed and needs to be removed manually?

[dmorris]

I'm saying:
If you installed Virus Blocker in one or mork racks, then removed it from all racks, the clamav-daemon is still installed on the server.

Does it need to be removed manually? No. It doesn't need to be removed at all.

[Polydwarf]

Originally Posted by dmorris

I'm saying:
If you installed Virus Blocker in one or mork racks, then removed it from all racks, the clamav-daemon is still installed on the server.

Does it need to be removed manually? No. It doesn't need to be removed at all.

It seems that it should at least be disabled, though.

'/etc/init.d/clamav-daemon stop' does not (permanently) stop it... Possibly due to the original problem where it seems to restart itself every two minutes.

After doing some more digging on my own, my guess is that it's the monitor restarting it (see /etc/untangle/monit.d/clamav_i386.conf (and the amd64 equivalent)).

Is there any situation in which Untangle updates ever touch these two conf files? If not, it looks to be pretty trivial to get rid of this problem by modifying them.

If those files do get updated, what about the actual init script for clam and freshclam in /etc/init.d?

[mrunkel]

they sit there doing nothing consuming almost no resources. what problem are you trying to solve?

[CADman_ks]

Originally Posted by mrunkel

they sit there doing nothing consuming almost no resources. what problem are you trying to solve?

Ultimately, I think that he's trying to fix this issue that he's having:

http://forums.untangle.com/virus-blo...ng-itself.html

It doesn't seem like it should be trying to update every 2 minutes.

CADman_ks

[Polydwarf]

The issue in my prior thread disappeared in my latest round of untangle formatting/reinstalling. I never did figure out why it happened, but given my more recent experience, I'd guess it's the monitor daemon that did it, due to entries in /etc/untangle/monit.d/clamav_*.conf. This problem has different causes, but end up in the same situation (High cpu usage for no good reason)

However, CADman has the right idea, for sure. My thought was to modify the /etc/untangle/monit.d/clamav_*.conf and/or /etc/init.d/clamav-* init scripts to make sure clam doesn't run. An apt-get remove does not look to be safe, at least during business hours where Untangle has to stay up and fully functional, due to it looking like a lot of stuff will break if I keep it tidy (IE, do an autoremove) because I installed with the Lite package. I may explore doing that in off-hours, though.

Since I don't have it in racks, and have no intention to, I honestly don't care if clam runs. And considering it likes to restart itself every couple of minutes, and chew up a lot of CPU in the process...

And yes, we were having user complaints (mostly related to DNS being flaky off of DNSMasq). Given that high CPU usage was evident, the goal was to get that down without spending money on new hardware.


Hence why I asked whether Untangle pushes down updates to the following files:

/etc/init.d/clamav-daemon
/etc/init.d/clamav-freshclam
/etc/untangle/monit.d/clamav_i386.conf
/etc/untangle/monit.d/clamav_amd64.conf

I've done a proof-of-concept on the init scripts to make sure clam doesn't run, and that's working just fine now. I want to make sure my work won't get overwritten in the future.

[dmorris]

yes, all changes made at the terminal/console level are subject to getting nuked on upgrade.

If you don't want virus blocker I would not install the lite package as the lite package includes virus blocker. I would just reinstall and install the applications you want.

sure, but any dns complaints you had were likely not related in any way to the clamav daemon, and almost surely you will have more issues after you make a mess of your server by changing a bunch of files by hand. Be our guest, just know that what you are doing may be fun but is not in any way rational.

[Polydwarf]

Originally Posted by dmorris

yes, all changes made at the terminal/console level are subject to getting nuked on upgrade.

Thank you.

Originally Posted by dmorris

If you don't want virus blocker I would not install the lite package as the lite package includes virus blocker. I would just reinstall and install the applications you want.

sure, but any dns complaints you had were likely not related in any way to the clamav daemon, and almost surely you will have more issues after you make a mess of your server by changing a bunch of files by hand. Be our guest, just know that what you are doing may be fun but is not in any way rational.

I agree, the DNS issues we had were likely not specifically due to ClamAV doing some virus checking. We were troubleshooting, though, and saw high cpu usage on the server (average, not spike, in the 0.8 to 1.0 range, on a single core box) due to ClamAV, so that seemed like a likely target for elimination since we weren't using it in the first place. And since I edited the init scripts to make sure clam doesn't run, the DNS issues have stopped. Coincidence? Maybe. I'll take that coincidence, though.

I don't view editing conf files and init scripts as fun; frankly, I'd much rather be doing a dozen other things than babysitting a router. If you want to debate the rationality of a particular approach, that's fine. However, this thread doesn't seem to be the place for it.