☑ apport in a storm

Ubuntu’s apport service is less then helpful for developers — learn how to disable it.

port storm

I’m not sure quite when it appeared, but Ubuntu 12.04 has a service called apport which is a bit of a pain.

It’s started by default and appears to attempt to collect crash dump information, presumably to send back to Ubuntu. I’ve seen little notification icons appearing at one time or another which I assume is this service doing its job. I’m not going to get into the potential privacy implications of sending core dumps of possibly commercial third party software (the rest of the system may filter the core dumps, I’m not sure), but if you’re a developer trying to get hold of core dumps this is annoying. I discovered this application when trying to figure out where my core dumps were disappearing to.

What happens is that the Upstart job for the service alters the value of /proc/sys/kernel/core_pattern, which changes where core dump files are stored, to pipe the core dump into /usr/share/apport/apport, which is a Python script. This script attempts to write the core dump to the local directory first, and then writes an annotated copy elsewhere, which is presumably picked up by some other background job which puts cutesy little exclamation marks into the notification area or something similar.

In principle, this isn’t all that terrible — after all, general users wouldn’t know a core dump if it bit them on the rear (and you really wouldn’t want a dump biting you in the rear). However, one rather crucial problem is that it ignores any previously set value of core_pattern and simply dumps its own value over it. The script always attempts to dump the core file into the current directory, regardless of the old value of core_pattern.

This is a bit of an issue because I use union mounts for building software, to avoid cluttering up my source directories with build artifacts, and these often confuse the kernel when it tries to generate core dumps. As a result, I change core_pattern to the following to store all core dumps in a central location:

/var/log/cores/core.%e.%p

This worked fine until I rebooted for some reason and suddenly apport stuck its ugly nose in.

Anyway, fortunately it’s pretty easy to disable. First edit /etc/default/apport and set enabled to 0:

1
2
3
4
# set this to 0 to disable apport, or to 1 to enable it
# you can temporarily override this with
# sudo service apport start force_start=1
enabled=0

Then, just stop the service:

sudo service apport stop

At this point you’ll want to check that it’s restored the value of core_pattern to something sensible, and update it yourself if not.

That’s one more developer annoyance in Ubuntu taken care of.

29 Jan 2013 at 1:16PM by Andy Pearce in Software  | Photo by Anna Goncharova on Unsplash  | Tags: linux  ubuntu debugging  |  See comments

☑ Bash expansion weirdness

Expanding a substring of “$*” in bash seems to magically add command-line parameter zero.

inflatable flamingo

Here’s a quirky one. In the bash shell, "$*" expands to a single string which is a whitespace-separated list of arguments starting at one. So if you have the following script as script.sh:

1
2
#!/bin/bash
echo Arguments: "$*"

… and you call it as script.sh arg1 arg2 arg3 then you’ll get the following output:

Arguments: arg1 arg2 arg3

So far so tedious. However, if we use some of bash’s parameter expansion rules to select a substring (in this case the substring starting at zero, or the whole string in fact):

1
2
#!/bin/bash
echo Arguments: "${*:0}"

… then suddenly you get parameter zero (the filename of the script) included:

Arguments: ./script.sh arg1 arg2 arg3

I’m not sure if that’s a bug or I’m missing some subtlety and it’s expected behaviour, but it’s one of those issues that’s pretty tough to Google around so I suspect it’ll remain a mystery.

25 Jan 2013 at 11:12AM by Andy Pearce in Software  | Photo by Vicko Mozara  | Tags: linux bash  |  See comments

⇐ Page 1   |   ← Page 5   |   Page 6 of 6