Monthly Archives: October 2014

MacBook Fix Fast Battery Drain

To debug and fix a MacBook fast draining battery try the following solutions / fixes.

First find out how fast your MacBook is draining its battery by using System Information (Apple logo top left corner, About This Mac, More Info, System Report, Power).

Look at the Amperage (mA) value.  Unplug your MacBook if you’re running on AC power / plugged into the wall outlet.  This negative number shows how fast your MacBook is draining its battery.  The Amperage value can be used to estimate hours of battery life remaining on your current MacBook charge.  Divide the Charge Remaining number by Amperage and that will give you the number of hours of remaining battery time for your laptop.  The larger the Amperage value, the less battery life you’ll have.  For a 2012 Macbook Pro 15″ the Charge Remaining with a full battery is around 8000 mA (milliAmps) and my lowest Amperage doing nothing is about 690 mA.  The Amperage value can jump to 1400 (while using WordPress on Chrome) or even 1900 at times after loading an application.  (Use Command + R to refresh the System Information window to see the new Amperage value which gets updated every 15 seconds or so).

On average your Amperage shouldn’t be above 1000 mA if you’re to meet the claimed battery life expectations Apple has published on their website about MacBooks.  So if you’re seeing Amperage values while on battery power not too far above and below 1000 mA, then you’re likely seeing around 8 hours battery life, which is pretty good and meets expectations.  If your Amperage value is constantly above 1000 and never gets below that value, you can try some changes and hopefully fixes.

Remember: Your goal is to minimize the Amperage value.  Fixes / Solutions to try

  1. Reset PRAM – Shut down / Turn Off MacBook. Start/Turn On MacBook.  Immediately press and hold Option + Command + P + R.  The normal start-up chime will sound. Then immediately after the screen will go black and the startup chime will sound again (perhaps louder and the screen at full brightness).  Let go of Option + Command + P + R keyboard combination.  PRAM has been reset.  Adjust your volume and brightness to your previous desired settings.
  2. Delete a plist file and restart the Dock process.  In Terminal (Applications -> Utilities -> Terminal), delete the file: rm ~/Library/Preferences/ then kill the Dock process. killall Dock.
  3. Turn off TimeMachine (Click on arrow around clock icon in the Dock, top right corner, Open Time Machine Preferences.  Move slider to the left to Off)
  4. Quit Google Drive sync application (looks like a black yield sign, click it, Quit Google Drive.  Restart Google Drive to update the version if you’re using OS X Mavericks. This may be enough as there was a confirmed bug in OS X Mavericks and Google Drive.  If not, leave it off until you need to sync files or you are back on AC power)
  5. Use Safari browser as opposed to Chrome or Firefox.  I found that Safari is less power hungry than Chrome.  But that may be due to the extensions I have running in Chrome.  Using Private Browsing on Chrome may also help (Command + Shift + N).

After doing each of these changes, spend some time watching your System Information application, paying attention to the Amperage number.  Keep refreshing every 15-30 seconds to check the change to how much battery you are currently draining.

Hopefully one of these changes will solve your fast draining battery on your MacBook!

Securely Delete Linux Server

Shutting down and deleting a Linux server securely – overwrite disk data using:

dd if=/dev/zero of=/dev/sdXXX bs=1048576

where sdXXX is found by using


which returns something like

Filesystem 1K-blocks Used Available Use% Mounted on
/dev/xvda 98438788 29142068 64296324 32% /
varrun 524288 44 524244 1% /var/run
varlock 524288 4 524284 1% /var/lock
udev 524288 52 524236 1% /dev
devshm 524288 0 524288 0% /dev/shm

In this case for me my main disk partition containing my data would be /dev/xvda that I want to delete so the command to securely delete a disk (overwriting with zeroes)

dd if=/dev/zero of=/dev/xvda bs=1048576

For more information on this process, check out this great article on using dd to securely erase disks on Linux.

Linux do-release-upgrade Checklist Recover from Broken Pipe

Before a do-release-upgrade in Ubuntu Linux, here’s a quick checklist of todo’s:

  • Backup important files (apache sites / log files / conf files, PHP .ini files, databases, cron scripts, .bash_aliases, .profile, upstart scripts)
  • Clear up enough space for upgrading (usually around 1GB)
  • Open up a secondary SSH window and alternate port for firewall if you get disconnected a lot
  • Change access to /var/run/screen to 777 (chmod 777 /var/run/screen)
  • about 2-3 hours of time to upgrade (started 5:14pm, broken pipe around 7:35pm, restart 8:10pm)


The Linux server will continue to run while upgrade is downloading necessary packages.

First question will be: Disable SSH password authentication for root?  If you’re using public/private key logins for SSH, go ahead and disable interactive typed password authentication for SSH.  This is safer.

Second question: Restart services during package upgrade without asking?  Sure.  Unless you like to watch terminal windows for unknown lengths of time and clicking Yes over and over again.

Next the Linux server will download, unpack, and update packages, restart services as necessary, one-by-one until all Linux packages are at the latest version available.

You may be asked to replace some configuration files such as /etc/default/rcS.  Since I have no recollection of changing that in paritcular, I’ll go with replacing it with the package maintainer (new) version.  (The only change was to assume BIOS clock is set to time based on UTC).  In other cases, such as jail.conf for fail2ban, I’d keep my own configuration file, since it’s full of my customizations to jails that I’d much prefer to keep.

For /boot/grub/menu.lst, I chose to “Install the Package Maintainer’s version” to replace my version with the new version.  Nothing exploded.  Or melted.

Recover from Broken Pipe during do-release-upgrade

During the ultra-long upgrade process you may get a Broken Pipe due to spotty Internet connection or accidentally closing your Terminal connection.  At the beginning of the process do-release-upgrade noted an alternate SSH port where you can reconnect (usually port 1022).  To reconnect to the active screen (here’s where the chmod 777 /var/run/screen comes in handy) first change the /var/run/screen permissions to 775 (chmod 775 /var/run/screen), then reconnect by executing the command screen -d -r.  This will reconnect you to the running upgrade.