Bug#529929: subversion: SOCK_CLOEXEC problem (EINVAL)
Johann Glaser
Version: 1.5.6dfsg-1
Severity: important
Subversion using HTTPS protocol stopped working today. Regarding to strace
it does an
socket(PF_INET, 0x80001 /* SOCK_??? */, IPPROTO_TCP) = -1 EINVAL (Invalid argument)
where 0x80001 means SOCK_STREAM | SOCK_CLOEXEC but strace doesn't seem to
know that (yet). Strangely the kernel rejects this flag (while a socket()
with SOCK_DGRAM with IPPROTO_IP for a DNS lookup worked a few lines before).
$ uname -a
Linux glaser 2.6.26 #1 PREEMPT Thu Dec 25 21:38:28 CET 2008 i686 GNU/Linux
Using libneon27-gnutls version 0.28.4-1.
-- System Information:
Debian Release: squeeze/sid
APT prefers testing-proposed-updates
APT policy: (500, 'testing-proposed-updates'), (500, 'proposed-updates'), (500, 'unstable'), (500, 'testing'), (500, 'stable'), (1, 'experimental')
Architecture: i386 (i686)
Kernel: Linux 2.6.26 (PREEMPT)
Locale: LANG=de_AT@euro, LC_CTYPE=de_AT@euro (charmap=ISO-8859-15)
Shell: /bin/sh linked to /bin/bash
Versions of packages subversion depends on:
ii libapr1 1.3.3-4 The Apache Portable Runtime Librar
ii libc6 2.9-12 GNU C Library: Shared libraries
ii libsasl2-2 2.1.22.dfsg1-25 Cyrus SASL - authentication abstra
ii libsvn1 1.5.6dfsg-1 Shared libraries used by Subversio
subversion recommends no packages.
Versions of packages subversion suggests:
pn db4.6-util <none> (no description available)
ii patch 2.5.9-5 Apply a diff file to an original
ii subversion-tools 1.5.6dfsg-1 Assorted tools related to Subversi
-- no debconf information
--
To UNSUBSCRIBE, email to debian-bugs-...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Peter Samuelson
[Johann Glaser]
> Subversion using HTTPS protocol stopped working today. Regarding to strace
> it does an
> socket(PF_INET, 0x80001 /* SOCK_??? */, IPPROTO_TCP) = -1 EINVAL (Invalid argument)
> where 0x80001 means SOCK_STREAM | SOCK_CLOEXEC but strace doesn't seem to
> know that (yet). Strangely the kernel rejects this flag (while a socket()
> with SOCK_DGRAM with IPPROTO_IP for a DNS lookup worked a few lines before).
Thanks for the detailed report.
> Using libneon27-gnutls version 0.28.4-1.
Yes, the bug is most likely in neon, since svn does not do any https
protocol work on its own. As a workaround (and diagnostic), you might
try the serf http/https backend instead. In ~/.subversion/servers:
[global]
http-library = serf
--
Peter Samuelson | org-tld!p12n!peter | http://p12n.org/
Aurelien Jarno
> Package: subversion
> Version: 1.5.6dfsg-1
> Severity: important
>
> Subversion using HTTPS protocol stopped working today. Regarding to strace
> it does an
> socket(PF_INET, 0x80001 /* SOCK_??? */, IPPROTO_TCP) = -1 EINVAL (Invalid argument)
> where 0x80001 means SOCK_STREAM | SOCK_CLOEXEC but strace doesn't seem to
> know that (yet). Strangely the kernel rejects this flag (while a socket()
> with SOCK_DGRAM with IPPROTO_IP for a DNS lookup worked a few lines before).
>
> $ uname -a
> Linux glaser 2.6.26 #1 PREEMPT Thu Dec 25 21:38:28 CET 2008 i686 GNU/Linux
>
You need a kernel >= 2.6.27 (or a higher version on some architecture)
to be able to use SOCK_CLOEXEC. The code should have fallback for these
kernels.
--
Aurelien Jarno GPG: 1024D/F1BCDB73
aure...@aurel32.net http://www.aurel32.net
Peter Samuelson
reassign 529929 libneon27
thanks
> On Fri, May 22, 2009 at 01:26:58PM +0200, Johann Glaser wrote:
> > socket(PF_INET, 0x80001 /* SOCK_??? */, IPPROTO_TCP) = -1 EINVAL (Invalid argument)
> > where 0x80001 means SOCK_STREAM | SOCK_CLOEXEC but strace doesn't seem to
> > know that (yet). Strangely the kernel rejects this flag (while a socket()
> > with SOCK_DGRAM with IPPROTO_IP for a DNS lookup worked a few lines before).
> >
> > $ uname -a
> > Linux glaser 2.6.26 #1 PREEMPT Thu Dec 25 21:38:28 CET 2008 i686 GNU/Linux
[Aurelien Jarno]
> You need a kernel >= 2.6.27 (or a higher version on some
> architecture) to be able to use SOCK_CLOEXEC. The code should have
> fallback for these kernels.
This code in neon's src/ne_socket.c:
#ifndef SOCK_CLOEXEC
#define SOCK_CLOEXEC 0
#define USE_CLOEXEC
#endif
implies that support for SOCK_CLOEXEC is detected by what is defined in
a kernel header. Instead it needs to be detected at runtime, given a
binary Linux distribution such as Debian. I'm reassigning this bug
accordingly. It looks like a duplicate of bug 529920, but I'm not
sure, so I'm not merging them.
Laszlo Boszormenyi
On Sat, 2009-05-23 at 09:55 -0500, Peter Samuelson wrote:
> > On Fri, May 22, 2009 at 01:26:58PM +0200, Johann Glaser wrote:
> > > $ uname -a
> > > Linux glaser 2.6.26 #1 PREEMPT Thu Dec 25 21:38:28 CET 2008 i686 GNU/Linux
>
> [Aurelien Jarno]
> > You need a kernel >= 2.6.27 (or a higher version on some
> > architecture) to be able to use SOCK_CLOEXEC. The code should have
> > fallback for these kernels.
Yes, on amd64 with kernel 2.6.30-rc2 it works, but not with 2.6.26.
> implies that support for SOCK_CLOEXEC is detected by what is defined in
> a kernel header. Instead it needs to be detected at runtime, given a
> binary Linux distribution such as Debian.
Agree. Joe, can you please fix it?
Regards,
Laszlo/GCS
Joe Orton
> Hi all,
>
> On Sat, 2009-05-23 at 09:55 -0500, Peter Samuelson wrote:
> > > On Fri, May 22, 2009 at 01:26:58PM +0200, Johann Glaser wrote:
> > > > $ uname -a
> > > > Linux glaser 2.6.26 #1 PREEMPT Thu Dec 25 21:38:28 CET 2008 i686 GNU/Linux
> >
> > [Aurelien Jarno]
> > > You need a kernel >= 2.6.27 (or a higher version on some
> > > architecture) to be able to use SOCK_CLOEXEC. The code should have
> > > fallback for these kernels.
> Yes, on amd64 with kernel 2.6.30-rc2 it works, but not with 2.6.26.
>
> > implies that support for SOCK_CLOEXEC is detected by what is defined in
> > a kernel header. Instead it needs to be detected at runtime, given a
> > binary Linux distribution such as Debian.
> Agree. Joe, can you please fix it?
It's on my todo list, but I'm not sure when I'll get to it. Patches
welcome.
Regards, Joe