Great. One detail.

You don't want infected machines on a LAN. So it's safest to physically pull the Ethernet cable out.

This precaution, however, prevents virus definition updates over the net. Booting Linux (GRML) lowers the threat from Windows viruses to almost nothing, but in a corporate setting, the bosses don't believe something like that. They want to know, "Did you or did you not detach the Ethernet cable, yes or no, according to our written policy for suspicious machines."

Yeah, I know, it's silly. But these kinds of policies do exist.

In that situation it's nice to have an alternative way to get updated virus defs. I can use, for example, a CD-RW, or floppies, or Zip, or USB hard drive, etc. I'll have to check how to do that with Clam. I hope GRML can somehow retain them in RAM.

Thanks, Mark

Thanks for all that. Mika suggested freshclam. "Freshclam" fails from GRML CD 0.5-3.

I tried it on a PC with Internet. The updates are downloaded OK. But then this happens:

ERROR: Clamd was NOT notified: Can't connect to clamd through /var/run/clamav/clamd.ctl

GRML's ClamAV can't update from the internet. One therefore MUST use portable storage to get updates.

Mark

OK, that is right, I did not start clamav-daemon...but then you say there's no need for it...that's confusing.

I followed Mika's previous instructions and reported a result. Please tell me what to do! And without ellipses! The hard drive is /mnt/hda1 and NTFS (Win NT 4). It is the only hard drive. I followed instructions to the letter, as best I could.

Freshclam or not, Clamscan hangs the machine. Clamscan ran overnight with no output and no discernable disk drive activity. Mid-day it still sits here doing nothing. This hard drive is old and very loud so I would know.

I can use any commands you want, just tell me. I would prefer explicit advice. I never pretended to be a ClamAV expert. Maybe this test can become part of your 0.6 application checkout.

Mark

I did read docs. Nothing worked. So, I tested the same stuff on another machine and it worked. The problems are machine-specific.

This box is the older PC that I told you about. ClamAV works for me on other machines, but not that one. It just hangs, dead. It hangs when I start the daemon. It also hangs if I clamscan without any daemon.

There is no problem mounting the NTFS drive, I can see it just fine, ls files etc. However there is no normal ClamAV output -- pretty much a dead cursor after "clamscan<RETURN>". I can type and see characters, but it's not a real prompt, just dead space.

The bug could be ancient Dell BIOS, GRML 0.5-3, the boot floppy, or ClamAV, I don't know. Sorry for the mess but this is testing in action. I can try other things if you think it might help GRML development. All I can report right now is that normal ClamAV commands simply do not work on that box. The box only has 48 MB RAM so it might be low mem.

Thanks, Mark

Jupp, this is - very probably - the problem. Virus scanning definitely needs some RAM.

Maybe so but in that case the proper behavior is a graceful exit. An error message like "out of RAM" can go to stderr. It is still a bug to hang and do nothing.

I do not know whether the bug is ClamAV itself, or GRML, or Linux, some interaction. But out of memory is a classic testing condition that a lot of programmers neglect to handle.

Mark

Checking for "enough memory" isn't that easy. Detecting this in a userspace program like clamav won't really work.

Well, "enough memory to run this program" is not the right question, and you are right, impossible to solve in general. That's not how things work though.

A well written program (in user space or anywhere) checks the return codes for each memory allocation (new pointer). When it gets an error, it uses exceptions or some other logic to propagate up to an error handler. Ultimately the user should see something.

Programmers often write code that has no error handlers, doesn't check return codes, NULL pointers, etc. It's not that out of memory is unsolvable. It's that programmers don't exercise error discipline in their code.

To just hang dead is very, very bad behavior. One expects that from Windows, not Linux.

Mark