Hi there,
On Thu, 31 Dec 2020, Jay A. Schoon via clamav-users wrote:
> ...
> Here are the things I would like to do:
>
> - Run scans that utilize multiprocessors (I believe I do have clamd
> installed, I just don?t know how to use it)
The clamd daemon can run multiple threads/cores, but using clamd and
using multiple cores are completely different things and have more or
less nothing to do with each other. You can for example run multiple
instances of clamscan, but whether you will realize the performance
improvement you might hope for will depend on factors such as storage
seek times, throughput rates and a host of other things too.
Experiment a little to see if you can get any worth-while improvements
with some simple tests, and while you wait for the results think about
what you're doing (and indeed whether it makes sense) rather than how
you're doing it. Get your computer to work smarter, not harder.
Now I'm going to simplify a bit, and later on mention some 'if's.
1. The clamd daemon.
The 'd' in 'clamd' is a not-especially-standard way to tell you that
clamd is what's called a 'daemon'. This means that when you start the
process, it doesn't interact with you through the terminal in the way
that other processes do. For example, after you start your editor, or
word processor or spreadsheet or mail client, they will generally wait
for some input from your keyboard and/or or mouse, and then act on it.
A daemon doesn't work that way. For a daemon, the way the software is
written is a little different, in that even if you start it from your
terminal (using the 'shell') it will 'detach' from the terminal, so it
no longer listens to that connection, and therefore no longer listens
to you. Unlike when you start an 'interactive' program like an editor
where you type a command to start the editor and the next things typed
are editor commands, when you start a daemon you will usually see the
shell command prompt come back on the screen because you're talking to
the shell again - not the daemon. For interactive programs, when the
shell prompt comes back it means that the process has terminated. The
process that you started has stopped. Maybe you stopped it e.g. using
a Quit command, maybe it even crashed. If you type 'emacs' at a shell
prompt, you run the editor to edit something then exit the editor; the
editor process is no longer running and you get the shell prompt back.
For a daemon it's different. The process has started, and it's given
your terminal input and output back to the shell but continues to run.
For clamd that's all there is to it. By itself, it won't do anything
at all. It will just sit there, consuming resources until you tell it
to do something somehow. Something other than terminal input tells it
what to do.
When running as a daemon the clamd process waits for instructions but
it doesn't get its instructions from your keyboard or your mouse. It
gets them from a 'socket'. It 'opens' the socket and 'listens' to it.
You can send instructions to clamd through the socket in several ways,
for example you can use the 'clamdscan' command - that's the simplest
way to use clamd. The clamdscan command interprets what you tell it
on its command line (the clamdscan command line) and communicates with
clamd over the socket on which clamd is listening to tell it what you
have asked it to do. So clamd does the scanning, not clamdscan. The
other ways to use the clamd daemon involve progressively more complex
setups which you aren't yet ready for. Be aware that starting clamd
can take "a while" because it has to read and compile on the order of
ten million lines from its database files. If you add any third-party
databases to your database directory, it can be even more than that.
Depending on system performance, "a while" can be a few seconds to a
few minutes. During the time it's starting up, clamd won't be able to
scan anything. When it has loaded the ClamAV 'official' database, it
will be using around a gigabyte of memory. More signatures, more RAM.
When it reloads the databases it will (temporarily) use about twice as
much RAM (by default - there's an option to make it behave like at the
first start, where it will use less memory but it won't scan while it
reloads the databases).
2. Scanning commands.
Note that there are two commands with similar names. The 'clamdscan'
command uses the clamd daemon and won't work if clamd isn't running.
The 'clamscan' command doesn't use clamd at all. So one way to tell
if you have clamd running, and a lot of other things properly set up
(such as configuring clamd and clamdscan to use the same socket!) is
simply to try to scan something using clamdscan. If it can't connect
to the daemon it will tell you so. That might mean either that clamd
isn't running or that the communications between clamdscan and clamd
aren't working. If you look at the list of process which are running
on the computer, you should be able to see clamd in the list if it's
running - but you need to make sure you have permission to see it for
example by using the root account. Always be very careful what you do
when you're using the root account, there's nothing to stop you from
destroying the entire system with a single, simple command. Do please
be especially careful if you get into the habit of recalling commands
from the root shell's history and re-executing them with a couple of
quick keystrokes. Don't ask me how I know all about that.
The clamscan command will take about as long to start up as clamd does
before it actually starts scanning anything, and while it's running it
will take as much memory as clamd does. So if clamd uses a gigabyte,
and you start clamscan, you'll need another gigabyte just for clamscan
because clamscan won't use clamd, nor the memory it's using. (Give or
take operating system efficiency things like shared memory pages which
probably won't help much in this case).
You need to read a bit more about clamd and how it's used, decide if
you actually want to use it at all (and pay the prices of using it,
such as RAM and complexity) and then of course configure it to suit
your installation and your requirements. If you want to schedule a
scan you can either use clamscan (and not run clamd) or clamdscan and
clamd together. I never run scheduled scans, of anything. I only use
clamd to scan mail, as it's passing through an MTA.
3. I promised some if's:
Usually a daemon can in fact be instructed _not_ to detach from the
terminal, often this is for testing and debugging.
Most often you don't start most daemons from the command line at all.
You'll have set up something in the operating system's boot routines
for example which does that. There are lots of ways of doing it.
Most daemons start and then run for a long time. The clamd daemon is
one example. The clamd daemon on my dedicated mail scanning server
has been running since the middle of November. Some daemons control
other daemons. For example, many are controlled by the well-known
'inetd' or 'xinetd' daemons. They may be started when something of
note happens in the operating system - like a TCP or UDP connection
being made to it - and the daemon may run for just a few seconds, or
even less, just while it's servicing the event.
Some daemons don't listen on sockets at all. Things like watchdogs for
example might just sleep, and periodically wake up to see if everything
they're supposed to be keeping an eye on is OK, then go back to sleep.
If things are not OK they might do anything from restart some process
which has died to reboot the entire system.
There are lots of other if's but I'm sure you get the picture and I'm
straying a little beyond the list's topic guidelines here.
> - Schedule virus scans (a assume this can be done through a Bash
> script with Automator)
I do own a Mac, but I haven't used it for twenty years so I'm very
rusty on Mac stuff and others will probably be able to help you better
than I can with Mac specifics. However I'm sure that you can use the
Mac OS 'cron'-like facility to do what you want. Here's a random page
that I found with a quick search:
https://alvinalexander.com/mac-os-x/mac-osx-startup-crontab-launchd-jobs/ I feel the need to ask what you hope to achieve by doing something
like this that you can't achieve better in other ways. If you have to
ask the questions you're asking now, please consider that if you do
find something nasty on the Mac then it might already be too late to
do anything about it except wipe the system and start again. I've
been using Linux systems for more than a quarter of a century, but
even so I know that if I found an infection in one of my systems I'd
be very reluctant ever to use it again. I'd remove any data from it
in a safe way, then blow it away. I'd probably scrap all the discs,
and look really hard at all the firmware (e.g. UEFI or BIOS chips).
That's because once the Bad Guys have got in, there's almost no limit
to the ways they can use to hide, and some of them are probably a lot
better at this stuff than I am because it's how they make a living.
> - Stipulate which volumes and directories to scan/exempt
That's covered in the documentation, available online and most likely
also in the documentation installed on your machine, which you need to
learn how to use. It will be well worth the effort, there's a lot at
your fingertips available for the price of a one-line keyboard command.
It's also worth perusing the mailing list archives. You might want to
do that before asking more questions here.
Don't scan things like /dev, /proc, and /sys, and if you scan anything
in /var be very selective about it because there's probably a _lot_ of
stuff in there which is (a) changing constantly and (b) not worth the
effort of scanning at all because it presents no risk.
> - Choose to quarantine infected items
See the documentation again, but I recommend that you do not attempt to
do this until you're much more familiar with your system. If you choose
to ignore my advice you will probably pose a bigger threat to the system
than the threats you think you're protecting it against, because there is
always a fairly high risk of false positives. If ClamAV identifies one
of your important system files falsely as malicious, and you quarantine
it, you might be left with a system that is sufficiently broken that it
won't boot, and you might not have the skills necessary to fix it. It's
perfectly possible that a false positive will be introduced by the very
next signature added to the database by the ClamAV team or a third-party
and automatically installed by freshclam; you might create one yourself.
> - Auto-scan files on access
Again see the documentation, but be aware that (1) performance can be
an issue (2) my rule of thumb is that on a good day, ClamAV detects
about one in three malicious items (on a bad day, none of them) and
(3) the Linux facilities used by ClamAV to implement this feature do
not exist on the Mac operating systems, so as has already been pointed
out you'll have some extra work to do that most other users won't.
> Happy New Year!
And the same to you, and all.
--
73,
Ged.
_______________________________________________
clamav-users mailing list
clamav-users@lists.clamav.net
https://lists.clamav.net/mailman/listinfo/clamav-users Help us build a comprehensive ClamAV guide:
https://github.com/vrtadmin/clamav-faq http://www.clamav.net/contact.html#ml