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
