Atomicorp

I have started getting hundreds of this type of errors :

An example : What does this mean ? Never seen such errors in the past !

This started after the update of clamd a week or so ago ...

Just run asl -s -f

That will fix it

check if user "clamd" or user "root" is set in /etc/clamd.conf.
It needs to run as root in that case
EDIT: ups, to late... asl -s-f is doing this for you

For future reference, and just so everyone understands whats going on, the mod_clam module can work in two ways (and option two is dead, we killed it, more on that in a moment).

It can tell (1) clamd to read a file, or (2) proftpd can stream the file to clamd. Option 1 works really well, it scales and scales and scales - did I mention it scales? Option 2 doesnt scale very well, its limited by the OSes capacity to open even more sockets and to stream the file to clamd, wait for a response, etc. Option 1 requires clamd to run as root (clamd needs to be able to read files owned by any user), Option 2 allows clamd to run as a non-root user because its not reading files, just processing a stream.

We used to do this via Option 2 and wrote the code to do it, it just didnt scale. Option 1 works great, and you have to run clamd as root anyway if you want to do real time file scans with the dazuko kernel module. So option 1 has two things going for it, it scales, and it allows you to do real time file system scans.

So, if you see this error, you need to run clamd as root. Everything (qmail-scanner, clapf, dazuko, proftp, etc. etc.) works just fine with clamd running this way so theres no need to run clamd as a non-root user.

mikeshinn wrote:For future reference, and just so everyone understands whats going on, the mod_clam module can work in two ways (and option two is dead, we killed it, more on that in a moment).

It can tell (1) clamd to read a file, or (2) proftpd can stream the file to clamd. Option 1 works really well, it scales and scales and scales - did I mention it scales? Option 2 doesnt scale very well, its limited by the OSes capacity to open even more sockets and to stream the file to clamd, wait for a response, etc. Option 1 requires clamd to run as root (clamd needs to be able to read files owned by any user), Option 2 allows clamd to run as a non-root user because its not reading files, just processing a stream.

We used to do this via Option 2 and wrote the code to do it, it just didnt scale. Option 1 works great, and you have to run clamd as root anyway if you want to do real time file scans with the dazuko kernel module. So option 1 has two things going for it, it scales, and it allows you to do real time file system scans.

So, if you see this error, you need to run clamd as root. Everything (qmail-scanner, clapf, dazuko, proftp, etc. etc.) works just fine with clamd running this way so theres no need to run clamd as a non-root user.

Nothing to argue !

But shoudln't be setup this way by default on the asl and asl related configs ? Will a simple asl -s -f fix this issue ? If not what should we do ?

Thanks !

nobody wrote:Nothing to argue !

But shoudln't be setup this way by default on the asl and asl related configs ? Will a simple asl -s -f fix this issue ? If not what should we do ?

Thanks !

As Brucelee stated above, asl -s -f fixes this. You should always, always, always run asl -s -f after modifying your setup. Every time. Without exceptions. Modifiying in this case includes yum update etc.

Yes, ASL configures clamd correctly by default - some third party packages may mess with your clamd configuration and set the user to something other than root, ASL will NEVER do this.