Apport uses 100% CPU in Xubuntu 15.04 Vivid Vervet

I was on Second Life the other day, and Firestorm froze solid. After killing it, I went back on and then the entire system froze (the graphical windowing system did not respond at all).

Taking a look at the output from atop, I saw that apport was running and taking 100% CPU (user mode). This was apparently enough to freeze all of the other processes such as X11 and Firestorm and Skype and Chromium and XFCE and the rest.

I killed apport and lo! everything returned to normal.

Researching this shows that a bug was reported way back in 2008 with Hardy, and remains present in 2012 in Precise Pangolin (and here it shows on my Vivid Vervet system). The problem occurs when apport is enabled on a “production” system such as a user’s desktop, instead of a machine being used for development of the Ubuntu distribution.

To disable it, go into the file /etc/defaults/apport and change the appropriate line so it reads:


That will disable apport so it won’t run on boot. The next step is to actually stop it entirely with:

service apport stop

If you really want to make sure everything is clean, you can reboot instead. This way, apport never starts at all, nor anything that depends on it.

If you want to go all out, you can remove apport entirely with:

apt-get remove apport

If you purge it, your configuration files are removed too – but by just removing it, you have a greater chance that apport won’t be enabled on an upgrade. If you upgrade from one distribution version to another, it might be re-enabled.

Another thing you may wish to do is to clean out the crash directory. The utility apport reads the crash directory and has been known to hang there. Cleaning it out may help in the event that apport winds up running and hangs. Clean it out with:

rm -f /var/crash/*

Hopefully, this will help you resolve any apport issues.

Disabling compcache in Ubuntu Jaunty (and Related Swap Errors)

If you have installed Ubuntu recently, you may have compcache enabled. This is a memory-based swap cache and its presence is unnecessary and unexpected in a permanent installation (it was designed for LiveCD operations). There is a bug report about compcache being enabled, along with directions on how to remove it.

This bug can also be seen if you are seeing errors like these:

Mar 6 17:27:29 server kernel: [14438.135859] compcache: Error allocating memory for compressed page: 60594, size=4096
Mar 6 17:27:29 server kernel: [14438.135871] Write-error on swap-device (254:0:484752)
Mar 6 17:27:29 server kernel: [14438.136813] allocation failed: out of vmalloc space - use vmalloc= to increase size.
Mar 6 17:27:29 server kernel: [14438.136824] compcache: Error allocating memory for compressed page: 60595, size=2093
Mar 6 17:27:29 server kernel: [14438.136835] Write-error on swap-device (254:0:484760)
Mar 6 17:27:29 server kernel: [14438.137088] allocation failed: out of vmalloc space - use vmalloc= to increase size.
Mar 6 17:27:29 server kernel: [14438.137098] compcache: Error allocating memory for compressed page: 60596, size=4079
Mar 6 17:27:29 server kernel: [14438.137108] Write-error on swap-device (254:0:484768)

You can also see it when you print swap information with the command swapon -s – if compcache is enabled, one of the swap entries will be “ramzswap”.

To disable compcache completely, do this:

rm -f /usr/share/initramfs-tools/conf.d/compcache && update-initramfs -u

The file compcache contains this line – which is what enables (and sizes) compcache:


This was summarized nicely in this email on the ubuntu-users mailing list in February of this year.

Getting the PalmPilot to work in Ubuntu Jaunty

I was surprised when I found that the Gnome Pilot Applet didn’t work – it didn’t appear at all. In the past I just brushed it off: but then, I decided it was time to get it fixed.

Strangely enough, there is a bug report about this and it is fixed in Karmic Koala (the upcoming version of Ubuntu) but not in Jaunty. This could be fixed in Jaunty but it isn’t. Can’t say why – makes no sense to me. The fix is to use an updated version of gnome-pilot which includes a patch to fix the bug – but this updated package is only available for Karmic.

However, loading the updated version of the gnome-pilot package (using the i386 version) was simple and there were no problems. I then restarted the gnome-pilot daemons for good measure:

sudo pkill gpilot

Probably overkill – but it doesn’t hurt. Then add the Pilot Applet to the panel and you should see the icon – and your gpilotd daemon will start in the background.

Next, click on the applet itself – and wait. The gnome-pilot Settings window should appear shortly. Make sure that the ID is not zero. This causes a bug (which is described in another bug report) where installs do not work. If the ID is zero, then click on Edit and change the PDA ID to another number (I used 5). Then click on Send to PDA and follow the instructions.

If you change the ID, you will have to go back into the Conduits tab (again in gnome-pilot Settings) and enable all of the conduits you want to use.

Once all of this is done, you should find that your PalmPilot is working up to par. Too bad that a distribution such as Ubuntu or Mint (both of which are billed as Linux for the normal person’s desktop) don’t properly support a PalmPilot “out of the box”.

Bug: synergyc freezes

If you are using Synergy in your daily work, you may have noticed that the Linux client is not working as it should. A bug (Bug #194029) reported to the Ubuntu development team provides extensive reports about the problem and possible resolutions. The biggest problem is sifting through all of them, as well as the realization that they don’t seem to have it fixed yet.

Admittedly, my problems are with Fedora 9 and Windowmaker (which shows that its not Ubuntu-specific, nor is it specific to GNOME or KDE). However, the resolutions seem to work under Fedora just as well as under Ubuntu.

The resolutions recommended are:

  • Run synergy as root: sudo synergyc. This resolution seems to be one least likely to work.
  • Run synergy with the highest priority possible using chrt: chrt -p 99 synergyc. This method can be incorporated into a startup script thusly: /usr/bin/synergyc myserver; pgrep synergyc | sudo xargs chrt -p 99
  • Recompiling the Linux kernel with a different scheduler: instead of configuring with CONFIG_FAIR_USER_SCHED use CONFIG_FAIR_CGROUP_SCHED.
  • Patching synergyc to fix the problem.
  • Enabling (for Ubuntu only) the hardy-proposed repository and updating the kernel to 2.6.24-16 or 2.6.24-17-generic seemed to work (although there were complaints that the desktop became sluggish).

In the case of Fedora 9 at least, this bug remains present even though it is almost a year old. I don’t use synergyc on a Ubuntu client – my Kubuntu host I use almost entirely at the console directly.

So what is the answer? I’d try using chrt first (for me that lessened the problem dramatically) and try upgrading to a new kernel configuration.