[Clamav-users] Problems with logrotate and freshclam

2006-04-16 Thread Leonardo Rodrigues Magalhães


   Hello Guys,

   I'm facing a strange problem with freshclam and log rotation using 
logrotate. Let me explain 


   Altough i'm not using pre-compiled RPMs, i took some files from the 
RPMs. One of these files is the /etc/logrotate.d/freshclam. I did some 
adjusts on the user/group, so my file looks like:


#
# Rotate FreshClam daemon log file
#

/var/log/clamav/freshclam.log {
   missingok
   create 640 vscan vscan
   postrotate
   /bin/kill -HUP `cat /var/run/clamav/freshclam.pid 2> /dev/null` 
2> /dev/null || true

   endscript
}



   It's working, freshclam.log is getting correctly rotated. The 
problem is that after log rotation, i cannot call freshclam from console 
anymore.


[EMAIL PROTECTED] ~]# freshclam
ERROR: Problem with internal logger.
[EMAIL PROTECTED] ~]#

   Altough freshclam IS working, as I can see activity on the 
freshclam.log file, i only get the 'problem with internal logger' when 
calling it from the console. A simple stop/start on the service seems to 
solve the problem. After stop/start, freshclam keeps running on the 
background and can be called from the console as well.


   I dont know if this can be the reason for the problem  watching 
the file descriptors through lsof, i can see the freshclam.log file 
descriptor:


[EMAIL PROTECTED] ~]# lsof -n | grep "freshclam\.log"
freshclam 20602   vscan0wW REG8,3 2076   24510465 
/var/log/clamav/freshclam.log

[EMAIL PROTECTED] ~]#

   After stop/start, it looks like:

[EMAIL PROTECTED] ~]# lsof -n | grep "freshclam\.log"   
freshclam 20360   vscan3w  REG8,3 2436   24510465 
/var/log/clamav/freshclam.log

[EMAIL PROTECTED] ~]#

   The different seems to be on the FD field. Before the stop/start it 
looks wW, which will give the 'problem with internal logger' error, but 
will keep freshclam working fine on background. After stop/start, FD 
field will look 3w, which will keep freshclam working both on background 
and console.


   I have googled and found some users complaining about problems with 
logging, but the problems were related to permission on 
file/directories, which is not my case. I have checked/rechecked and 
things seems fine.



   Is this kind of problem known ? Is there any tip/hint on how to 
avoid/solve it ?


   Thanks for your attentions guys.


--


Atenciosamente / Sincerily,
Leonardo Rodrigues
Solutti Tecnologia
http://www.solutti.com.br

Minha armadilha de SPAM, NÃO mandem email
[EMAIL PROTECTED]
My SPAMTRAP, do not email it




___
http://lurker.clamav.net/list/clamav-users.html


RE: [Clamav-users] Problems with logrotate and freshclam

2006-04-16 Thread clamav
> files from the RPMs. One of these files is the 
> /etc/logrotate.d/freshclam. I did some adjusts on the 
> user/group, so my file looks like:
> 
> #
> # Rotate FreshClam daemon log file
> #
> 
> /var/log/clamav/freshclam.log {
> missingok
> create 640 vscan vscan
> postrotate
> /bin/kill -HUP `cat /var/run/clamav/freshclam.pid 2> 
> /dev/null` 
> 2> /dev/null || true
> endscript


I'm not certain, but I think the problem is that you're creating the log
file while freshclam is still using it.  The "create" command in logrotate
says:

  Immediately *after* rotation (*before* the postrotate script is run)
  the log file is created (with the same name as the log file just
  rotated).

Sending the HUP signal to freshclam after the create isn't what you want.
Freshclam just closes its connection to the logfile upon receiving the HUP
signal, and opens a new one upon first write.




___
http://lurker.clamav.net/list/clamav-users.html


Re: [Clamav-users] Problems with logrotate and freshclam

2006-04-16 Thread Leonardo Rodrigues Magalhães



[EMAIL PROTECTED] escreveu:

I'm not certain, but I think the problem is that you're creating the log
file while freshclam is still using it.  The "create" command in logrotate
says:

  Immediately *after* rotation (*before* the postrotate script is run)
  the log file is created (with the same name as the log file just
  rotated).

Sending the HUP signal to freshclam after the create isn't what you want.
Freshclam just closes its connection to the logfile upon receiving the HUP
signal, and opens a new one upon first write.
  


   I think that's correct .. this is, by far, the most used log 
rotation procedure.


   logrotate 'rotates' logfiles: rename all the old files and increase 
their numbers, remove the oldest one and rename the actual freshclam.log 
to freshclam.log.1. Logrotate, then, creates a new freshclam.log with 
permissions and owner/group configured. Until now, freshclam doesnt know 
what's happening. File descriptor will continue to point freshclam.log.1 
file and not our new freshclam.log. If nothing happens, freshclam daemon 
will continue to write on it's filedescriptor, thus writing information 
on the 'old' logfile and not the new one. So, there goes the HUP . 
it will instruct freshclam daemon to close and reopen logfiles, thus 
getting the filedescriptor on the newly created freshclam.log,


   I dont think that's the problem, at least this is the procedure i've 
seen a LOT of daemons using for log rotations. And i took these 
freshclam logrotate file from the official RPMs, i have to suppose they 
are correct :)


   Anyway, thanks for your answer !

--


Atenciosamente / Sincerily,
Leonardo Rodrigues
Solutti Tecnologia
http://www.solutti.com.br

Minha armadilha de SPAM, NÃO mandem email
[EMAIL PROTECTED]
My SPAMTRAP, do not email it




___
http://lurker.clamav.net/list/clamav-users.html


[Clamav-users] clamscan error and requirements

2006-04-16 Thread roger martinez
After a clamscan command ,i obtain this output with
clamav0.88.1 source release


LibClamAV Error: fileblobAddData: Can't write 76 bytes to
temporary file textpart: No space left on device
LibClamAV Error: fileblobAddData: Can't write 76 bytes to
temporary file textpart: No space left on device
LibClamAV Error: fileblobAddData: Can't write 76 bytes to
temporary file textpart: No space left on device
LibClamAV Error: fileblobAddData: Can't write 76 bytes to
temporary file textpart: No space left on device
LibClamAV Error: fileblobAddData: Can't write 76 bytes to
temporary file textpart: No space left on device
LibClamAV Error: fileblobAddData: Can't write 76 bytes to
temporary file textpart: No space left on device
LibClamAV Error: fileblobAddData: Can't write 76 bytes to
temporary file textpart: No space left on device
LibClamAV Error: fileblobAddData: Can't write 76 bytes to
temporary file textpart: No space left on device
LibClamAV Warning: Multipart MIME message contains no boundaries
LibClamAV Warning: Multipart MIME message contains no boundaries
LibClamAV Warning: Multipart MIME message contains no boundaries
LibClamAV Warning: Multipart MIME message contains no boundaries
LibClamAV Warning: Multipart MIME message contains no boundaries
LibClamAV Warning: Multipart MIME message contains no boundaries
LibClamAV Warning: Multipart MIME message contains no boundaries
LibClamAV Warning: Multipart MIME message contains no boundaries
LibClamAV Warning: Multipart MIME message contains no boundaries
LibClamAV Warning: Multipart MIME message contains no boundaries
LibClamAV Warning: Multipart MIME message contains no boundaries
LibClamAV Warning: Multipart MIME message contains no boundaries
LibClamAV Warning: Multipart MIME message contains no boundaries
LibClamAV Warning: Multipart MIME message contains no boundaries
LibClamAV Warning: Multipart MIME message contains no boundaries
LibClamAV Warning: Multipart MIME message contains no boundaries
#

and the resultt is :


--- SCAN SUMMARY ---
Known viruses: 51002
Engine version: 0.88.1
Scanned directories: 75
Scanned files: 404
Infected files: 0
Data scanned: 495.85 MB
Time: 394.753 sec (6 m 34 s)

hard drive partitionning is :

Sys. de fich.1K-blocs   Occupé Disponible Capacité
Monté sur
/dev/hda8   964500287920627584  32% /
tmpfs   517496 0517496   0% /dev/shm
/dev/hda1  7164956   2476116   4688840  35%
/mnt/windows
/dev/hda9 20192676  16708844   3073536  85% /usr
/dev/hda1020192676   7731048  12051332  40% /usr/local
/dev/hda1124636408  15032260   8853272  63% /home
/dev/hda13 1057812797020217740  79% /bak
/dev/hda569973 29388 36972  45% /boot
/dev/hda6  1478668608664809924  43% /var
/dev/hda7   280005  8255257294   4% /tmp
After a clamscan /tmp seems to fill a lot ; however it can
give an answer ,
command is clamscan -r --infected /home/roger/.mozilla
>/home/roger/Infection/Analyse_160406


is there a minimal size of /tmp to start clamav , in 0.88
source release there is not problem with the same command (
and same verification file )
Can anyone help me ?
Best regards

Roger Martinez






Accédez au courrier électronique de La Poste : www.laposte.net ; 
3615 LAPOSTENET (0,34 €/mn) ; tél : 08 92 68 13 50 (0,34€/mn)



___
http://lurker.clamav.net/list/clamav-users.html


Re: [Clamav-users] clamscan error and requirements

2006-04-16 Thread Leonardo Rodrigues Magalhães



roger martinez escreveu:

LibClamAV Error: fileblobAddData: Can't write 76 bytes to
temporary file textpart: No space left on device
LibClamAV Error: fileblobAddData: Can't write 76 bytes to
temporary file textpart: No space left on device
LibClamAV Error: fileblobAddData: Can't write 76 bytes to
temporary file textpart: No space left on device
LibClamAV Error: fileblobAddData: Can't write 76 bytes to
temporary file textpart: No space left on device
LibClamAV Error: fileblobAddData: Can't write 76 bytes to
temporary file textpart: No space left on device
LibClamAV Error: fileblobAddData: Can't write 76 bytes to
temporary file textpart: No space left on device
LibClamAV Error: fileblobAddData: Can't write 76 bytes to
temporary file textpart: No space left on device
LibClamAV Error: fileblobAddData: Can't write 76 bytes to
temporary file textpart: No space left on device
  


   No Space left on device usually means 'out of space' !! There's no 
magic or hidden message on that, there's no space for doing something 
the process was supposed to do.



After a clamscan /tmp seems to fill a lot ; however it can
give an answer ,
command is clamscan -r --infected /home/roger/.mozilla
  

/home/roger/Infection/Analyse_160406



hard drive partitionning is :

Sys. de fich.1K-blocs   Occupé Disponible Capacité
Monté sur
/dev/hda8   964500287920627584  32% /
tmpfs   517496 0517496   0% /dev/shm
/dev/hda1  7164956   2476116   4688840  35%
/mnt/windows
/dev/hda9 20192676  16708844   3073536  85% /usr
/dev/hda1020192676   7731048  12051332  40% /usr/local
/dev/hda1124636408  15032260   8853272  63% /home
/dev/hda13 1057812797020217740  79% /bak
/dev/hda569973 29388 36972  45% /boot
/dev/hda6  1478668608664809924  43% /var
/dev/hda7   280005  8255257294   4% /tmp
is there a minimal size of /tmp to start clamav , in 0.88
source release there is not problem with the same command (
and same verification file )

  


   Your /tmp is small, that's a fact. I dont know if clamav needs a 
'minimal space of /tmp to start', but i think the answer is NO. The 
minimal space needed depends on the files clamav will have to scan. I 
would worry about compressed files, maybe clamav decompress and writes 
on /tmp to scan the decompressed ones.


   Please try changing TemporaryDirectory to something different from 
/tmp in clamd.conf. Gives TemporaryDirectory a path will more space 
available and try it. I think you should have a /var/tmp in your linux. 
Try it !



--


Atenciosamente / Sincerily,
Leonardo Rodrigues
Solutti Tecnologia
http://www.solutti.com.br

Minha armadilha de SPAM, NÃO mandem email
[EMAIL PROTECTED]
My SPAMTRAP, do not email it




___
http://lurker.clamav.net/list/clamav-users.html


[Clamav-users] Stale clamav CVS repository at sourceforge.net?

2006-04-16 Thread Panagiotis Christias
Hello,

the CVS repository at sourceforge.net seems to be stale since the end
of March. At least the web interface at:

http://cvs.sourceforge.net/viewcvs.py/clamav/clamav-devel/

Any ideas?

Regards,
Panagiotis
___
http://lurker.clamav.net/list/clamav-users.html