Linux

Dear Lazyweb,

what is the best way to debug a problem with the session DBus apparently getting stuck? The KDE4 session on this computer becomes completely unresponsive. An ssh login still works but a simple

export DISPLAY=:0
qdbus

qdbus --system

strace qdbus

ps aux showed two session busses running. One from the user and another one from root. The root session bus was probably created by running Adept a few minutes before.

strace on the dbus process of the user showed it polling and calling gettimeofday, apparently at timeouts. Attaching gdb to the session bus didn't give me any information

Anyway, I don't know enough about dbus and I would like to get rid of this annoying hang. Whatever you try to do with the computer, in the end you have to fall back to SysRq + {S, U, B} since nothing else can get the system back. Any ideas how to get more information on what could be the cause?

So I wrote a blog entry, clicked "Save" and was brought to the login screen as apparently the session had timed out (how are you supposed to write a blog entry in a few minutes?). Anyway, I tried going back, but that only brought me to the login page again. OK, nothing is lost yet, I thought, the text is probably still somewhere in your 1GB of RAM. Now, how does one grep through his RAM? Of course /proc/kcore - I successfully did it for exactly the same kind of situation before, but this time it said:
cat: /proc/kcore: Operation not permitted
But I am root! How can I not be permitted to read? The permissions on the file were fine, so I looked at the kernel source and there it was:

I tried grepping through /proc/kcore on the server where s9y runs (which runs Kubuntu Breezy and doesn't have the stupid patch), hoping to find the POST data that was sent to apache, but no success.

Now I lost a few hours of my life only because of too short timeouts, and a stupid patch... I better go back to learning now.

PS: Before hitting the "Save" button I will copy the whole text into the clipboard!

Today I received a new toy: a brand new Alesis IO|2 device. It's a USB audio device with two microphone/line/guitar inputs (with insert plugs), MIDI in and out, 2 output channels and a headphone connector. The device is completely powered by the USB port and seems quite robust (haven't tested throwing it at the ground - and won't do that anytime soon ). It seems to be good for low latency setups: A simple test with jack connecting input and output, and speaking into a microphone made it feel almost like plugging the microphone directly into the mixer connected to the amp.

Getting it to work with Linux was painless, except for one caveat: The device only does 24bit, no 16bit or even 8... That means, most programs won't work with it. Only jackd opens the device without throwing errors.

Since I wanted to test other programs with the device I started playing with the ~/.asoundrc file. With a simple trick, ALSA can automatically convert 16Bit audio data to 24Bit:

The important part is the !default clause that defines the conversion to S24_3LE (omitting the format statement works as well - seems like ALSA knows the right format to use in that case).

I tried the ALSA softvol plugin (as the device has no mixing controls) but didn't succeed. Dmix also seems to be only supported for S16 and S32 hardware, so no dmix... But aRts, mplayer, ogg123, xine and of course jackd work without problems now.

Update:

There seem to be problems - either in aRts or in the ALSA format converter. After some time the music turns into static. Not nice

Now testing with JuK directly outputting using aKode...

When writing on a longer blog entry yesterday (it's not ready, yet) I thought I might give updating Serendipity a try. And while I was at it, I wanted to get rid of MySQL on the poor Server with only 256MB RAM. As I need the PostgreSQL that's also running there and free tells number like:

             total       used       free     shared    buffers     cached
Mem:        256620     248852       7768          0          0      61544
-/+ buffers/cache:     187308      69312
Swap:       489940     217300     272640

I thought it would be a good idea.

So I did a mysqldump of the data and a second installation of serendipity 0.8.1 but with a PostgreSQL DB. But then the problems started because of the encodings. The PostgreSQL DB was in UTF-8 while the MySQL dump apparently was in UTF-8 as well. But doing a "\i data.sql" in psql only gave me errors of unknown Unicode sequences. So I tried all combinations: "SET NAMES 'LATIN1'" in psql and import again. Nothing. "mysqldump --default-character-set=latin1". Import as latin1, or unicode. Sometimes the import would work, but then I would get to see unicode sequences in the serendipity output.

In the end I realized that the problem was not the import or export but serendipity. It fetched the text as unicode from the DB and didn't make sure to convert to the encoding it told the webbrowser the text was in. As 0.8.1 didn't have support for UTF-8 from the central configuration I just changed the LANG_CHARSET in the relevant files to "UTF-8" and everything worked as expected.

The update from 0.8.1 to 0.9.1 was painless and now the UTF-8 setting could be set from the admin pages. The last hurdle was to rename the serendipity directory as I wasn't working on the main blog site. Changing the paths in the serendipity configuration was not enough. I had to manually change a .htaccess file and do two updates to the DB for plugins that also saved the complete path in their config.

Now I have a shiny Serendipity 0.9.1 using PostgreSQL, ready for more blog entries to steal your time

UPDATE: Well, one more problem: The sequences for the primary keys were all at 1. So I had to set all sequences manually to the MAX(id) of the according table. Hopefully now everything works...

So it took KabelBW 2.5 months to deliver. And then my old laptop serving vir.homelinux.org died when I relocated it to my new place. Almost another month later vir.homelinux.org is back up. My brother bought himself a new laptop and I got to use his old one as my new server.

The laptop is an old Medion computer with a 1GHz Pentium III (Coppermine) and 256MB RAM. I switched the hard disk to a Hitachi 30GB that I had used before as second hard disk for my ThinkPad. The Cable-Modem, WLAN-Router and Server sit in a small cabinet in our living room. The Cable-Modem also does VoIP so that's why the telephones are on that cabinet.

As you can see on the last image, the screen suffered a strong blow. But since I almost never have to use that screen (remote administration rules) that doesn't matter much. Now I have to watch the temperature in there. It's already nicely warm. I might have to build a little cooling system.