I've been playing with Imaging utilities for Mac. Specifically for OSX 10.5.x.
We have a OSX Server at the Office where I work. Its just a Mac Mini loaded with OSX Server, which at the time is all unplugged sitting in a pile on the floor. Just before it got moved out of the "lab" and into the "conference room" which is now our Lab because we're hiring another person to help us out.
Anyways - long story short.
I used Carbon Copy to image the complete Server via Firewire Targeted Mode (I put the Mini in Targeted Mode) and used a Firewire Cable to my MacBook, which I use a USB to SATA Adapter to which I copied the image to a 2.5" 250gig Laptop SATA Drive. Could have as well been my iPod... I just had the 250gig laying around, why not use it? My iPod is only 4gigs anyways.
I brought the image home, hooked the USB to SATA adapter up to the MacBook, booted holding Option (gives you boot menu) and it will automatically find the USB Adapter and allow you to boot from the external drive just as if it was your internal hard drive.
If you image another persons machine, you will need to know their passwords in order to perform anything. You can reset them if you don't know how but all in all - this is a very easy way to replicate your drive as a backup drive and boot from it - from any mac.
The simple thing would be have an external usb hard drive, image your drive to it (using another computer to pull it from your drive and to the external) then you can take your data/programs/preferences/everything with you anywhere you go...
Saturday, July 19, 2008
Sunday, July 13, 2008
syslogd using all resources in osx
Has your computer hung up with 'syslogd' using 99% of your resources?
You kill it only to have it come alive again and use every bit of your resources?
I had this problem, couldn't find a direct fix, so I am posting my solution.
Part of this came from a fellow on Apples discussion pages, credit given at botton.
I am going to make this short and sweet. Cut and paste if you wish.
--begin fix--
It turns out a very large /var/log/asl.db (a primary log for syslogd) causes all manner of issues, notably, occasional syslogd cpu hoggage. In my case, I was getting repeated malloc errors from syslogd as well, compounding the issue. My asl.db was was 55Mb. After reading this blog post:
http://smartic.us/2007/11/8/leopard-100-cpu-usage-caused-by-syslogd-and-possibly-time-machine
I went on a hunt, and found, according to:
http://developer.apple.com/documentation/Darwin/Reference/ManPages/man8/syslogd.8.html
The asl.db size is supposed to be limited to a default of 25600000 bytes. Mine was way bigger. Something was clearly amiss.
There is no database size limit -- theoretically anyway; practically, there clearly is, as evidenced by this and many similar threads around the net.
The fix is to edit /System/Library/LaunchDaemons/com.apple.syslogd.plist
and add the db_max arg:
/usr/sbin/syslogd
-db_max 5000000
Adjust the max to your taste. I limited mine to 5M bytes. After that, the nightly sweep should keep this problem from occurring again.
I also deleted my asl.db file, which is located in /private/var/log - See *Note below.
To stop and restart 'syslogd' server, type/paste in terminal:
sudo launchctl unload /System/Library/LaunchDaemons/com.apple.syslogd.plist
*See Note Below
sudo launchctl load /System/Library/LaunchDaemons/com.apple.syslogd.plist
*Note: As a precaution, I backed up my asl.db file and deleted the original before starting the service. If you want to perform this, type the following in terminal:
sudo cp /private/var/log/asl.db /private/var/log/asl.bak
Now continue with the 'load' command to restart the 'syslogd' service.
--end fix--
Most credit given to:
adhir
Posts: 1
From: Washington, DC Metro
Registered: Nov 27, 2007
http://discussions.apple.com/thread.jspa?threadID=1228710
You kill it only to have it come alive again and use every bit of your resources?
I had this problem, couldn't find a direct fix, so I am posting my solution.
Part of this came from a fellow on Apples discussion pages, credit given at botton.
I am going to make this short and sweet. Cut and paste if you wish.
--begin fix--
It turns out a very large /var/log/asl.db (a primary log for syslogd) causes all manner of issues, notably, occasional syslogd cpu hoggage. In my case, I was getting repeated malloc errors from syslogd as well, compounding the issue. My asl.db was was 55Mb. After reading this blog post:
http://smartic.us/2007/11/8/leopard-100-cpu-usage-caused-by-syslogd-and-possibly-time-machine
I went on a hunt, and found, according to:
http://developer.apple.com/documentation/Darwin/Reference/ManPages/man8/syslogd.8.html
The asl.db size is supposed to be limited to a default of 25600000 bytes. Mine was way bigger. Something was clearly amiss.
There is no database size limit -- theoretically anyway; practically, there clearly is, as evidenced by this and many similar threads around the net.
The fix is to edit /System/Library/LaunchDaemons/com.apple.syslogd.plist
and add the db_max arg:
Adjust the max to your taste. I limited mine to 5M bytes. After that, the nightly sweep should keep this problem from occurring again.
I also deleted my asl.db file, which is located in /private/var/log - See *Note below.
To stop and restart 'syslogd' server, type/paste in terminal:
sudo launchctl unload /System/Library/LaunchDaemons/com.apple.syslogd.plist
*See Note Below
sudo launchctl load /System/Library/LaunchDaemons/com.apple.syslogd.plist
*Note: As a precaution, I backed up my asl.db file and deleted the original before starting the service. If you want to perform this, type the following in terminal:
sudo cp /private/var/log/asl.db /private/var/log/asl.bak
Now continue with the 'load' command to restart the 'syslogd' service.
--end fix--
Most credit given to:
adhir
Posts: 1
From: Washington, DC Metro
Registered: Nov 27, 2007
http://discussions.apple.com/thread.jspa?threadID=1228710
Subscribe to:
Comments (Atom)
