AppStream Error in Ubuntu 16.04 Xenial

I’d been seeing this error recently:

AppStream cache update completed, but some metadata was ignored due to errors.

According to a Q&A on AskUbuntu, this is the result of a bug in the app stream package.

The package has as of 24 December is not yet in the package updates for 16.04; therefore, to fix it one either needs to add it from the proposed repository or from the backports repository.

Once you’ve enabled the backports repository (which you may not have to do at all) you can specifically pull the package from backports with this command:

sudo apt install appstream/xenial-backports

Now instead of the default version 0.9.4, you should have the updated version (0.10.1 of this writing):

appstreamcli —version
AppStream CLI tool version: 0.10.1

To complete the process, you need to update the cache data:

sudo appstreamcli refresh —force

Then make sure to do an update and upgrade to get any missed updates:

sudo apt-get update
sudo apt-get upgrade

And clean up the last of the update by removing the now unneeded libappstream3:

sudo apt-get autoremove

This should fix the problem once and for all.

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:

enabled=0

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.

Puppet refuses to run: “run already in progress”

Recently, one of the servers appeared to not be keeping up with configuration changes. Since it runs Puppet, this is a problem – it means that the changes at the puppet server are not getting propagated to the clients. The server is running Ubuntu Lucid Lynx Server 10.04.3 and Puppet 2.6.3.

So I shut down the puppet agent and tried running it manually:

# service puppet stop
 * Stopping puppet agent
   ...done.
# puppet agent --test
notice: Run of Puppet configuration client already in progress; skipping
#

Since puppet is definitively not running, I had to do some research and find out why it was not running.

I found this bug (Puppet bug #2888) that stated sometimes puppet does not remove its lockfile /var/lib/puppet/state/puppetdlock. Sure enough, on my system, the lockfile was still there. I deleted it and puppet ran normally.

There was also a bug report (Puppet bug #5246) that suggested puppet sometimes does not remove its pidfile /var/lib/puppet/run/agent.pid. Some of the testing suggests that this bug is confined to running puppet --onetime (without other options). I don’t think this affected me: after removing the lockfile, puppet ran normally.

Fixing an Android Phone that Locks on Boot

My Android phone started locking up upon boot during the initialization done by the Swapper app. My phone – a Samsung Mesmerize a/k/a Samsung Fascinate – is running cyanogenmod 7 and a shameful number (150+) of apps. I actually reduced the number of apps from its previous high of 300+ (“There’s an App for that! And I have it right here!”)

A Google search and I found a description of how to enter Safe Mode on the Samsung Fascinate.

I also found details on why using swap on Android doesn’t make sense, as well as discussion on the cyanogenmod wiki about why swap is not necessary.

Armed with this information, I booted my Samsung Mesmerize into Safe Mode. This is done by pressing the Menu button when the Samsung display appears (or is it the cyanogenmod logo?). When the system recognizes Safe Mode, it will buzz several times, then continue normally. However, the display will have “Safe Mode” in the lower left hand corner.

Having booted into Safe Mode, I went into Settings > Applications > Manage Applications… and removed Swapper from the device. I then rebooted, and started in normal mode. Fortunately for me, Swapper was indeed the culprit (if it hadn’t thrown up a dialog box, I would have been stumped!).

Now without swap, the device seems to almost be more responsive – perhaps swap was not such a good idea after all.

Investigating Mysterious Outbound TCP Connections

Recently, I had a situation where a firewall had outgoing TCP connections I knew nothing about. If you are to maintain a secure system and a secure network, this sort of thing demands investigation. (I won’t report full details in order to maintain anonymity for various entities.)

Where to start, then? First, use tcpdump and capture the traffic. It may be useful to capture it into a file for looking at with Wireshark. I watched the traffic flow across all interfaces by using tcpdump:

tcpdump -s0 -n -i any host 999.999.999.999

I noticed that there was no traffic coming from anywhere except the outgoing port on the firewall.

Then I became more interested in the IP address being connected to and the port (443 or HTTPS in this case). Connecting to the IP on port 443 didn’t turn up anything interesting (except they used Red Hat Enterprise Linux). Looking up the IP address in a whois listing showed that the IP address was very similar to that of the firewall maker – very interesting indeed. Looking up the IP in reverse DNS showed it to be an Amazon AWS host in Ireland.

Then I wrote a script that used lsof to watch for a connection and find the program making the connection:

#!/bin/bash

WORK=/tmp/work.$$
PORT=":443"

# Prep: erase if present
rm -f $WORK

while true ; do
    if $(lsof -ni $PORT > $WORK) ; then
        ( echo "Found ports open:" ; echo ; cat $WORK ; echo ; echo "Process data:" ; echo
          lsof $(cat $WORK | sed -n '1d; s/^[^ ]*  *\([^ ]*\).*$/-p \1 /p;') ) | \
        mail -s "Found something on port $PORT" me@myhost.example.com
        echo "Sent message at $(date)..."
    fi
done

# Clean up
rm -f $WORK

Because lsof returns 0 only if it has something to report, this works beautifully. I could have slowed it down with a sleep command, but this worked for my purposes.

It showed a program being run that was part of the firewall. Since it was running periodically, I went and looked for it in the crontab files:

grep program /etc/cron/

I found this program in a file in the /etc/anacron.hourly directory. If I had wanted to, I could have stopped the program from running at all by changing this file. I ran the commands independently of the crontab file to see what the output would be.

I was also able to get help from the program by using the option --help. The program was actually a python script located in /usr/bin, and I searched out the actual code that was called: it was compiled python source (a *.pyc file) found in /usr/lib/python2.4/site-packages/ – the compiled source can be decompiled and investigated.

If I wanted to take complete control, the program could have been renamed and a script put in its place which called the original script and did a little extra – such as report by mail every time the command runs, what the command line was, what the output was, and more.

There’s a lot that can be found out if you just know where to look.

Debugging Problems with Chrome Extensions (and One You Can’t Live Without!)

I’ve had some niggling problems with my Chromium installation on Ubuntu 10.10, and just never got around to fixing them. Now I’ve not only fixed the one I most wanted to fix, but I also fixed others as well.

Before I discuss the solution… the problems.

The first problem I’ve had is that I couldn’t look at any of the pictures of Android phone displays in the Android Market. I could see them and click on them, but nothing would happen. Similarly, I could click on “more” to see more of the description, but nothing would happen.

Second major problem was with Mint: the “details” bar in the transaction list was off, and the current transaction highlight was also off: decidedly not conducive to reading or getting things done.

I knew that at least some of these problems had to do with extensions because the pages worked when the extensions were off. The quickest way to turn off all extensions in Chrome (assuming a default installation) isn’t to restart in safe mode or to disable extensions one by one – or even to use an extension to turn all the extension off: the quickest way is to use Incognito Mode. Simply copy the URL and paste it into an Incognito window and watch what happens.

To narrow it down further, I turned to another extension: One Click Extensions Manager. Between this and Incognito Mode, the amount of debugging time saved is just tremendous!

Using the One Click Extensions Manager, I turned off all extensions, then started enabling them one at a time. Before I knew it, my problems were resolved.

The problem with the Market turned out to be caused by a bug in Droid Code. I found this out by turning the extensions back on one by one. Turns out that this bug has been mentioned in the reviews; I just never saw it. Unfortunately, I use Droid Code all the time – however, I replaced it with the QR Code Generator for Android Market and now things work again.

After resolving the problem with the Android Market, I thought I’d do a Google search to find the problem with Mint.com. The problem with Mint turned out to have to do with the Orbvious Interest extension, an extension that provides quick access to Read-It-Later. Turned out there was a bug report (or two!) about this very problem.

Using One Click Extensions Manager made enabling and disabling extensions a one-click process: once the list of extensions is open, a single click will either enable/disable it (left-click) or uninstall it (right-click). It’s unbelievable until you try it: disabling in the Google Extensions Manager is a very slow process.

A side benefit to all of this is I got to clean out some of my extensions: I do tend to collect them willy-nilly (oh, the shame of it!).

Ubuntu: dpkg fails with “failed in buffer_read(fd)”

Recently, I was trying to update (and upgrade) Ubuntu Lucid, and received this error while running apt-get:

dpkg: unrecoverable fatal error, aborting:
failed in buffer_read(fd): files list for package `apparmor': Input/output error
E: Sub-process /usr/bin/dpkg returned an error code (2)

The solution was summarized nicely by Vivek Kapoor; he attributes the solution to C.M. Connelly (from 5 May, 2003). One of the nice things about Connelly’s entry is that he shows you how he debugged the problem he had, and how he fixed it; go read the post.

The error message is coming from dpkg, and refers to the “files list for package `apparmor'“. The files list is in /var/lib/dpkg/info; in this case, /var/lib/dpkg/info/apparmor.list. The problem being referred to in the error message is that, for some reason, this file cannot be read.

This file can be recreated if you have the package on hand; if not, you can fetch it with apt-get install -d package (possibly with the --reinstall option if necessary). The package will be downloaded to /var/cache/apt/archives, and even if a reinstall is attempted, the reinstall will fail (through dpkg) even though the download through apt succeeds.

The info file contains lines like this (using the top five lines of apparmor as an example):

drwxr-xr-x root/root         0 2010-03-30 14:59 ./
drwxr-xr-x root/root         0 2010-03-30 14:59 ./sbin/
-rwxr-xr-x root/root    783108 2010-03-30 14:59 ./sbin/apparmor_parser
drwxr-xr-x root/root         0 2010-03-30 14:59 ./etc/
drwxr-xr-x root/root         0 2010-03-30 14:59 ./etc/apparmor/

To recreate the file, pipe the output from dpkg -c debfile – like this:

dgd@cor:/var/cache/apt/archives$ dpkg -c apparmor_2.5-0ubuntu3_i386.deb |sudo tee /var/lib/dpkg/info/apparmor.list >/dev/null

After that, you should be good to go. You might want to check the disk (using fdisk) and perhaps reinstall the package to make sure all files are okay.

I don’t understand how this dpkg problem can last for seven years now; dpkg should be able to cleanly handle the recreation of this file if necessary, and shouldn’t be reporting obscure messages about its internal workings. From a user perspective – and a system administrator perspective – dpkg should automatically recreate the list file if there are problems with it, or even recreate all control files used by the package.

One very interesting tip was hidden in Connelly’s blog post from 2003: you can use less on a Debian package and it will report useful information (here’s an example from first lines of apparmor):

apparmor_2.5-0ubuntu3_i386.deb:
 new debian package, version 2.0.
 size 350314 bytes: control archive= 3944 bytes.
    2338 bytes,    61 lines      conffiles            
     360 bytes,    18 lines   *  config               #!/bin/sh
     662 bytes,    15 lines      control              
     708 bytes,    10 lines      md5sums              
    3577 bytes,   119 lines   *  postinst             #!/bin/sh
    2402 bytes,    90 lines   *  postrm               #!/bin/sh
    1186 bytes,    52 lines   *  preinst              #!/bin/sh
     959 bytes,    32 lines   *  prerm                #!/bin/sh
     421 bytes,     9 lines      templates            
 Package: apparmor
 Version: 2.5-0ubuntu3
 Architecture: i386
 Maintainer: Ubuntu Core Developers 
 Installed-Size: 2248
 Depends: libc6 (>= 2.8), debconf (>= 0.5) | debconf-2.0, lsb-base, initramfs-tools, debconf
 Suggests: apparmor-profiles, apparmor-docs
 Conflicts: libapache2-mod-apparmor (<< 2.5-0ubuntu2)
 Replaces: apparmor-parser, libapache2-mod-apparmor (<< 2.5-0ubuntu2)
 Section: admin
 Priority: extra
 Homepage: http://apparmor.wiki.kernel.org/
 Description: User-space parser utility for AppArmor
  AppArmor Parser is a user level programs that is used to load in program
  profiles to the AppArmor Security kernel module.

*** Contents:
drwxr-xr-x root/root         0 2010-03-30 14:59 ./
drwxr-xr-x root/root         0 2010-03-30 14:59 ./sbin/

How much can you find out about a HP-UX process?

The answer to this question can be important many times. Let’s take some examples of what can be done to find out all we can about a particular process.

There are, of course, simple things that can be done. Let’s take midaemon as an example. From the command line, we can find out where it is, what it is, and some description of it:

# type midaemon
midaemon is /opt/perf/bin/midaemon
# what `which midaemon`
/opt/perf/bin/midaemon:
        midaemon       C.04.70.000  10/03/07 HP-UX 11 =*=
# file `which midaemon`
/opt/perf/bin/midaemon: ELF-32 executable object file - IA64
# ldd `which midaemon`
        libpthread.so.1 =>      /usr/lib/hpux32/libpthread.so.1
        libIO.so =>     /opt/perf/lib/hpux32/libIO.so
        libc.so.1 =>    /usr/lib/hpux32/libc.so.1
        libdl.so.1 =>   /usr/lib/hpux32/libdl.so.1
# man midaemon
# cd /sbin/init.d
# grep midaemon
# cd /etc/rc.config.d
# grep -i midaemon *
# swlist -l file | grep midaemon
  MeasurementInt.MI: /opt/perf/bin/midaemon
  MeasurementInt.MI: /opt/perf/man/man1/midaemon.1
  MeasurementInt.MI-JPN: /opt/perf/man/ja_JP.SJIS/man1/midaemon.1
#

This tells us a lot already: it’s part of the performance system (/opt/perf) and is 32-bit and is part of the MeasurementInt package (and has a Japanese man page!). The man page explains the program in detail.

But there’s more. Let’s suppose that lsof is on hand (as it should be!); then we can do this:

# lsof -c midaemon
COMMAND   PID USER   FD   TYPE DEVICE SIZE/OFF  NODE NAME
midaemon 2198 root  cwd    DIR 64,0x3     8192     2 /
midaemon 2198 root  txt    REG 64,0x5   828932 13799 /opt/perf/bin/midaemon
midaemon 2198 root  mem    REG 64,0x8    19799   956 /usr/lib/tztab
midaemon 2198 root  mem    REG 64,0x8    87900    78 /usr/lib/hpux32/libnss_dns.so.1
midaemon 2198 root  mem    REG 64,0x8   169104   722 /usr/lib/hpux32/libnss_files.so.1
midaemon 2198 root  mem    REG 64,0x8    76236 19454 /usr/lib/hpux32/libdl.so.1
midaemon 2198 root  mem    REG 64,0x8  4929272   695 /usr/lib/hpux32/libc.so.1
midaemon 2198 root  mem    REG 64,0x5   115124 13809 /opt/perf/lib/hpux32/libIO.so
midaemon 2198 root  mem    REG 64,0x8  1505144   734 /usr/lib/hpux32/libpthread.so.1
midaemon 2198 root  mem    REG 64,0x8  1065976 19453 /usr/lib/hpux32/dld.so
midaemon 2198 root  mem    REG 64,0x8   176988 19535 /usr/lib/hpux32/uld.so
midaemon 2198 root    2u   REG 64,0x9     1174 17923 /var (/dev/vg00/lvol9)
midaemon 2198 root    3u   REG 64,0x9     1174 17923 /var (/dev/vg00/lvol9)
midaemon 2198 root    4u   REG 64,0x9    11303 17949 /var (/dev/vg00/lvol9)
midaemon 2198 root    5u   REG 64,0x9    11303 17949 /var (/dev/vg00/lvol9)
midaemon 2198 root    7r   REG 64,0x9    13689  1620 /var/opt/perf/parm

This shows that the working directory is / (root); stdin and stdout are closed (0u and 1u in the FD column); stderr is still open and tied to /var; and there are four other file descriptors open: three on /var and one is the /var/opt/perf/parm file (configuration). We can also deduce that there was another file descriptor opened which is now closed (and would have been 6u).

There is also no network connections open, or pipes, or other things.

The ps output provides more details:

# ps -elf | sed -n '1p; /midaem[.]*on/p;'
  F S      UID   PID  PPID  C PRI NI             ADDR   SZ            WCHAN    STIME TTY       TIME COMD
541 R     root  2198     1  0 -16 20 e00000060de31b80  524                -  Jan 15  ?        28:55 /opt/perf/bin/midaemon

From this we can see it is relatively small (SZ = 524). This example also shows a couple of tricks: using sed this way keeps the header intact (1p) and also matches midaemon without matching the search string.

Using glance, we can find out even more. Using the text mode command glance, first select the process (using the command key s and entering the pid – 2198). Then a view of the current activity by the process is given. In this case, we can see the total size is 51.6Mb (VSS) and in memory size is 44.8Mb (RSS). We can also see that the process appears to be switching voluntarily almost all of the time – that is, it never utilizes its full time slice when scheduled.

From that process summary display, enter the command key M. This provides a detailed memory display of the process – very useful. The various types of memory used by the process are broken down at the bottom in summary: text refers to the program code; data is program data; stack is a working area as well as where function calls are stored; shmem refers to shared memory (memory shared between processes); and other, which is everything else. All these areas are shown explicitly above in the main display.

Using the command key F, we can see again what lsof showed us. With an inode number, we can search for the file explicitly. Using lsof:

# lsof  | sed -n '1p;  / 17949 /p'
COMMAND     PID     USER   FD   TYPE             DEVICE    SIZE/OFF    NODE NAME
scopeux    2150     root    0u   REG             64,0x9       11303   17949 /var (/dev/vg00/lvol9)
scopeux    2150     root    1u   REG             64,0x9       11303   17949 /var (/dev/vg00/lvol9)
scopeux    2150     root    2u   REG             64,0x9       11303   17949 /var (/dev/vg00/lvol9)
scopeux    2150     root    4u   REG             64,0x9       11303   17949 /var (/dev/vg00/lvol9)
scopeux    2150     root    5u   REG             64,0x9       11303   17949 /var (/dev/vg00/lvol9)
midaemon   2198     root    4u   REG             64,0x9       11303   17949 /var (/dev/vg00/lvol9)
midaemon   2198     root    5u   REG             64,0x9       11303   17949 /var (/dev/vg00/lvol9)
# lsof  | sed -n '1p;  / 17923 /p'
COMMAND     PID     USER   FD   TYPE             DEVICE    SIZE/OFF    NODE NAME
midaemon   2198     root    2u   REG             64,0x9        1174   17923 /var (/dev/vg00/lvol9)
midaemon   2198     root    3u   REG             64,0x9        1174   17923 /var (/dev/vg00/lvol9)
#

It would appear that scopeux (another command) is sharing a file with midaemon (inode 17949) on /var, and that inode 17923 is not shared. Since there is no file listed, it is likely that these files were created, then deleted after opening. (The inode remains, but the file is not listed in the directory).

Another useful tool is tusc:

sybil # tusc 2198
( Attached to process 2198 ("/opt/perf/bin/midaemon") [32-bit] )
ki_call(KI_TRACE_GET, 0x40080ab0, 0x80000, 0x7ffff860) ............................................................... [sleeping]
In user-mode ......................................................................................................... [sleeping]
In user-mode ......................................................................................................... [sleeping]
In user-mode ......................................................................................................... [sleeping]
In user-mode ......................................................................................................... [sleeping]
ksleep(PTH_CONDVAR_OBJECT, 0x400108b0, 0x400108b8, NULL) ............................................................. [sleeping]
ki_call(KI_TRACE_GET, 0x40080ab0, 0x80000, 0x7ffff860) ............................................................... = 8
kwakeup(PTH_CONDVAR_OBJECT, 0x400108b0, WAKEUP_ONE, 0x7ffff7c0) ...................................................... = 0
ksleep(PTH_CONDVAR_OBJECT, 0x400108b0, 0x400108b8, NULL) ............................................................. = 0
ki_call(KI_TRACE_GET, 0x40080b50, 0x80000, 0x7ffff860) ............................................................... = 8
kwakeup(PTH_CONDVAR_OBJECT, 0x400108b0, WAKEUP_ONE, 0x7ffff7c0) ...................................................... = 0
ksleep(PTH_CONDVAR_OBJECT, 0x400108b0, 0x400108b8, NULL) ............................................................. = 0
ki_call(KI_TRACE_GET, 0x40080bf0, 0x80000, 0x7ffff860) ............................................................... = 8
kwakeup(PTH_CONDVAR_OBJECT, 0x400108b0, WAKEUP_ONE, 0x7ffff7c0) ...................................................... = 0
ksleep(PTH_CONDVAR_OBJECT, 0x400108b0, 0x400108b8, NULL) ............................................................. = 0
ki_call(KI_TRACE_GET, 0x40080c90, 0x80000, 0x7ffff860) ............................................................... = 8
ksleep(PTH_CONDVAR_OBJECT, 0x400108b0, 0x400108b8, NULL) ............................................................. = 0
kwakeup(PTH_CONDVAR_OBJECT, 0x400108b0, WAKEUP_ONE, 0x7ffff7c0) ...................................................... = 0
ki_call(KI_TRACE_GET, 0x40080ab0, 0x80000, 0x7ffff860) ............................................................... = 8
kwakeup(PTH_CONDVAR_OBJECT, 0x400108b0, WAKEUP_ONE, 0x7ffff7c0) ...................................................... = 0
ksleep(PTH_CONDVAR_OBJECT, 0x400108b0, 0x400108b8, NULL) ............................................................. = 0
( Detaching from process 2198 ("/opt/perf/bin/midaemon") )

The tusc command will show you what the process is doing, and what system calls it is making. If the process can be started from scratch (by restarting the program binary) then a lot of information can be gathered using tusc.

A summary view of this same data can be gotten from glance, using the L command key to show the system calls made and the time spent in each one. Just ask tusc related, in this case ki_call(), ksleep(), and kwakeup() are the three system calls be done.

Again using glance, if you want to see the wait states for the process (reasons the process gives up the CPU to other processes) use the W key command. For midaemon, it shows sleep as the reason for 85% of wait states in this process.

We can look through the binary for even more detail:

# strings `which midaemon` | head -n 7
/var/opt/perf/status.mi
/var/opt/perf/status.mi
/dev/ptym/
@$Header: miflock.c,v 1.2 95/09/27 08:43:20 thierry Exp $
@(#)midaemon       C.04.70.000  10/03/07 HP-UX 11 =*=
-pstat_freq
        4p
# tail -n 30 /var/opt/perf/status.mi
midaemon: Tue Oct 28 23:53:34 2008
Start midaemon       C.04.70.000  10/03/07 HP-UX 11 =*=
midaemon: Wed Oct 29 03:31:41 2008
Stop midaemon - non-permanent/no-client, normal MI termination
midaemon: Wed Oct 29 03:39:56 2008
Start midaemon       C.04.70.000  10/03/07 HP-UX 11 =*=
midaemon: Tue Nov 11 19:10:11 2008
Stop midaemon - non-permanent/no-client, normal MI termination
midaemon: Tue Nov 11 19:21:32 2008
Start midaemon       C.04.70.000  10/03/07 HP-UX 11 =*=
midaemon: Fri Nov 21 21:30:21 2008
Stop midaemon - non-permanent/no-client, normal MI termination
midaemon: Fri Nov 21 21:38:29 2008
Start midaemon       C.04.70.000  10/03/07 HP-UX 11 =*=
midaemon: Fri Nov 28 10:15:28 2008
Start midaemon       C.04.70.000  10/03/07 HP-UX 11 =*=
midaemon: Wed Dec 10 11:41:26 2008
Start midaemon       C.04.70.000  10/03/07 HP-UX 11 =*=
midaemon: Thu Jan 15 21:31:06 2009
Stop midaemon - Commanded MI termination
midaemon: Thu Jan 15 21:42:42 2009
Start midaemon       C.04.70.000  10/03/07 HP-UX 11 =*=
midaemon: Thu Jan 15 21:55:53 2009
Stop midaemon - Commanded MI termination
midaemon: Thu Jan 15 22:03:59 2009
Start midaemon       C.04.70.000  10/03/07 HP-UX 11 =*=

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.

Solaris Virtual Memory Analysis: a tour through one admin’s process

This article by A. J. Clark was very informative; it doesn’t just show you what the problem is, but takes you through the process as the administrator analyzes a Solaris 8 server trying to find out why swap space was so heavily used. Go read it!