You've got your socket named incorrectly in clamd.conf. It is overwriting the executable. You should move your socket to /var/lib/clamav.
On Jul 6, 2010, at 9:22 PM, Hook <[email protected]> wrote: > Sorry for the delayed response. > > I found that after install clamd is a ´normal exec´ file with some Kb ( lets > say 83kb for example ). > > Then, after starting it, becomes a ´socket´ type, zero lenght. > > Rebooted in normal way, et voilà... no more clamd 83kb. > > So its not FS nor UPS > > Because of a backed up clamd file, copied it as clamd.....and starts as > normal! > > Regards > > H. > > --- El jue, 7/1/10, Shawn Bakhtiar <[email protected]> escribió: > >> De: Shawn Bakhtiar <[email protected]> >> Asunto: Re: [Clamav-users] clamd missed >> A: [email protected] >> Fecha: jueves, 1 de julio de 2010, 08:33 pm >> >> To preface the importance of what is being said: >> >> 1) Production servers should ALL have UPS and UPS should be >> tested, and if power outages are longer than the UPS ability >> to maintain, some proper shutdown mechanism must be enabled >> (do not be cheap with production servers). >> >> 2) I have hard booted linux boxes (FreeBSD should be very >> much similar - OS X - ) many many many times (in a lab >> environment, and on rare occasions in production) and have >> never experienced this, unless as stated here, there was a >> greater issue with the installation such as a failing drive, >> incorrect settings on a RAID, or something more sinister, >> which in turn would cause ALL kinds of failures. Services >> would not start up (missing configs and libs), etc... >> >> 3) I've compiled ClamAV since it is not available through >> yum on my distro (at least the latest version) and have had >> no issues of the kind you describe specifically related to >> clam. >> >> 4) Do you have anything like tripwire installed (yes you >> can tell exactly what files have been altered) ? You would >> have needed to install it before the system became >> unstable. >> >> 5) Do not focus on clam, focus on the fact that a file is >> getting corrupted when it should not. Do you have other >> mechanisms installed that check, or maintain files for you? >> Some other security. Is SELinux enabled (this is a far >> shot)? ONLY IF YOU ARE ABSOLUTLY SURE THIS IS THE ONLY >> FILE! >> >> All of the advice on this thread has been dead on. Critical >> systems should not be able to fail in this manor, and a good >> understanding of file structure and systems is important in >> being able to trace it down. >> >> >>> Date: Thu, 1 Jul 2010 17:13:27 +0100 >>> From: [email protected] >>> To: [email protected] >>> Subject: Re: [Clamav-users] clamd missed >>> >>> Hi there, >>> >>> On Thu, 1 Jul 2010 Jerry wrote: >>> >>>> Yeah, It's an UPS failure. >>> >>> Perhaps you should get a better UPS. If it's >> important to you that >>> the server runs reliably I'd recommend one which has >> the converter >>> running continuously, not a cheap 'line interactive' >> one. Make sure >>> that the battery health is monitored by the UPS and >> that batteries can >>> be replaced while it is on line. >>> >>>>> Did you run a filesystem checking tool after >> the abnormal >>>>> shutdown? >>>> >>>> Yes, fsck -f >>> >>> Are you sure about that? The man page for fsck >> on FreeBSD that I just >>> checked seems to indicate that the -p flag is required >> with -f. >>> >>> How exactly did you run fsck? Do you know that >> it is dangerous to run >>> it on a mounted, writable partition? If I had >> only one partiton on a >>> machine I would normally want to boot on a LiveCD or >> move the disc to >>> another machine to check it, so that I have a full >> running system with >>> all the tools I need to examine and repair >> partitions. >>> >>>>> Did you only reinstall ClamAV?? If so I do >> not believe that you >>>>> know that all is OK.? Under these >> circumstances, I would not know. >>>> >>>> As far as I know, mails get trought, Av is >> working, no file system errors.... >>> >>> How many files are there in the system? >> 10,000? 100,000? A million? >>> How have you ensured that clamd in /usr/local/sbin/ >> was the only one >>> which suffered any damage? What mechanism can >> you suggest which might >>> explain that this one single file was damaged, and all >> the others were >>> protected by some magical shield? Do you >> understand that damage to a >>> directory is not the same as damage to the file? >> How can you explain >>> that some tiny part of a directory which is normally >> only being read >>> has twice accidentally been written in the same highly >> improbable way? >>> Looking at the information before me I have to say >> that if this is not >>> beyond the bounds of credibility, it's certainly out >> there at the edge. >>> >>>>> It is a _very_ bad idea to shut down a >> modern operating system the >>>>> hard way >>>> >>>> This is crystal clear. I'll let Power company >> know that :)) >>> >>> I thought you said it was a UPS failure. >>> >>>> By the way, still in dark of WHY clamd can't >> work. >>> >>> You showed us why in your OP. >>> >>> On Wed, 30 June Hook wrote: >>> >>>>> argos [/var/log/clamav]# ll >> /usr/local/sbin/clamd >>>>> srw-rw-rw- 1 root wheel 0 >> Jun 2 08:37 /usr/local/sbin/clamd >>> >>> It is easy to understand why clamd doesn't work if >> it's >>> (a) zero length and >>> (b) not executable >>> >>> Why not try this for yourself as an experiment? >> Create a file of zero >>> length, make sure that it is not executable, and then >> try to run it. >>> My guess is that you won't get very far. :) >>> >>>> Zero lenght and ONLY clamd affected. >>> >>> I'm still far from convinced that you know what damage >> has been done >>> to your system. I'm not convinced that you >> understand how filesystems >>> work, and for example the difference between the >> content of a file and >>> the information which is contained about it in a >> directory. From the >>> information which you have given us, under these >> circumstances I would >>> have no confidence that the only damage done to the >> filesystem was to >>> one single file. The directory containing the >> file seems to have been >>> corrupted -- the file should have been executable, and >> your directory >>> listing shows that it is not. In my experience, >> when a filesystem is >>> corrupted the damage is usually rather extensive, and >> fsck, when run >>> correctly, will show many, many corrections being >> made. >>> >>> The symptoms which you have described (one single, >> specific binary >>> file being truncated to zero bytes when the power to >> the machine is >>> switched off on two separate occasions) make no sense >> to me at all. >>> That makes me think that there's at least one >> important piece of this >>> puzzle which we haven't seen yet. I suspect >> that, unintentionally >>> perhaps, you are not giving us all the information >> that you have. >>> >>> -- >>> >>> 73, >>> Ged. >>> _______________________________________________ >>> Help us build a comprehensive ClamAV guide: visit http://wiki.clamav.net >>> http://www.clamav.net/support/ml >> >> >> >> >> _________________________________________________________________ >> Hotmail has tools for the New Busy. Search, chat and e-mail >> from your inbox. >> http://www.windowslive.com/campaign/thenewbusy?ocid=PID28326::T:WLMTAGL:ON:WL:en-US:WM_HMP:042010_1 >> _______________________________________________ >> Help us build a comprehensive ClamAV guide: visit http://wiki.clamav.net >> http://www.clamav.net/support/ml >> > > > > _______________________________________________ > Help us build a comprehensive ClamAV guide: visit http://wiki.clamav.net > http://www.clamav.net/support/ml _______________________________________________ Help us build a comprehensive ClamAV guide: visit http://wiki.clamav.net http://www.clamav.net/support/ml
