The last little while I've been making Michael earn his keep. Primarily by ripping CDs to the network drive for music fun goodness. I've got all my CDs done and a mess of the Wendawg's as well. Definitely got Grip setup properly now. I have the ripping and encoding re-niced such that, well they're both below 0 so my normal use of the computer isn't affected, but also such that ripping only stays slightly ahead of the encoding thus minimizing disk usage by the ripped .wav files.
And speaking of disk space, I finally got Snort (and Snarf) installed properly on Michael in Mandrake (9.2 for what its worth). Great. So I started cranking open the snort alert logs I've got for school (which I'll get back to in a minute). The thing I failed to notice was that snort is enabled on boot by default after installation on Mandrake. Now I do almost *everything* over the lan with NFS and SMB both of which are (correctly) logged by snort as they are both dangerous to system and network security. After a *very* short amount of time, my computer started having hissy fits. 'What is this?' I say. 'X won't start? Oh my. Why is that?'
Well, good old df -h / to the rescue. Sure enough, my root partition was full. 'That fucking sucks', says I, 'what ate my disc?' Now I didn't clue in that it might be snort since I have a tendency of filling the drive if left to my own devices (ha ha) so a little bit of the old du -sh /* to figure out where the space went led me right to the snort logs.
Okay snort, you can suckit. I shut off snort, disabled it from running on boot and gave its alert logs a we spot of the rm -Rf. Sure enough, the 1.6GB of free space I had thought I had showed back up. Bloody marvelous. Now everything works like a charm.
Now that problem cropped only after some uptime. The *other* fun problem I had was in processing the snort alert log with snarf. The first file I tried to run it on was 352,584 lines long (1 line per alert). So I started up snarf and looked at my memory usage off and on as it went to 200 megs, 300, 500, 700 and seemed to hold steady at 700 for a while... And I do mean a while. After an hour or so I said fuckit and went to bed.
The next morning, my shell politely informs me that snarf was terminated by -9 signal (a.k.a. -KILL). Well that sucks, says I. So I nice it up and leave snarf running. An hour and a half later, X stops responds. Fucking marvelous. I then notice that gkrellm is showing that the CPU is basically *only* handling IO requests. Hmm I wonder what could have happened. Maybe snarf ate through my gig of ram and token 128M of swap and then started thrashing? I think so. The kernel happily killed that process however poor X didn't survive the incident. All Michael's peripherals were seized so I couldn't even get to a virtual terminal. So I shelled in and was able to gracefully reboot the system thus restoring us to the happy land where keyboards and mice aren't just objets d'art.
In summary: thrashing sounds cool but it's more cool in the 'lets watch that on tv' and not in the 'I want to do this at home' kind of way.
For anyone who's had to cleanup some mail problems with Postfix configuration (or more often with other things, like anti-spam, tied in ...
In the course of troubleshooting the office Jabber server the other day, I came across some interesting info about the various caches that O...
For everyone who uses cron, you are familiar with the job schedule form: min hr day-of-month month day-of-week <command> A problem...