So long Gracie...you will be missed

Our beloved girl, Gracie, has gone home this past Tuesday. Her heart grew too big and finally gave way while she went outside to lay in the sun one last time.

I wish I could pet her one last time. I wish I could take her on one last walk. Had I known that Tuesday was her last day, I would have done both of these things. I'm going to miss her.

Some of you may remember Ben, our first greyhound who succumbed to bone cancer new years day in 2006. I posted about "Ben's Rose" on my blog at that time which sprung up in our rose garden the day after he died. The rose came from the unlikeliest of a shrub, a misfit, a runt...but, it bloomed the most beautiful rose, it was unmistakable that the rose was Ben letting us know that he was free of pain.

Gracie, not to be out done, sent us a sign of her courageous spirit and her eye-catching beauty...it's almost unbelievable. After she passed, on the way to the vet to prepare for her final arrangements, as I drove down the highway, I saw a huge bird. Vultures are not uncommon in Tennessee and at first, it appeared that I had seen one flying by the highway. But, for some reason I couldn't take my eyes off it. As I looked for a half second longer, I realized that I was not looking at a vulture, rather I was looking at a Bald Eagle!

The white head and tail feathers were unmistakeable. She sent an eagle to me to remind me of her beauty, strength, courage, and triumphant spirit that stole our heart and that which made us love her so much.

Gracie, we will miss you. Say hello to Ben for us.

She was born on 01/11/1998 and went to her forever ever home
on 06/30/2009.

And because the life of a greyhound should never end on a sad note, here is a movie that best personifies her. Don't let her tickle your funny bone...she's guilty I tell you.

Our Family

1120081526-00
Originally uploaded by K3bert

I was just surfing the Internet, and was looking back at our photo's. My wife caught this greyt action photo of Ester playing with Russ. You can see Gracie in the background, she's too mature for such tomfoolery.

Close call lightning strike

Close call lightning strike
Originally uploaded by K3bert

Today at work, a quick moving thunderstorm rolled through. A lightning strike occurrd just outside my office window. The tree didn't fair to well and luckily for me, I wasn't sitting at my desk. Notice all the bark was blown off the tree.

syslog consuming 100% cpu - SOLVED!

Finally figured out. Can't explain how it happened, but I know what happened.

A couple of months ago, I dropped my MacBook and the hard drive froze. I was able to replace it with no issue. I went to install Leopard, but the DVD couldn't be read. So, I reinstalled Tiger and opened a support case...bottom line, when I dropped the laptop, the DVD can't read double density DVDs anymore.

Why is this significant? It's not, but part of the story.

When I took my laptop in because I couldn't get Leopard installed, the store installed via an external drive. The result from this upgrade was that the /etc/periodic/daily/500.daily was renamed /etc/periodic/daily/500.daily.applesaved and the original file was replaced with a new version.

When the periodic daily job was run, both files ran. The problem is that the 500.daily.applesaved file is for some reason not compatible. The line in the backed up file that was causing the problem was:

syslog -p -k Time lt -7d -o -k Time lt -3d -k Level ge 4 -o -k Time lt -1d -k Level ge 6

Don't know why it caused the problem, but it did. The full content of the file that was backed up follows. Once I removed the .applesaved file, it worked like a champ.

#!/bin/sh -
#
# @(#)daily 8.2 (Berkeley) 1/25/94
#
PATH=/bin:/usr/bin:/sbin:/usr/sbin:/usr/local/bin
host=`hostname -s`
bak=/var/backups

echo "step 1"
echo "Removing scratch and junk files:"

if [ -d /var/rwho ] ; then
cd /var/rwho && {
find . ! -name . -mtime +7 -exec rm -f -- {} \; ; }
fi

# Clean up junk files.
#find / \( ! -fstype local -o -fstype rdonly \) -a -prune -o \
# \( -name '[#,]*' -o -name '.#*' -o -name a.out -o -name '*.core' \
# -o -name '*.CKP' -o -name '.emacs_[0-9]*' \) \
# -a -atime +3 -exec rm -f -- {} \;

# Clean up NFS turds. May be useful on NFS servers.
#if [ "${host}" != "localhost" ]; then
# find / -name .nfs\* -mtime +7 -exec rm -f -- {} \; -o -fstype nfs -prune
#fi

if [ -d /tmp ]; then
cd /tmp && {
find . -fstype local -type f -atime +3 -ctime +3 -exec rm -f -- {} \;
find -d . -fstype local ! -name . -type d -mtime +1 -exec rmdir -- {} \; \
>/dev/null 2>&1; }
fi

if [ -d /var/spool/fax ]; then
echo "step 2"
echo "Removing scratch fax files"
cd /var/spool/fax && \
find . -type f -name '[0-9]*.[0-9][0-9][0-9]' -mtime +7 -delete >/dev/null 2>&1;
fi


# remove system messages older than 21 days
msgs -c

if [ -f /var/account/acct ] ; then
if [ -x /usr/bin/gzip ]; then gzext=".gz"; else gzext=""; fi
echo "step 3"
echo "Gathering accounting statistics:"
cd /var/account
if [ -f "acct.2${gzext}" ] ; then mv -f "acct.2${gzext}" "acct.3${gzext}" ; fi
if [ -f "acct.1${gzext}" ] ; then mv -f "acct.1${gzext}" "acct.2${gzext}" ; fi
if [ -f "acct.0${gzext}" ] ; then mv -f "acct.0${gzext}" "acct.1${gzext}" ; fi
cp -pf acct acct.0
if [ -x /usr/bin/gzip ]; then gzip -9 acct.0; fi
sa -s > /dev/null
fi

#if [ -d /var/db/netinfo ]; then
# echo ""
# echo "Backing up NetInfo data"
# cd /var/db/netinfo
# for domain in *.nidb; do
# domain=$(basename $domain .nidb)
# server=`nicl -t localhost/$domain -statistics | grep tag | awk '{print $3}'`
# if [ $server = master ] ; then nidump -r / -t localhost/$domain > $bak/$domain.nidump; fi
# done
#fi

echo "step 4"
echo "Checking subsystem status:"

echo ""
echo "disks:"
df -k -l
echo ""
dump W

if [ -d /var/spool/mqueue ]; then
echo "step 5"
echo "mail:"
mailq
fi

echo "step 6"
echo "network:"
netstat -i

echo "step 7"
if [ -d /var/rwho ] ; then
ruptime
fi

echo "step 8"
printf %s "Rotating log files:"
cd /var/log
for i in system.log; do
if [ -f "${i}" ]; then
printf %s " ${i}"
if [ -x /usr/bin/gzip ]; then gzext=".gz"; else gzext=""; fi
if [ -f "${i}.6${gzext}" ]; then mv -f "${i}.6${gzext}" "${i}.7${gzext}"; fi
if [ -f "${i}.5${gzext}" ]; then mv -f "${i}.5${gzext}" "${i}.6${gzext}"; fi
if [ -f "${i}.4${gzext}" ]; then mv -f "${i}.4${gzext}" "${i}.5${gzext}"; fi
if [ -f "${i}.3${gzext}" ]; then mv -f "${i}.3${gzext}" "${i}.4${gzext}"; fi
if [ -f "${i}.2${gzext}" ]; then mv -f "${i}.2${gzext}" "${i}.3${gzext}"; fi
if [ -f "${i}.1${gzext}" ]; then mv -f "${i}.1${gzext}" "${i}.2${gzext}"; fi
if [ -f "${i}.0${gzext}" ]; then mv -f "${i}.0${gzext}" "${i}.1${gzext}"; fi
if [ -f "${i}" ]; then
touch "${i}.$$" && chmod 640 "${i}.$$" && chown root:admin "${i}.$$"
mv -f "${i}" "${i}.0" && mv "${i}.$$" "${i}" && if [ -x /usr/bin/gzip ]; then
gzip -9 "${i}.0"; fi
fi
fi
done
if [ -f /var/run/syslog.pid ]; then kill -HUP $(cat /var/run/syslog.pid | head -1); fi
echo "done rotating"

# Prune the main syslog output file (/var/log/asl.log)
# Delete all messages after 7 days (-k Time lt -7d)
# Delete Warning (Level 4) and above after 3 days (-k Time lt -3d -k Level ge 4)
# Delete Info (Level 6) and above after 1 day (-k Time lt -1d -k Level ge 6)
echo "step 9"

syslog -p -k Time lt -7d -o -k Time lt -3d -k Level ge 4 -o -k Time lt -1d -k Level ge 6

echo "step 10"
if [ -f /etc/daily.local ]; then
echo "step 11"
echo "Running daily.local:"
sh /etc/daily.local
fi

if [ -f /etc/security ]; then
echo "step 12"
echo "Running security:"
sh /etc/security 2>&1 | sendmail root
fi

Another f$%ing sleepless night...I'm at my wits end

I do not know what to do and it's start to ware me out. If it weren't for the ADD medicine on, I don't think I would get anything accomplished. But, that's enough about me.

The good news is we found our next home. We have been complete discontent with our current home. It's the same size in square footage as the home in Houston, but it's 2 story. Our older greyhound, Gracie, the one pictured on the right doesn't do stairs. The home is also situated with a bonus room above the garage which never gets used. Therefore, our primary family room is downstairs which has the kitchen (smaller than most galley kitchens) the family room, dinning room and 1/2 bath. Therefore, we re confined to a single room apartment living with 3 dogs.

You can only imaging how much work it takes to keep this place clean. There are days we don't do a good job.

The good news is, that the dogs have about a 1 acre fenced in lot to run around. The floor plan is single story and open. And most importantly, it's in the country.

I'm going to have to buy a riding lawnmower and some overalls! We'll get a does of the "real life". Don't have the pictures yet, but you can see the satellite images from google with the home was first being built. Also, it has a septic tank...I heard they work good if you don't try to do 15 loads of laundry, run 2 showers at the same time, and do 15 loads of dishes.

Here's to a bubble free yard with our new home.

Cancellation fees for doc appointments

So, typically if you don't cancel a doc appoinment within 24 ours of the appointment, you are charged a fee.

Let's say you have an appoinent scheduled to last 45 minutes. Don't you think it's reasonable that if after waiting for 45 minutes in the doc office and you still have not visited the doc, shouldn't thy be cosisered a cancellation and you should be paid a fee?

ok...just kidding...no idea what's up with the syslog process

Just an update, I have no idea what's causing the syslog process to hog all the cpu. It appears to be related to the periodic daily task, but not sure which one..

syslog consuming 100% cpu part deux

So, from the previous post, I thought I may have been on to something with 100GB daily.out file. As it turns out, I wasn't. But, I kept digging today. And I found something interesting in system.log file

Mar 26 03:30:41 Legolas [0x0-0x219219].com.apple.dock[4729]: 2009-03-26 03:30:41.448 DashboardClient[5247:10b] (com.iSlayer.iStatpro4.widget) file:///Users/kevin/Library/Widgets/iStat%20pro.wdgt/scripts/core.js: TypeError: Result of expression 'this.isSectionEnabled' [undefined] is not a function. (line: 528)

Could it be this simple, the iStat widget was throwing an exception which caused the churn in the syslog process? It looked like this exception was being thrown every 3 minutes, non stop. Every three minutes doesn't seem like enough activity to cause the problem...but, I uninstalled it and going on 12+ hours without cpu saturation

It started with syslog consuming all my cpu

A rather strange phenomenon has been occurring on my Mac over the last several weeks. Don't know what started nor do I know if it's over, but I want to tell you the tale of the 110GB daily.out file and the syslog process that kept (maybe keeps) consuming all my CPU.

At least once a day, the syslog process starts consuming 100% of the CPU on my Mac Book and does not stop without force quitting. Searching through Google, I learned that many others have the same problem, but no consistent explanation. So, I resigned to force quitting the process whenever it would misbehave...until tonight.

I start up Openoffice.org to create a spreadsheet to for a household budget when I receive a nice message saying that my root disk is almost full. Opening the disk utility showed that I only had 600MB of free space left. I did the natural thing, I emptied my trash bin. That only gave me back 10MB, so I'm at 610MB.

I did some googling on how to run the disk utility or look at other 3rd party utilities that could help determine any unwanted, and large files were lurking on my drive. I went back into the disk utility again when all of a sudden it was reporting 0 bytes of space left!

Yikes!

I went and looked in the /var/log directory, as this is where many (if not all) log files are written. I did your friendly "ls -help" command and to my astonishment, the daily.out file was 110GB in size!

Stunned silence.

After the shock wore off, the awe kicked in and I went to see what in the heck was going on. As it turned out, on 2 days, Jan 24 and Feb 6, I started receiving an inordinate number of "kernel[0] " messages in the log. No other description provided. Google didn't help much either other than providing that the only similar errors actually related to disk i/o errors and the kernel.

Now I tried googling "how do i control the size of the daily.out log file mac os x" which lead me to maxosxhints.com. Here, I found a script that will rotate out the daily (and weekly and monthly) log files once they become larger than 50kb. Chalking up the kernel errors to some anomaly that has since gone away (at least I hope so), I went ahead and set up the script listed in the comments section of the post on the page and then executed, thus purging the 110GB daily.out file.

I now have 120GB freespace according to disk utility. The math doesn't seem quite right, but at least I took care of the drive space issue.

Now, if the cpu hogging syslog process has/had anything to do with the large file (or vice versa), I don't know. Only time will tell and I don't have an answer for any of you out there that google "syslog consuming 100% cpu" and end up on this page, but this was a journey that I had to share.

Gumby would be proud

Gumby would be proud
Originally uploaded by K3bert

I guess I shouldn't make fun of her, after all she has a broken leg. It must be hard to find the right "roaching" position.