Linux ulimit memory enforcement oddity

Found an interesting wrinkle in the Linux handling of ulimits for maximum memory size and data segment size – they are not enforced by current glibc / kernel configurations in certain conditions.

I tracked this down to the fact that somewhere around glibc 2.3 the malloc() implementation was ripped out and replaced with one that uses mmap() for allocations of 128KB or more. The kicker is that the kernel mmap() implementation only cares about the virtual memory ulimit (RLIMIT_AS) for enforcement, the others are just ignored!

So currently an application which uses small allocations (<128KB) will find malloc() failing when they hit their max mem / data seg size ulimit whereas an application that grabs RAM in larger chunks will sail happily past that without a care in the world..

Bug, feature or undefined behaviour ? You decide.. 🙂

Installing Lacie 4L Lightscribe software on AMD64 Ubuntu/Debian systems (Updated x3)

Caveat: Whilst the below works for me for those particular applications you may find that other 32-bit only applications require a fuller 32-bit environment, which you can get using a separate install of a 32-bit Ubuntu (often called a “chrooted environment”) – please see the corresponding Ubuntu Wiki page for more information.

I have a new AMD64 compatible system (an Intel quad core box) which comes with an ASUS DRW-1814BLT Lightscribe DVD burner. Problem is that I’m running a 64-bit version of KUbuntu Linux (as it’ll have 8GB RAM once the final sticks arrive) and the closed source Lightscribe software is 32-bit only and won’t install without a bit of prodding.

So, to help others, this is the hack that I did to install it successfully.

First I had previously installed the 32-bit compatibility libraries for AMD64 thus:

$ sudo apt-get install ia32-libs

Then I downloaded the Lightscribe System Software as a 32-bit .deb and the Lacie 4L package (which has a nice GUI) as the x586 RPM.

Then I installed fakeroot and alien and converted both of them to TAR files thus:

$ fakeroot alien -t lightscribe-1.10.19.1-linux-2.6-intel.deb
$ fakeroot alien -t 4L-1.0-r6.i586.rpm

Then I converted the two tar files straight back into .deb’s:

$ fakeroot alien lightscribe-1.10.19.1.tgz
$ fakeroot alien 4L-1.0.tgz

Then it’s the usual installation procedure of:

$ sudo dpkg -i ./lightscribe_1.10.19.1-2_all.deb
$ sudo dpkg -i 4l_1.0-2_all.deb

and it seems to work (though I have no Lightscribe media to test with yet!):

$ 4L-cli enumerate
Using /etc/lightscribe.rc
Drive path: /dev/sr0
Usable: 1
Full name: ASUS DRW-1814BLT 1.13 132
Model: DRW-1814BLT
Manufacturer: ASUS
Capabilities: monochrome
Drive inner radius: 21700
Drive outer radius: 58700

Update: I’ve since spotted that dpkg has a –force-architecture option, this may avoid the need for converting the lightscribe package.

Update 2: It works! I’ve successfully used the GUI to label a CD as a test.

Update 3: Paul Bailey has distilled the above into a simple recipe.

War on Difference

Bruce Schneier has written good things on why this “war on terror” is going badly wrong. Go read..

We’ve opened up a new front on the war on terror. It’s an attack on the unique, the unorthodox, the unexpected; it’s a war on different. If you act different, you might find yourself investigated, questioned, and even arrested — even if you did nothing wrong, and had no intention of doing anything wrong. The problem is a combination of citizen informants and a CYA attitude among police that results in a knee-jerk escalation of reported threats.

[…]

The problem is that ordinary citizens don’t know what a real terrorist threat looks like. They can’t tell the difference between a bomb and a tape dispenser, electronic name badge, CD player, bat detector, or a trash sculpture; or the difference between terrorist plotters and imams, musicians, or architects. All they know is that something makes them uneasy, usually based on fear, media hype, or just something being different.