Skype 5.3.0.116 – a memory hog with memory leaks

Just take a look at the following screenshot I just took, showing two Skype 5.3.0.116 instances running on a current Windows 7 box with 4 GB of RAM:

That’s 330 MB of private memory for each instance at this very moment! Note that these numbers are steadily growing (at about 2 KB/s) for both processes – for no apparent reason. A hint, that there’s likely a memory leak somewhere in Skype.

Let’s hope Microsoft will rewrite Skype from scratch (The current code-base probably isn’t worth refactoring). I’m confident they don’t lack the human and financial resources to do it. It can only get better.

Zimbra Collaboration Server: Troubles after updating to ZCS 7.1.1 – here’s the solution.

Generally, Zimbra‘s update scripts for ZCS run smoothly. However, after updating ZCS from 7.0.1 to 7.1.1 on Ubuntu 10.04.2 LTS a couple of days ago, I noticed that most of the server’s services crashed within 1-2 hours after starting the (virtual) server.

To make a long debugging story short, here’s a summary of the problem:

The update script doesn’t properly remove old entries in /etc/rsyslog.conf when creating a new dedicated rsyslog configuration file for zimbra (/etc/rsyslog.d/60-zimbra.conf). This makes rsyslog log its own logging due to double rule entries – making /var/log/zimbra-stats.log grow at 2 MB/s. Like this, zimbra effectively DOSes itself as the server runs out of free disk space in no time (my above-average 12 GB of free space were filled within about 1 hour 40 minutes).

And here’s the solution:

1. Stop rsyslog to stop it from filling up your disk with nonsense: ‘/etc/init.d/rsyslog stop’ or ‘service rsyslog stop’
2. If necessary (i.e. if the updated server has been running for several minutes already), reclaim your free disk space by deleting/emptying big log files in /var/log, e.g. zimbra-stats.log, zimbra.log, mail.info, mail.log, mail.err, mail.warn etc.
3. Edit /etc/rsyslog.conf and remove the entries (likely at the end of the file) that look similar to these:
local0.* @mail.yourserver.com
local1.* @mail.yourserver.com
auth.* @mail.yourserver.com
local0.* -/var/log/zimbra.log
local1.* -/var/log/zimbra-stats.log
auth.* -/var/log/zimbra.log
mail.* @mail.yourserver.com
mail.* -/var/log/zimbra.log

(these are now in /etc/rsyslog.d/60-zimbra.conf)
4. Restart rsyslog: ‘service rsyslog restart’
5. Restart ZCS if it doesn’t run properly anymore: /etc/init.d/zimbra restart (you may even have to reboot the whole box if that doesn’t work)

Less is more: colordiff and more or less

In the Unix/Linux/Mac OS X world, less is more. Literally, in that ‘less‘ fully emulates ‘more‘, and figuratively, as it provides useful additional functionality like backwards scrolling. So, you really want to use ‘less’ instead of ‘more’ for paging another command’s output, e.g.

cat a_long_document.txt|less

When used to page the output of colordiff however, ‘less’ displays a mess instead of properly displaying colored output like ‘more’.
The trick is to use ‘less’ with either the -r or -R option (which both repaint the screen), i.e.

colordiff -u file_old.py file_new.py|less -r

or

colordiff -u file_old.py file_new.py|less -R

(try which one works better with your system and terminal)

Blog to be migrated to a new server

Just a quick update to let you know that this blog/changelog will soon be migrated to a new (faster) server.

I’ll keep (unavoidable, due to DNS changes [see comments below, ed.]) downtimes at the minimum and will inform you in advance about expected outages.

Thanks for your understanding.

Erase/wipe free space using Mac OS X

When deleting a file, most operating systems just delete the reference to this file, not its actual content. For illustration, that’s like removing a chapter from a book’s table of contents without actually removing (and shredding) the according pages in the book.

So, in order to really (securely) delete a file on a hard disk, there are basically two methods (simplified; from a technical point of view it’s both the same):

  • Overwrite the file content (i.e. its clusters) with random data
  • Delete the file as usual, empty the trash and overwrite the whole free space on the according hard disk with random data

For the second method, here’s how to do it using Mac OS X:

  1. Delete the file(s) and empty the trash
  2. Find out the device name of the according hard disk by opening a new ‘Terminal’ window and executing the “df” command. For example, for a RAID 1 disk, the path of the disk might be something like “/dev/disk2”
  3. In the opened ‘Terminal’ window, execute:
    diskutil secureErase freespace 1 /dev/disk2
    where “1” stands for “single-pass random-fill erase” and “/dev/disk2” is the disk device  (adjust this to match your disk). When prompted, enter the admin’s credentials.

Note that overwriting free space like this takes quite some time depending on the amount of free space there is and how many passes you need (e.g. use “2” for a US DoD 7-pass secure erase or “3” for a Gutmann 35-pass secure erase). For more information about diskutil and its options, see “man diskutils”.