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 attachment 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 attachment 130113 [details, diff] 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 attachment 130118 [details, diff] 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.
Comment on attachment 130118 [details, diff] stunnel-4.20-fPIC.diff 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
