From @schweikert

Created by @schweikert

This is a bug report for perl from david@​schweikert.ch,
generated with the help of perlbug 1.35 running under perl v5.8.8.

-----------------------------------------------------------------
Socket​::SOMAXCONN() seems to always return 128 on Linux. That value is,
however, dynamic and can be set/queried with the
/proc/sys/net/core/somaxconn file.

Cheers,
David

PS​: see also bug #44259 about a similar problem on Solaris.

Flags:
    category=library
    severity=medium

Site configuration information for perl v5.8.8:

Configured by Debian Project at Wed Dec  6 23:17:41 UTC 2006.

Summary of my perl5 (revision 5 version 8 subversion 8) configuration:
  Platform:
    osname=linux, osvers=2.6.18.3, archname=i486-linux-gnu-thread-multi
    uname='linux saens 2.6.18.3 #1 smp sat nov 25 13:39:52 est 2006 i686 gnulinux '
    config_args='-Dusethreads -Duselargefiles -Dccflags=-DDEBIAN -Dcccdlflags=-fPIC -Darchname=i486-linux-gnu -Dprefix=/usr -Dprivlib=/usr/share/perl/5.8 -Darchlib=/usr/lib/perl/5.8 -Dvendorprefix=/usr -Dvendorlib=/usr/share/perl5 -Dvendorarch=/usr/lib/perl5 -Dsiteprefix=/usr/local -Dsitelib=/usr/local/share/perl/5.8.8 -Dsitearch=/usr/local/lib/perl/5.8.8 -Dman1dir=/usr/share/man/man1 -Dman3dir=/usr/share/man/man3 -Dsiteman1dir=/usr/local/man/man1 -Dsiteman3dir=/usr/local/man/man3 -Dman1ext=1 -Dman3ext=3perl -Dpager=/usr/bin/sensible-pager -Uafs -Ud_csh -Uusesfio -Uusenm -Duseshrplib -Dlibperl=libperl.so.5.8.8 -Dd_dosuid -des'
    hint=recommended, useposix=true, d_sigaction=define
    usethreads=define use5005threads=undef useithreads=define usemultiplicity=define
    useperlio=define d_sfio=undef uselargefiles=define usesocks=undef
    use64bitint=undef use64bitall=undef uselongdouble=undef
    usemymalloc=n, bincompat5005=undef
  Compiler:
    cc='cc', ccflags ='-D_REENTRANT -D_GNU_SOURCE -DTHREADS_HAVE_PIDS -DDEBIAN -fno-strict-aliasing -pipe -I/usr/local/include -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64',
    optimize='-O2',
    cppflags='-D_REENTRANT -D_GNU_SOURCE -DTHREADS_HAVE_PIDS -DDEBIAN -fno-strict-aliasing -pipe -I/usr/local/include'
    ccversion='', gccversion='4.1.2 20061115 (prerelease) (Debian 4.1.1-20)', gccosandvers=''
    intsize=4, longsize=4, ptrsize=4, doublesize=8, byteorder=1234
    d_longlong=define, longlongsize=8, d_longdbl=define, longdblsize=12
    ivtype='long', ivsize=4, nvtype='double', nvsize=8, Off_t='off_t', lseeksize=8
    alignbytes=4, prototype=define
  Linker and Libraries:
    ld='cc', ldflags =' -L/usr/local/lib'
    libpth=/usr/local/lib /lib /usr/lib
    libs=-lgdbm -lgdbm_compat -ldb -ldl -lm -lpthread -lc -lcrypt
    perllibs=-ldl -lm -lpthread -lc -lcrypt
    libc=/lib/libc-2.3.6.so, so=so, useshrplib=true, libperl=libperl.so.5.8.8
    gnulibc_version='2.3.6'
  Dynamic Linking:
    dlsrc=dl_dlopen.xs, dlext=so, d_dlsymun=undef, ccdlflags='-Wl,-E'
    cccdlflags='-fPIC', lddlflags='-shared -L/usr/local/lib'

Locally applied patches:
    


@INC for perl v5.8.8:
    /etc/perl
    /usr/local/lib/perl/5.8.8
    /usr/local/share/perl/5.8.8
    /usr/lib/perl5
    /usr/share/perl5
    /usr/lib/perl/5.8
    /usr/share/perl/5.8
    /usr/local/lib/site_perl
    .


Environment for perl v5.8.8:
    HOME=/home/dws
    LANG=en_US.UTF-8
    LANGUAGE (unset)
    LC_COLLATE=C
    LC_TIME=C
    LD_LIBRARY_PATH (unset)
    LOGDIR (unset)
    PATH=/home/dws/bin:/usr/local/bin:/usr/bin:/bin:/usr/games:/usr/local/isgtc/bin
    PERL_BADLANG (unset)
    SHELL=/bin/bash

From jns@gellyfish.com

Hi,
On Thu, 2007-08-02 at 02​:04 -0700, David Schweikert wrote​:

Socket​::SOMAXCONN() seems to always return 128 on Linux. That value is,
however, dynamic and can be set/queried with the
/proc/sys/net/core/somaxconn file.

Cheers,
David

PS​: see also bug #44259 about a similar problem on Solaris.

I'm not so sure that this is really a "bug" - the Socket module is
behaving exactly as described that is "load the C socket.h defines" and
bits/socket.h on Linux has​:

  #define SOMAXCONN 128

Now it might be possible for Socket to gather the runtime value of this
from /proc/sys/net/core/somaxconn, but then the proc fs might not be
mounted for some reason or some version of the kernel doesn't support
this. And then there all the other operating systems that allow runtime
configuration of this value, all with different interfaces ...

My suggestion would be, in the first instance, to create a non-core CPAN
module (say Socket​::RuntimeParams or something) that can encapsulate all
the different methods for getting these runtime values for the various
OS where the socket.h value is just a default - it could even get
cunning and redefine the Socket​::SOMAXCONN (for example) when it is
used.

The advantage (as I see it) of having this initially non-core is that it
can be released more quickly to a wider audience (I'd guess it wouldn't
appear in 5.10 even if it was core) and can be used by people stuck with
an older Perl on these platforms. The advantage of having it in a
separate module in the first place is that it will simplify development
( SOMAXCONN is currently retrieved from an autoloaded XS constant()
subroutine,) and means that it will be easier not to burden users who
are not on an affected system with the extra code.

Of course it might be worth updating the documentation for Socket to
indicate that some systems might have this runtime configuration.

/J\

The RT System itself - Status changed from 'new' to 'open'

From ams@toroid.org

At 2007-08-02 21​:31​:08 +0100, jns@​gellyfish.com wrote​:

I'm not so sure that this is really a "bug" - the Socket module is
behaving exactly as described that is "load the C socket.h defines"

I agree. Probing (this, and other) runtime parameters should be left to
a separate module.

Of course it might be worth updating the documentation for Socket to
indicate that some systems might have this runtime configuration.

Good idea.

-- ams

From @schweikert

On Thu, Aug 02, 2007 at 20​:28​:18 -0700, Abhijit Menon-Sen via RT wrote​:

I'm not so sure that this is really a "bug" - the Socket module is
behaving exactly as described that is "load the C socket.h defines"

I agree. Probing (this, and other) runtime parameters should be left to
a separate module.

Nobody is going to require a CPAN module only to query the value of
SOMAXCONN... Also, why would you want to have the SOMAXCONN value of
socket.h instead of the real value as used by the system?

Cheers
David

From jns@gellyfish.com

On Fri, 2007-08-03 at 08​:34 +0200, David Schweikert wrote​:

On Thu, Aug 02, 2007 at 20​:28​:18 -0700, Abhijit Menon-Sen via RT wrote​:

I'm not so sure that this is really a "bug" - the Socket module is
behaving exactly as described that is "load the C socket.h defines"

I agree. Probing (this, and other) runtime parameters should be left to
a separate module.

Nobody is going to require a CPAN module only to query the value of
SOMAXCONN... Also, why would you want to have the SOMAXCONN value of
socket.h instead of the real value as used by the system?

Well to be fair they are already using a module to get the value of
SOMAXCONN (albeit one that doesn't reflect the maximum backlog that the
system might actually allow.)

The great advantage of having the determination of the runtime
determination of the real maximum backlog in a separate module is that
it will be available to people using older versions of perl​: it seems to
me unlikely that Socket will ever be dual-lifed. It also makes it easier
to develop as currently SOMAXCONN is provided by the constant() XSUB in
Socket and we can avoid burdening people who do not have a dynamic
maximum backlog with the extra code.

This doesn't preclude such a module going into the core or even that
Socket might use it to determine the value in the future if that is what
people decide to do.

It appears from looking at the documentation for Linux and FreeBSD that
there is nothing stopping you from providing INT_MAX (and possibly also
a negative value) for backlog which will result in you getting the
configured value, I don't have any other systems to check this with at
the moment but if someone were to confirm that other systems where the
maximum backlog is configurable also behave like this (without an error)
then I would propose to change the perlfunc entry for listen(), the
relevant parts of perlipc and the Socket manpage to reflect this.

It would be nice if there were a single sysctl interface that could be
used across a variety of OS types but Linux and FreeBSD have a different
"MIB" and the Linux documentation appears to suggest that the sysctl
interface might be unstable and it is better to go directly to
the /proc/sys - of course any ideas about this are welcome :-)

SoOoo, if everyone's basically happy with changing the documentation as
above (subject to confirmation that the same works on other systems with
a configurable somaxconn,) I'll make with the appropriate patches. Then
I'll start looking at making a module to get at the real runtime values,
suggestions for the name of which would be welcome as well as the method
of obtaining the values on OS we haven't already discussed. And then we
can take a look at a way of possibly incorporating these values into
Socket somehow if people think that's a good idea.

Does that sound like a plan?

/J\
--
Winners don't do de-tox

From jns@gellyfish.com

Hi,
On Fri, 2007-08-03 at 15​:20 +0200, David Schweikert wrote​:

Hi Jonathan,

On Fri, Aug 03, 2007 at 14​:03​:55 +0100, Jonathan Stowe wrote​:

It appears from looking at the documentation for Linux and FreeBSD that
there is nothing stopping you from providing INT_MAX (and possibly also
a negative value) for backlog which will result in you getting the
configured value, I don't have any other systems to check this with at
the moment but if someone were to confirm that other systems where the
maximum backlog is configurable also behave like this (without an error)
then I would propose to change the perlfunc entry for listen(), the
relevant parts of perlipc and the Socket manpage to reflect this.

What about the following​: document that if you want the highest possible
backlog, you should just pass INT_MAX to listen(). If then there is an
operating system that can't cope with INT_MAX, it could be implemented
in listen() to limit the backlog parameter to SOMAXCONN.

We'd need to know which OS had which behaviour and possibly introduce a
Configure probe to determine this - I'm not sure that we have any
existing probes using IPC client/server code (and hence requiring a
fork()) and I fear that we would end up needing to probe for additional
stuff beforehand to see if we can perform the test and it could get
nasty, but I'll let the Configure gurus chime in on that. I'm also sure
that there will be a mixture of opinions on whether perl's listen()
behaviour should or shouldn't be changed to differ from the C libraries
one on certain systems and I'd like to hear those before doing anything
about that part.

I'd also rather not have making any changes to the behaviour of listen()
a dependency for changing the documentation in the first instance - I'm
sure we can sneak a change in the documentation past the pumpkings to
get it in for 5.10 but I would be less sure about what could be a
reasonably large addition to Configure and a change to the currently
documented behaviour (that is the same as OS listen().)

I don't think that many applications really care about what the
SOMAXCONN value is​: most applications probably just want to pass it to
listen().

I have a suspicion that anyone who cares about this will already know
that the system they are on is capable of setting the value at runtime
(or knows how to find out), if they don't know or don't care then it is
likely that the Socket​::SOMAXCONN is the correct default anyway. I could
imagine that there may well be code out there that uses a value for
backlog that is less then SOMAXCONN for a variety of reasons.

SoOoo, if everyone's basically happy with changing the documentation as
above (subject to confirmation that the same works on other systems with
a configurable somaxconn,) I'll make with the appropriate patches. Then
I'll start looking at making a module to get at the real runtime values,
suggestions for the name of which would be welcome as well as the method
of obtaining the values on OS we haven't already discussed. And then we
can take a look at a way of possibly incorporating these values into
Socket somehow if people think that's a good idea.

I am still not convinced that anybody would start using such a module.
It seems like overkill to require a module just for that. The module
being in core or not is the killer factor here...

I just see it as a way of moving this forward and not making it a
dependency for the release of , say, 5.10 - we can gather all the
required information and get it working and make it available to anyone
who might care what the effective runtime value of SOMAXCONN might be
and then we can have the conversation about putting it into the core and
having Socket use it at a later date.

We still need to get some understanding of the behaviour on other OS
than the ones that have already been mentioned as well.

/J\
--
Make war on hippies

From @schweikert

Hi Jonathan,

On Fri, Aug 03, 2007 at 14​:03​:55 +0100, Jonathan Stowe wrote​:

It appears from looking at the documentation for Linux and FreeBSD that
there is nothing stopping you from providing INT_MAX (and possibly also
a negative value) for backlog which will result in you getting the
configured value, I don't have any other systems to check this with at
the moment but if someone were to confirm that other systems where the
maximum backlog is configurable also behave like this (without an error)
then I would propose to change the perlfunc entry for listen(), the
relevant parts of perlipc and the Socket manpage to reflect this.

What about the following​: document that if you want the highest possible
backlog, you should just pass INT_MAX to listen(). If then there is an
operating system that can't cope with INT_MAX, it could be implemented
in listen() to limit the backlog parameter to SOMAXCONN.

I don't think that many applications really care about what the
SOMAXCONN value is​: most applications probably just want to pass it to
listen().

SoOoo, if everyone's basically happy with changing the documentation as
above (subject to confirmation that the same works on other systems with
a configurable somaxconn,) I'll make with the appropriate patches. Then
I'll start looking at making a module to get at the real runtime values,
suggestions for the name of which would be welcome as well as the method
of obtaining the values on OS we haven't already discussed. And then we
can take a look at a way of possibly incorporating these values into
Socket somehow if people think that's a good idea.

I am still not convinced that anybody would start using such a module.
It seems like overkill to require a module just for that. The module
being in core or not is the killer factor here...

Thanks a lot for your rapid response and help!

Cheers
David