Tried to set up a new VPS last night — a Xen VPS with stock kernel 2.6.18. Picked Debian 5 Lenny as operating system, and then upgrade to Squeeze using
apt-get dist-upgrade. Smooth sailing so far. Until I tried to pull some of the toolchains I was trying to build from a remote subversion repository.
For example to pull the latest WordPress.
$ svn co http://core.svn.wordpress.org/trunk/ svn: OPTIONS of 'http://core.svn.wordpress.org/trunk': could not connect to server (http://core.svn.wordpress.org)
Definitely not a network issue as every single Subversion repository over HTTP is returning the same problem. A bit of gooling seems to suggest that neon is to blame (neon is the HTTP/WebDAV client library used by Subversion). Doing strace shows that:
... close(4) = 0 socket(PF_INET, 0x80001 /* SOCK_??? */, IPPROTO_TCP) = -1 EINVAL (Invalid argument) write(2, "svn: OPTIONS of 'http://core.svn."..., 115svn: OPTIONS of 'http://core.svn.wordpress.org/trunk': could not connect to server (http://core.svn.wordpress.org) ) = 115 exit_group(1) = ?
Well. According to
/usr/include/bits/socket.h, 0×80000 is
SOCK_CLOEXEC (Atomically set close-on-exec flag for the new descriptor(s).), which is not supported on Linux kernel older than 2.6.27. Here comes the problem of para-virtualisation and operating system jails — you are still running the virtualised kernel supplied by your vendor. Almost all of my VPS — Xen or OpenVZ — runs on Linux kernel 2.6.18 as it’s the kernel of choice for RHEL 5 where many virtualisation vendors want to support.
Well. Instead of rebuilding subversion with an older neon library, here is a much simpler work-around posted on Debian’s mailing list.
$ echo 'http-library=self' >> ~/.subversion/servers
Done! Subversion should now be working on the older kernels.