home
> blog
>> 636

translate to German (by SYSTRAN)

Weblog RDF feed, Atom feed

Sun Jun 20 19:04:48 2010 GMT: Giant PyXMPP Memory Leak

Wed Jun 16 06:03:37 2010 GMT: Free INGATE VServers

Sat Jun 12 20:56:11 2010 GMT: Running Ubuntu Lucid Lynx with Kernel 2.6.26

I had hoped to be able to upgrade my virtual server to Ubuntu Lucid Lynx today. It started quite well as the "apt-get dist-upgrade" ran without any problems, but after the first reboot, the machine didn't come back up. A quick search on the net revealed that Lucid Lynx doesn't support any older kernels (in this case, my virtual server hoster provides Debian's stable 2.6.26 kernel).

So what do you do with a server that refuses to boot and you only have minimal access to the server? Clearly, there must be a way to work around this.

It turns out that the main issue is that some packages used during the boot process (mountall, plymouth, udev) rely on syscalls that are only available on more recent kernels: mainly pipe2 and the SOCK_CLOEXEC flag for the socket syscall. Fortunately, these can be mapped to the standard pipe syscall and the SOCK_CLOEXEC flag can simply be stripped away using a LD_PRELOAD library:

#define _GNU_SOURCE
 
#include <unistd.h>
#include <dlfcn.h>
#include <sys/socket.h>
#include <stdio.h>
 
int (*socket_fwd)(int, int, int) = NULL;
 
static void __attribute__ ((constructor)) init()
{
    socket_fwd = dlsym(RTLD_NEXT, "socket");
}
 
int pipe2(int pipedes[2], int flags)
{
    return pipe(pipedes);
}
 
int socket (int domain, int type, int protocol)
{
    return socket_fwd(domain, type & ~SOCK_CLOEXEC, protocol);
}

Compiling that into a shared library and modifying the "exec mountall" call in /etc/init/mountall.conf as follows

mount -o remount,rw /dev/hda1 /
LD_PRELOAD=/liblucidcompat.so /sbin/mountall $force_fsck $fsck_fix
ifup lo

seems to somehow "work around" the problem - well, there are still a couple of errors, but it appears to boot without any major problems. I am sure some hotplugging functionality won't work now, but I don't expect to see any hotplugging on a Xen virtualised server anyway.

BTW, don't try this at home - you could end up with a broken system...

Sun Jun 06 11:29:19 2010 GMT: JabRSS Migration to PyXMPP

I have just moved JabRSS to use PyXMPP instead of PyXPCOM/JabXPCOM/jabberoo. While the previous set up worked quite well, it got incresingly difficult to get PyXPCOM built stand-alone, so moving to PyXMPP will hopefully simplify things as it comes as a standard package for Debian/Ubuntu.

So far, the service appears to work as usual, but only time will tell if there are any hidden problems...

Sat May 29 13:35:22 2010 GMT: PyXMPP Bug

I have just been playing a bit with PyXMPP and already found a critical bug. Fortunately, it should be quite easy (almost trivial) to fix it...

Sun May 02 09:47:48 2010 GMT: IPv6 Reverse DNS

The issue with reverse DNS records for my IPv6 addresses have been solved and I have therefore been able to move almost all services over to the native IPv6 addresses. The only service still using the old HE IPv6 addresses is DNS as I need to get the glue records for ns.cmeerw.net updated at the registry (probably next week).

Fri Apr 30 21:02:57 2010 GMT: Native IPv6 Connectivity

This week I was able to set up native IPv6 connectivity for edge.cmeerw.net as IP-Projects have added support for native IPv6. There are still some minor issues such as reverse DNS not working yet, which means that I am still using the HE tunnelled IPv6 addresses as well for some services. Of course, this means that I have to do some tricky policy based routing to get packets routed to the correct uplink (based on the source address).

Wed Apr 14 08:04:14 2010 GMT: Fix for Berkeley DB's SQLite Concurrency Issue

Thu Apr 08 19:45:38 2010 GMT: Concurrency Issue in Berkeley DB/SQLite

Sun Apr 04 21:21:18 2010 GMT: Ubuntu Lucid Lynx

Thu Apr 01 20:20:08 2010 GMT: Berkeley DB Ships with SQLite Interface

Sat Mar 27 08:42:18 2010 GMT: Moving