Description of problem:
If the ipv6 protocol is disabled, for example by adding "alias net-pf-10 off"
into /etc/modprobe.conf, lbxproxy gets into an endless initialization loop.
It prints lines about being unable to open companion ipv6 listening sockets,
then tries again at port N+1, and so on, ad infinitum. It doesn't get to
actually starting to work, even on the existing ipv4 socket. (Actually,
it's *sockets*, since it creates hundreds of ipv4 ones in the loop.)
Version-Release number of selected component (if applicable):
Turn off ipv6. Reboot machine. Start X session. Run "lbxproxy". It may
spew a lot of text instead of being nice and quiet, and actually working.
Please report this issue to X.Org developers by filing a bug report in
the X.Org bugzilla located at http://bugs.freedesktop.org in the "xorg"
Once you've filed your bug report to X.Org, if you paste the new
bug URL here, Red Hat will continue to track the issue in the
centralized X.Org bug tracker, and will review any bug fixes that
become available for consideration in future updates.
Setting status to "NEEDINFO", awaiting X.Org bug URL for tracking.
As requested, the bz 3565 @ opendesktop. It's disappointing that you force bug
reporters to do this work twice. I know of no other RH software packager /
maintainer that imposes this requirement.
Can you explain how "CLOSED UPSTREAM" relates to a fix to this problem? The
upstream bug is still in the NEW state, so is there any reason that a later
fedora snapshot has received a fix?
"UPSTREAM" status reflects that the issue is being tracked in the upstream
bug tracker, and once a patch or solution is available from upstream, we
will review it and consider including it in a future release.
The "CLOSED" part is a misnomer. Technically it is OPEN->UPSTREAM.