Home | Docs | Forums | Lists | Bugs | Planet | Store | GMN | Get Gentoo!

Full Text Bug Listing

ive upgraded to stunnel 4.14 and now after every connection i see zombie
processes  of stunnel.
strace shows that their parents are waiting for some action:

ps auxw | grep stun
stunnel  26754  0.0  1.0   3660  1948 ?        SNs  13:30   0:00 stunnel
stunnel  26755  0.0  0.0      0     0 ?        ZN   13:30   0:00 [stunnel] <defunct>

strace -p 26754
Process 26754 attached - interrupt to quit
poll(

in the logfile i can find only this:

Nov 28 13:36:22 felix stunnel: LOG5[28707:1]: Connection closed: 37 bytes sent
to SSL, 49 bytes sent to socket
Nov 28 13:36:22 felix stunnel: LOG5[28707:1]: stack_info: size=65536,
current=4668 (7%), maximum=4668 (7%)

so stunnel thinks its closed the connection and should have exited but it does
not do that.

i am running stunnel through xinetd and have no problems with previous (i
believe it was 4.10) version.

my emerge info:
Portage 2.0.53_rc7 (default-linux/x86/2005.1, gcc-3.4.4, glibc-2.3.5-r3,
2.6.14-gentoo i686)
=================================================================
System uname: 2.6.14-gentoo i686 Pentium II (Deschutes)
Gentoo Base System version 1.12.0_pre11
distcc 2.18.3 i686-pc-linux-gnu (protocols 1 and 2) (default port 3632) [enabled]
dev-lang/python:     2.4.2
sys-apps/sandbox:    1.2.13
sys-devel/autoconf:  2.13, 2.59-r7
sys-devel/automake:  1.4_p6, 1.5, 1.6.3, 1.7.9-r1, 1.8.5-r3, 1.9.6-r1
sys-devel/binutils:  2.16.1
sys-devel/libtool:   1.5.20-r1
virtual/os-headers:  2.6.11-r3
ACCEPT_KEYWORDS="x86 ~x86"
AUTOCLEAN="yes"
CBUILD="i686-pc-linux-gnu"
CFLAGS="-pipe -march=pentium2 -O3 -fstack-protector"
CHOST="i686-pc-linux-gnu"
CONFIG_PROTECT="/etc /usr/kde/2/share/config /usr/kde/3/share/config
/usr/share/config /var/bind /var/qmail/control"
CONFIG_PROTECT_MASK="/etc/gconf /etc/terminfo /etc/env.d"
CXXFLAGS="-pipe -march=pentium2 -O3 -fstack-protector"
DISTDIR="/usr/portage/distfiles"
FEATURES="autoconfig collision-protect distcc distlocks sandbox sfperms strict
userpriv usersandbox"
GENTOO_MIRRORS="http://linux.rz.ruhr-uni-bochum.de/download/gentoo-mirror
http://gentoo.mirror.solnet.ch http://trumpetti.atm.tut.fi/gentoo/"
MAKEOPTS="-j3"
PKGDIR="/usr/portage/packages"
PORTAGE_TMPDIR="/home/portagetmp"
PORTDIR="/usr/portage"
SYNC="rsync://1g.compfort.com.pl/gentoo-portage"
USE="x86 alsa apm arts avi berkdb bitmap-fonts bzip2 caps chroot clearpasswd
crypt curl eds elf emboss encode expat foomaticdb gd gif glibc-omitfp gmp gpm
gstreamer hardened idn imlib kde libg++ libwww mad mbox mhash mikmod minimal
motif mp3 mpeg ncurses nptl nptlonly ogg oggvorbis opengl oss pam pam_chroot
pam_timestamp pcre pdflib perl png pwdb python qt quicktime readline sdl
sendfile sftplogging ssl symlink tcpd threads truetype-fonts type1-fonts udev
vorbis xinetd xml2 xmms xv zlib userland_GNU kernel_linux elibc_glibc"
Unset:  ASFLAGS, CTARGET, LANG, LC_ALL, LDFLAGS, LINGUAS, PORTDIR_OVERLAY

stunnel 4.14 on i686-pc-linux-gnu UCONTEXT+POLL+IPv6+LIBWRAP with OpenSSL 0.9.7i
14 Oct 2005

another comment on this subject:
stunnel says i have ipv6 compiled although i have not used ipv6 USE flag.

Please, remove aliz from metadata.xml wrt Bug 112192...

Doing a quick glance on their mailing list, I don't see anything that describes
this exactly. The only suggestion I saw was try running it without a chroot and
in the foreground. See what that does.

About the ipv6 thing, I've noticed that their configure script isn't
acknowledging the option correctly. I'll have to poke around and see why that
is, but for now I'm not sure whats going on.

ok here are my findings:

running stunnel in the foreground standalone with no other options changed 
(that is, compression chroot socket options and setuid turned on) works
flawlessly and stunnel properly closes connections - no defunct processess left.

running it through xinetd with all above options disabled has the effect i
initially described. after turning level 7 logging i can see:
...
2005.11.29 17:38:17 LOG7[16594:1]: SSL write shutdown
2005.11.29 17:38:17 LOG7[16594:0]: Waiting 60 second(s) for 2 file descriptor(s)
2005.11.29 17:38:17 LOG7[16594:0]: CONTEXT 1, FD=0, (IN)->()
2005.11.29 17:38:17 LOG7[16594:0]: CONTEXT 1, FD=1, (OUT)->(OUT)
2005.11.29 17:38:17 LOG7[16594:1]: SSL alert (write): warning: close notify
2005.11.29 17:38:17 LOG7[16594:1]: SSL_shutdown retrying
2005.11.29 17:38:17 LOG7[16594:1]: SSL doesn't need to read or write
2005.11.29 17:38:17 LOG7[16594:0]: Waiting 60 second(s) for 1 file descriptor(s)
2005.11.29 17:38:17 LOG7[16594:0]: CONTEXT 1, FD=0, (IN)->(IN)
2005.11.29 17:38:17 LOG7[16594:1]: SSL socket closed on SSL_read
2005.11.29 17:38:17 LOG7[16594:1]: Socket write shutdown
2005.11.29 17:38:17 LOG5[16594:1]: Connection closed: 37 bytes sent to SSL, 49
bytes sent to socket
2005.11.29 17:38:17 LOG7[16594:1]: stunnel finished (0 left)
2005.11.29 17:38:17 LOG5[16594:1]: stack_info: size=65536, current=4444 (6%),
maximum=4444 (6%)
2005.11.29 17:38:17 LOG7[16594:1]: Context 1 closed
2005.11.29 17:38:17 LOG7[16594:0]: Waiting -1 second(s) for 0 file descriptor(s)


it seems stunnel is happy with the connection although i am a little bit worried
about the last message?

i'll try recompiling stunnel 4.14 with different threading model and see what
(if anything) changes.

are you by any chance subscribed to stunnel mailing list? if so you could
forward the info to them :)

OK ladies and gentlemen here are my latest findings ;)

stunnel through xinetd works great with fork and pthread threading model.
it does not work so well with ucontext model (defunct processess).

i would recommend using one of the above, especially that ucontext has had some
security and performance problems in the past.

when NO ipv6 option is used with configure (--disable-ipv6 and such), stunnel
compiles with ipv4 option as expected when no USE flag ipv6 is used.

another question is why is there USE flag 'ssl' used in stunnel ebuild ? it is
not used by ebuild script at all.

hope this information helps someone out there

best regards,

(In reply to comment #5)

> stunnel through xinetd works great with fork and pthread threading model.
> it does not work so well with ucontext model (defunct processess).
> 
> i would recommend using one of the above, especially that ucontext has had some
> security and performance problems in the past.

Looking at the configure script, it seems as though it'll enable all those
threading models if you don't set it at compile time? Are you suggesting I pick
between using pthread or fork?

> when NO ipv6 option is used with configure (--disable-ipv6 and such), stunnel
> compiles with ipv4 option as expected when no USE flag ipv6 is used.

Ok, so you're saying that the use flag for ipv6 is working as expected or isn't?

> another question is why is there USE flag 'ssl' used in stunnel ebuild ? it is
> not used by ebuild script at all.

Thats from the ssl-cert eclass I use in the ebuild. I agree the useflag makes it
redundant, but the eclass is useful for this ebuild.

Actually, I take that back.. It seems to pick ucontext first. So I'll need to
pick between pthread or fork. Think that should be a useflag or just default to
one or the other?

Created an attachment (id=73800) [details]
patched ebuild

(In reply to comment #6)
> (In reply to comment #5)

> Looking at the configure script, it seems as though it'll enable all those
> threading models if you don't set it at compile time? Are you suggesting I pick
> between using pthread or fork?
dont know whether it compiles them all in but it chooses the specified one when
run. and it also modifies its version string indicating the threading model
used. havent found an option to choose between them during runtime. thus, i
would recommend choosing threading model that works fine.

> 
> > when NO ipv6 option is used with configure (--disable-ipv6 and such), stunnel
> > compiles with ipv4 option as expected when no USE flag ipv6 is used.
> 
> Ok, so you're saying that the use flag for ipv6 is working as expected or isn't?
ok i have messed it up a little :)
if you specify --disable-ipv6, ipv6 gets compiled in. seems to be their error:

./configure --disable-ipv6
...
checking whether to enable IPv6 support... yes
...
if you omit ipv6 option, only ipv4 gets compiled in.

ive found another mistake in the ebuild of stunnel 4.14. configure option for
disabling wrappers is now --disable-libwrap.

> 
> > another question is why is there USE flag 'ssl' used in stunnel ebuild ? it is
> > not used by ebuild script at all.
> 
> Thats from the ssl-cert eclass I use in the ebuild. I agree the useflag makes it
> redundant, but the eclass is useful for this ebuild.
> 

have no idea about eclasses yet thanks for the info though :)


i have included a modified version of the ebuild for stunnel 4.14. please check
it and tell me what you think.

heh it seems stunnel reacts exactly the same odd way when it comes to libwrap.
if you specify disable-libwrap, it disables it.
if you specify enable-libwrap, it disables it as well :)

so another if use flag needed just as with ipv6 case.

Yeah, I noticed in their changelog that they changed the tcp wrappers name and
was going to update the ebuild once I had this issue sorted. About the
--disable-ipv6 not working as aspected, I just tried what you suggested and that
indeed does what its supposed to do. I'll see about getting on their mailing
list and finding out whats going on. 

Thanks for working all of this out! I'll let you know what I find out on my end.

Please, test w/ 4.20; if it still doesn't work for you, attach a unified diff
against that version and reopen.

time flows so quickly... almost two years have passed,
i'm using stunnel version 4.20 now with default ebuild and i dont recall any
problems whatsoever.

Thanks for reporting back. Arches, please stabilize 4.20; been in the tree
since February without any bugs.

Seems to work here, marked ppc stable.  The ppc64 keyword seems to have been
dropped, so I also added ~ppc64 and will leave ppc64 CC'd for later
stabilization.

?

Stable for HPPA.

CC'ing ia64 as they probably want in as well.

ia64 doesn't want to stabilize it

net-misc/stunnel-4.20

stunnel libs namely libstunnel.so are being built without -fPIC on AMD64.

x86 stable

alpha stable, thanks Tobias

Created an attachment (id=130113) [details]
stunnel-4.20-fPIC.diff

Patch to make libstunnel.so being compiled with -fPIC.

NOTE: The stunnel executable is also being built with same objects (built with
-fPIC) as libstunnel.so.

Created an attachment (id=130118) [details]
stunnel-4.20-fPIC.diff

Errr.. Just forget the other patch.. I was thinking in another thing when I
made it.

It should work this time.. It builds ONLY libstunnel.so with PIC.

(From update of attachment 130118 [details])
Useless patch.. Its building correctly without it.. Guess I didn't saw the fPIC
on the first time. Sorry for delaying amd64 stabilization.

net-misc/stunnel-4.20  USE="ssl tcpd -ipv6 (-selinux)"

- Emerges on AMD64.
- Tested by tunneling http data to an apache server.
  The certificates generated by ebuild didn't work on my setup. I had to create
new ones.

amd64 stable.
Please have a look into the auto-created certificates. They're not signed
correctly.

sparc stable

ppc64 stable