Alexandria Bridgman: 05/02/1932 – 23/02/2009

You were the head of the family, mother to 8, grandmother to 18, great grandmother to many more.

You where stolen from us before your time. The disease that attacked you was merciless. Medical science could not help you. Yet you fought with all your strength and passion and managed to hold on long enough for us all to say goodbye, thus was your desire to live.

No words can express how much we all miss you. I personally will miss the many conversation we use to share. You shared with me many thoughts, feelings and opinions, from your thoughts on politics, to what vitamins I should be taking. There are so many more conversations I’d like to have had….

I know without question that you are in heaven, looking down on us from above, wondering why we are all making a fuss. I want you to know that you will be remembered until my own end of days, you will not be forgotten. I’ll tell my future children about the lessons my Nanna taught me.

The world is less bright without you in it.

Travis Read
Your loving grandson
Requiscat in Pace

T

T

T

Yesterday we had a brief outage to services on the Greenwood Server. I’ve been having power stability issues for some time so finally got a sparky onsite who replaced some wiring.

I was also made aware of the fact that rebooting the server cleared a lot of memory. As such I have blown away vmware which was the main memory hog. vmware still runs on the colocated server which has much more memory avaliable.

T

The Problem:
On the first sunday of every month a script runs:
#6 1 * * 0 root [ -x /usr/share/mdadm/checkarray ] && [ $(date +\%d) -le 7 ] && /usr/share/mdadm/checkarray –cron –all –quiet
This does a rebuild on each raid array. However, on the first Sunday of every month my server dies. It appears to lock up without any error on the console. A reboot will result in the server booting, trying to continue rebuilding the raid array followed by another lockup. I have to go into linux single mode. Disable the 2nd disk of the raid arrays, reboot, then manually add a disk to the first raid array, wait for it to finishing rebuilding and then add in the 2nd member of the other arary. In the short to medium term I’ve disabled the cron entry.

The question, what is causing this!

Thus far I thought it was a bad disk, so I replaced one of the drives wth a brand new drive, however the problem still occures. I tested the old disk and it also works correctly. I suspect there is a bug in the kernel somewhere, something to do with libsata or similar.
http://ubuntuforums.org/showthread.php?t=748418
is a report of the same problem.

I thought perhaps it’s a load issues, I mean, a rebuild hammers the raid? So I tried:
date; dd if=/dev/zero of=/blah count=1024 bs=100M; date
which writes 100gig of data from /dev/zero as fast as the raid can go. During this test nothing unexpected happened. Therefor I have proved the issues doesn’t appear to be hardware related.

I think I need to upgrade my kernel but my current kernel is a custom compiled job so upgrading is hard.

I’m currently working on the following projects:
* Make layer7-filter work (filter bit torrent etc)
* Compare ext3, ext2, XFS and Reiserfs
* putting an upgrade plan together to migrade from sarge to stable debian
* Migrate client email onto colo
* Migrate client webpages onto colo
* Make tomizone work on linksys AP in roof
* create a server image to allow rapid recovery in the event of system failure
* Find a way to stop phpgallery comment spam
* test and chuck out all the crap hardware I have laying around
* figure out why /usr/share/mdadm/checkarray causes array to degrade. checkarray reported one of the disks failed, I’ve replaced the disk and tested it but it’s fine? Hammering the raid array causes no issue aswell.
date; dd if=/dev/zero of=/blah count=1024 bs=100M; date

Recently completed:

* Deployment of a USB disk based Backup solution
* Start to document what various things do
* Update firewall to block annoying wifi leechers
* Update squid to use less resources
* Resolve issues with openvpn and quagga