Re: sslsplit needs to be restarted every 30 min.
On 2015-05-11, C.L. Martinez carlopm...@gmail.com wrote: Yep, it seems the problem is Too many open files message: leapis.com/storage.googleapis.com sproto:TLSv1.2:AES128-SHA dproto:TLSv1.2:ECDHE-ECDSA-CHACHA20-POLY1305 ssl [172.22.55.1]:41558 [74.125.226.170]:443 sni:ci6.googleusercontent.com names:*.googleusercontent.com/*.googleusercontent.com/*.blogspot.com/*.bp.blogspot.com/*.commondatastorage.googleapis.com/*.doubleclickusercontent.com/*.ggpht.com/*.googledrive.com/*.googlesyndication.com/*.googleweblight.com/*.safenup.googleusercontent.com/*.sandbox.googleusercontent.com/*.storage.googleapis.com/blogspot.com/bp.blogspot.com/commondatastorage.googleapis.com/doubleclickusercontent.com/ggpht.com/googledrive.com/googleusercontent.com/googleweblight.com/static.panoramio.com.storage.googleapis.com/storage.googleapis.com sproto:TLSv1.2:AES128-SHA dproto:TLSv1.2:ECDHE-ECDSA-CHACHA20-POLY1305 Warning: Failed to write to content log: Bad file descriptor Warning: Failed to write to content log: Bad file descriptor ssl [172.22.55.1]:50639 [74.125.226.171]:443 sni:ci4.googleusercontent.com names:*.googleusercontent.com/*.googleusercontent.com/*.blogspot.com/*.bp.blogspot.com/*.commondatastorage.googleapis.com/*.doubleclickusercontent.com/*.ggpht.com/*.googledrive.com/*.googlesyndication.com/*.googleweblight.com/*.safenup.googleusercontent.com/*.sandbox.googleusercontent.com/*.storage.googleapis.com/blogspot.com/bp.blogspot.com/commondatastorage.googleapis.com/doubleclickusercontent.com/ggpht.com/googledrive.com/googleusercontent.com/googleweblight.com/static.panoramio.com.storage.googleapis.com/storage.googleapis.com sproto:TLSv1.2:AES128-SHA dproto:TLSv1.2:ECDHE-ECDSA-CHACHA20-POLY1305 Warning: Failed to write to content log: Bad file descriptor Failed to open '/tmp/20150511T113718Z-[172.22.55.1]:50639-[74.125.226.171]:443.log': Too many open files (24) Warning: Failed to write to content log: Bad file descriptor ssl [172.22.55.1]:59905 [74.125.226.160]:443 sni:plus.google.com names:*.google.com/*.google.com/*.android.com/*.appengine.google.com/*.cloud.google.com/*.google-analytics.com/*.google.ca/*.google.cl/*.google.co.in/*.google.co.jp/*.google.co.uk/*.google.com.ar/*.google.com.au/*.google.com.br/*.google.com.co/*.google.com.mx/*.google.com.tr/*.google.com.vn/*.google.de/*.google.es/*.google.fr/*.google.hu/*.google.it/*.google.nl/*.google.pl/*.google.pt/*.googleadapis.com/*.googleapis.cn/*.googlecommerce.com/*.googlevideo.com/*.gstatic.cn/*.gstatic.com/*.gvt1.com/*.gvt2.com/*.metric.gstatic.com/*.urchin.com/*.url.google.com/*.youtube-nocookie.com/*.youtube.com/*.youtubeeducation.com/*.ytimg.com/android.com/g.co/goo.gl/google-analytics.com/google.com/googlecommerce.com/urchin.com/youtu.be/youtube.com/youtubeeducation.com sproto:TLSv1.2:AES128-SHA dproto:TLSv1.2:ECDHE-ECDSA-CHACHA20-POLY1305 Error 24 on listener: Too many open files Program exited normally. (gdb) backtrace full No stack. (gdb) thread apply all backtrace (gdb) Aha. Unless it's very busy I wouldn't expect sslsplit to use a huge number of openfiles simultaneously, so I wonder if it is failing to close something. Please try fstat | grep sslsplit soon after startup (allow a couple of requests to go through first), then again after it has handled a larger number of connections (maybe 5 minutes or so?) - let's see if something is building up. No need to run it in gdb for this now, it is exiting normally (i.e. following normal error handling and reaching the end of the program) so you could just use your normal startup script.
Re: sslsplit needs to be restarted every 30 min.
On 2015-05-13, Stuart Henderson s...@spacehopper.org wrote: On 2015-05-11, C.L. Martinez carlopm...@gmail.com wrote: Yep, it seems the problem is Too many open files message: leapis.com/storage.googleapis.com sproto:TLSv1.2:AES128-SHA dproto:TLSv1.2:ECDHE-ECDSA-CHACHA20-POLY1305 ssl [172.22.55.1]:41558 [74.125.226.170]:443 sni:ci6.googleusercontent.com names:*.googleusercontent.com/*.googleusercontent.com/*.blogspot.com/*.bp.blogspot.com/*.commondatastorage.googleapis.com/*.doubleclickusercontent.com/*.ggpht.com/*.googledrive.com/*.googlesyndication.com/*.googleweblight.com/*.safenup.googleusercontent.com/*.sandbox.googleusercontent.com/*.storage.googleapis.com/blogspot.com/bp.blogspot.com/commondatastorage.googleapis.com/doubleclickusercontent.com/ggpht.com/googledrive.com/googleusercontent.com/googleweblight.com/static.panoramio.com.storage.googleapis.com/storage.googleapis.com sproto:TLSv1.2:AES128-SHA dproto:TLSv1.2:ECDHE-ECDSA-CHACHA20-POLY1305 Warning: Failed to write to content log: Bad file descriptor Warning: Failed to write to content log: Bad file descriptor ssl [172.22.55.1]:50639 [74.125.226.171]:443 sni:ci4.googleusercontent.com names:*.googleusercontent.com/*.googleusercontent.com/*.blogspot.com/*.bp.blogspot.com/*.commondatastorage.googleapis.com/*.doubleclickusercontent.com/*.ggpht.com/*.googledrive.com/*.googlesyndication.com/*.googleweblight.com/*.safenup.googleusercontent.com/*.sandbox.googleusercontent.com/*.storage.googleapis.com/blogspot.com/bp.blogspot.com/commondatastorage.googleapis.com/doubleclickusercontent.com/ggpht.com/googledrive.com/googleusercontent.com/googleweblight.com/static.panoramio.com.storage.googleapis.com/storage.googleapis.com sproto:TLSv1.2:AES128-SHA dproto:TLSv1.2:ECDHE-ECDSA-CHACHA20-POLY1305 Warning: Failed to write to content log: Bad file descriptor Failed to open '/tmp/20150511T113718Z-[172.22.55.1]:50639-[74.125.226.171]:443.log': Too many open files (24) Warning: Failed to write to content log: Bad file descriptor ssl [172.22.55.1]:59905 [74.125.226.160]:443 sni:plus.google.com names:*.google.com/*.google.com/*.android.com/*.appengine.google.com/*.cloud.google.com/*.google-analytics.com/*.google.ca/*.google.cl/*.google.co.in/*.google.co.jp/*.google.co.uk/*.google.com.ar/*.google.com.au/*.google.com.br/*.google.com.co/*.google.com.mx/*.google.com.tr/*.google.com.vn/*.google.de/*.google.es/*.google.fr/*.google.hu/*.google.it/*.google.nl/*.google.pl/*.google.pt/*.googleadapis.com/*.googleapis.cn/*.googlecommerce.com/*.googlevideo.com/*.gstatic.cn/*.gstatic.com/*.gvt1.com/*.gvt2.com/*.metric.gstatic.com/*.urchin.com/*.url.google.com/*.youtube-nocookie.com/*.youtube.com/*.youtubeeducation.com/*.ytimg.com/android.com/g.co/goo.gl/google-analytics.com/google.com/googlecommerce.com/urchin.com/youtu.be/youtube.com/youtubeeducation.com sproto:TLSv1.2:AES128-SHA dproto:TLSv1.2:ECDHE-ECDSA-CHACHA20-POLY1305 Error 24 on listener: Too many open files Program exited normally. (gdb) backtrace full No stack. (gdb) thread apply all backtrace (gdb) Aha. Unless it's very busy I wouldn't expect sslsplit to use a huge number of openfiles simultaneously, so I wonder if it is failing to close something. Please try fstat | grep sslsplit soon after startup (allow a couple of requests to go through first), then again after it has handled a larger number of connections (maybe 5 minutes or so?) - let's see if something is building up. No need to run it in gdb for this now, it is exiting normally (i.e. following normal error handling and reaching the end of the program) so you could just use your normal startup script. Also, as mentioned before, please show the command line you're using, I've just done some small tests with divert-to (ipfw nat engine), rdr-to (pf nat engine) and static destination and haven't noticed an FD leak in the normal case. Of course if it is just very busy, you may need to raise an openfiles limit (ulimit -n if starting manually, or via the relevant class in login.conf if using an rc.d script, which would be 'daemon' unless you've added a separate class for it).
Re: sslsplit needs to be restarted every 30 min.
On 05/13/2015 06:57 AM, Stuart Henderson wrote:
On 2015-05-13, Stuart Henderson s...@spacehopper.org wrote:
On 2015-05-11, C.L. Martinez carlopm...@gmail.com wrote:
Yep, it seems the problem is Too many open files message:
leapis.com/storage.googleapis.com sproto:TLSv1.2:AES128-SHA
dproto:TLSv1.2:ECDHE-ECDSA-CHACHA20-POLY1305
ssl [172.22.55.1]:41558 [74.125.226.170]:443
sni:ci6.googleusercontent.com
names:*.googleusercontent.com/*.googleusercontent.com/*.blogspot.com/*.bp.blogspot.com/*.commondatastorage.googleapis.com/*.doubleclickusercontent.com/*.ggpht.com/*.googledrive.com/*.googlesyndication.com/*.googleweblight.com/*.safenup.googleusercontent.com/*.sandbox.googleusercontent.com/*.storage.googleapis.com/blogspot.com/bp.blogspot.com/commondatastorage.googleapis.com/doubleclickusercontent.com/ggpht.com/googledrive.com/googleusercontent.com/googleweblight.com/static.panoramio.com.storage.googleapis.com/storage.googleapis.com
sproto:TLSv1.2:AES128-SHA dproto:TLSv1.2:ECDHE-ECDSA-CHACHA20-POLY1305
Warning: Failed to write to content log: Bad file descriptor
Warning: Failed to write to content log: Bad file descriptor
ssl [172.22.55.1]:50639 [74.125.226.171]:443
sni:ci4.googleusercontent.com
names:*.googleusercontent.com/*.googleusercontent.com/*.blogspot.com/*.bp.blogspot.com/*.commondatastorage.googleapis.com/*.doubleclickusercontent.com/*.ggpht.com/*.googledrive.com/*.googlesyndication.com/*.googleweblight.com/*.safenup.googleusercontent.com/*.sandbox.googleusercontent.com/*.storage.googleapis.com/blogspot.com/bp.blogspot.com/commondatastorage.googleapis.com/doubleclickusercontent.com/ggpht.com/googledrive.com/googleusercontent.com/googleweblight.com/static.panoramio.com.storage.googleapis.com/storage.googleapis.com
sproto:TLSv1.2:AES128-SHA dproto:TLSv1.2:ECDHE-ECDSA-CHACHA20-POLY1305
Warning: Failed to write to content log: Bad file descriptor
Failed to open
'/tmp/20150511T113718Z-[172.22.55.1]:50639-[74.125.226.171]:443.log':
Too many open files (24)
Warning: Failed to write to content log: Bad file descriptor
ssl [172.22.55.1]:59905 [74.125.226.160]:443 sni:plus.google.com
names:*.google.com/*.google.com/*.android.com/*.appengine.google.com/*.cloud.google.com/*.google-analytics.com/*.google.ca/*.google.cl/*.google.co.in/*.google.co.jp/*.google.co.uk/*.google.com.ar/*.google.com.au/*.google.com.br/*.google.com.co/*.google.com.mx/*.google.com.tr/*.google.com.vn/*.google.de/*.google.es/*.google.fr/*.google.hu/*.google.it/*.google.nl/*.google.pl/*.google.pt/*.googleadapis.com/*.googleapis.cn/*.googlecommerce.com/*.googlevideo.com/*.gstatic.cn/*.gstatic.com/*.gvt1.com/*.gvt2.com/*.metric.gstatic.com/*.urchin.com/*.url.google.com/*.youtube-nocookie.com/*.youtube.com/*.youtubeeducation.com/*.ytimg.com/android.com/g.co/goo.gl/google-analytics.com/google.com/googlecommerce.com/urchin.com/youtu.be/youtube.com/youtubeeducation.com
sproto:TLSv1.2:AES128-SHA dproto:TLSv1.2:ECDHE-ECDSA-CHACHA20-POLY1305
Error 24 on listener: Too many open files
Program exited normally.
(gdb) backtrace full
No stack.
(gdb) thread apply all backtrace
(gdb)
Aha. Unless it's very busy I wouldn't expect sslsplit to use a huge
number of openfiles simultaneously, so I wonder if it is failing
to close something.
Please try fstat | grep sslsplit soon after startup (allow a couple
of requests to go through first), then again after it has handled
a larger number of connections (maybe 5 minutes or so?) - let's see
if something is building up.
No need to run it in gdb for this now, it is exiting normally (i.e.
following normal error handling and reaching the end of the program)
so you could just use your normal startup script.
Also, as mentioned before, please show the command line you're using,
I've just done some small tests with divert-to (ipfw nat engine),
rdr-to (pf nat engine) and static destination and haven't noticed
an FD leak in the normal case.
Of course if it is just very busy, you may need to raise an openfiles
limit (ulimit -n if starting manually, or via the relevant class in
login.conf if using an rc.d script, which would be 'daemon' unless
you've added a separate class for it).
Uhmmm ... I think you are right Stu, my pf rules needs to be wrong:
pass in quick inet proto tcp from $laptop to { !internal_networks
!unsupp_sslsplit_hosts } port $sslsplit_ssl_ports rdr-to 127.0.0.1
port 8443 tag intlans-to-inet
As you can see, I redirect directly to sslsplit's listening port, but
according to sslsplit's man page, that is wrong... And it seems, this is
the explination about the error of Too many open files ...
Am I right??
Re: sslsplit needs to be restarted every 30 min.
On 05/06/2015 11:15 AM, C.L. Martinez wrote: Hi all, I have a strange problem with sslsplit (installed from packages) in a OpenBSD 5.7 amd64 host. Every 30 minutes (more or less. It is not exactly), sslsplit needs to be restarted: May 6 09:50:14 obsd57 monit[23714]: Monit start delay set -- pause for 120s May 6 09:52:14 obsd57 monit[16338]: 'localhost' Monit started May 6 09:53:14 obsd57 monit[16338]: 'sslsplit' process is not running May 6 09:53:14 obsd57 monit[16338]: 'sslsplit' trying to restart May 6 09:53:14 obsd57 monit[16338]: 'sslsplit' start: /etc/rc.d/sslsplit May 6 09:53:44 obsd57 monit[16338]: 'sslsplit' process is running with pid 22344 May 6 10:27:45 obsd57 monit[16338]: 'sslsplit' process is not running May 6 10:27:45 obsd57 monit[16338]: 'sslsplit' trying to restart May 6 10:27:46 obsd57 monit[16338]: 'sslsplit' start: /etc/rc.d/sslsplit May 6 10:28:16 obsd57 monit[16338]: 'sslsplit' process is running with pid 5788 May 6 11:00:19 obsd57 monit[16338]: 'sslsplit' process is not running May 6 11:00:19 obsd57 monit[16338]: 'sslsplit' trying to restart May 6 11:00:19 obsd57 monit[16338]: 'sslsplit' start: /etc/rc.d/sslsplit May 6 11:00:49 obsd57 monit[16338]: 'sslsplit' process is running with pid 1295 Is this a normal behavior?? Or maybe exists some problem in this OpenBSD host? From the other side, all other services running in this box, works without problems: dnscrypt_proxy, pf, opensmtpd, etc ... Thanks. Hi all, I have contacted with the developer last week and told me that this is not a bug in sslsplit, points to OpenBSD. Please, any advice, help or tip??
Re: sslsplit needs to be restarted every 30 min.
On 05/11/2015 09:00 AM, Philip Guenther wrote: On Mon, May 11, 2015 at 1:13 AM, C.L. Martinez carlopm...@gmail.com wrote: On 05/06/2015 11:15 AM, C.L. Martinez wrote: I have a strange problem with sslsplit (installed from packages) in a OpenBSD 5.7 amd64 host. Every 30 minutes (more or less. It is not exactly), sslsplit needs to be restarted: ... I have contacted with the developer last week and told me that this is not a bug in sslsplit, points to OpenBSD. Did the developer point to something specific, or just say that this problem isn't being seen on other OS? Please, any advice, help or tip?? Looking at the packaging bits, it appears the sslsplit program changes uid after starting. This means that if it's coredumping, you can easily capture the core files by following the example at the bottom of the sysctl(1) manpage, doing something like the following as root: mkdir /var/crash/sslsplit chmod 700 /var/crash/sslsplit sysctl kern.nosuidcoredump=3 I suggest you *first* compile it yourself, with debugging information. You'll need to unpack the ports source for the version of OpenBSD you're running, then cd /usr/ports/security/sslsplit make CFLAGS=-ggdb reinstall Then do the mkdir/chmod/sysctl steps above so that any core files are left in /var/crash/sslsplit/, then run it and see if the restarts are leaving behind core files there. If they are, then include the gdb backtrace in your report here. Philip Guenther Here is her answer: Hi C.L., This is very likely not a bug in sslsplit itself. I cannot support the OpenBSD packages or OpenBSD monit functionality. You will have to use whatever mechanism OpenBSD provides to support their system and packages. I am not familiar with what or how that would be. Daniel Ok, I will try these recommendations Phillip. Many thanks.
Re: sslsplit needs to be restarted every 30 min.
On 2015-05-11, C.L. Martinez carlopm...@gmail.com wrote: On 05/11/2015 09:00 AM, Philip Guenther wrote: On Mon, May 11, 2015 at 1:13 AM, C.L. Martinez carlopm...@gmail.com wrote: On 05/06/2015 11:15 AM, C.L. Martinez wrote: I have a strange problem with sslsplit (installed from packages) in a OpenBSD 5.7 amd64 host. Every 30 minutes (more or less. It is not exactly), sslsplit needs to be restarted: ... I have contacted with the developer last week and told me that this is not a bug in sslsplit, points to OpenBSD. Did the developer point to something specific, or just say that this problem isn't being seen on other OS? Please, any advice, help or tip?? Looking at the packaging bits, it appears the sslsplit program changes uid after starting. This means that if it's coredumping, you can easily capture the core files by following the example at the bottom of the sysctl(1) manpage, doing something like the following as root: mkdir /var/crash/sslsplit chmod 700 /var/crash/sslsplit sysctl kern.nosuidcoredump=3 I suggest you *first* compile it yourself, with debugging information. You'll need to unpack the ports source for the version of OpenBSD you're running, then cd /usr/ports/security/sslsplit make CFLAGS=-ggdb reinstall Then do the mkdir/chmod/sysctl steps above so that any core files are left in /var/crash/sslsplit/, then run it and see if the restarts are leaving behind core files there. If they are, then include the gdb backtrace in your report here. Philip Guenther Here is her answer: Hi C.L., This is very likely not a bug in sslsplit itself. I cannot support the OpenBSD packages or OpenBSD monit functionality. You will have to use whatever mechanism OpenBSD provides to support their system and packages. I am not familiar with what or how that would be. Daniel Ok, I will try these recommendations Phillip. Many thanks. Additionally to Philip's advice, the package does not include an rc.d script so you have written your own. Please also include a copy of this script and the command line flags you're using. Can you replicate the problem if you run sslsplit in the foreground or better still in debug mode (-D)? (Did the upstream developer ask you to do this? If not, I am *very* surprised). Ideally run it from gdb in debug mode (obviously replace the set args line with whatever you normally use, plus -D): # gdb `which sslsplit` set args -c /path/to/cert.pem -D https 127.0.0.1 8585 ipfw run If/when it crashes, backtrace full and thread apply all backtrace, along with the recent debug output might be useful.
Re: sslsplit needs to be restarted every 30 min.
On Mon, May 11, 2015 at 1:13 AM, C.L. Martinez carlopm...@gmail.com wrote: On 05/06/2015 11:15 AM, C.L. Martinez wrote: I have a strange problem with sslsplit (installed from packages) in a OpenBSD 5.7 amd64 host. Every 30 minutes (more or less. It is not exactly), sslsplit needs to be restarted: ... I have contacted with the developer last week and told me that this is not a bug in sslsplit, points to OpenBSD. Did the developer point to something specific, or just say that this problem isn't being seen on other OS? Please, any advice, help or tip?? Looking at the packaging bits, it appears the sslsplit program changes uid after starting. This means that if it's coredumping, you can easily capture the core files by following the example at the bottom of the sysctl(1) manpage, doing something like the following as root: mkdir /var/crash/sslsplit chmod 700 /var/crash/sslsplit sysctl kern.nosuidcoredump=3 I suggest you *first* compile it yourself, with debugging information. You'll need to unpack the ports source for the version of OpenBSD you're running, then cd /usr/ports/security/sslsplit make CFLAGS=-ggdb reinstall Then do the mkdir/chmod/sysctl steps above so that any core files are left in /var/crash/sslsplit/, then run it and see if the restarts are leaving behind core files there. If they are, then include the gdb backtrace in your report here. Philip Guenther
Re: sslsplit needs to be restarted every 30 min.
On 05/11/2015 10:59 AM, Stuart Henderson wrote: On 2015-05-11, C.L. Martinez carlopm...@gmail.com wrote: On 05/11/2015 09:00 AM, Philip Guenther wrote: On Mon, May 11, 2015 at 1:13 AM, C.L. Martinez carlopm...@gmail.com wrote: On 05/06/2015 11:15 AM, C.L. Martinez wrote: I have a strange problem with sslsplit (installed from packages) in a OpenBSD 5.7 amd64 host. Every 30 minutes (more or less. It is not exactly), sslsplit needs to be restarted: ... I have contacted with the developer last week and told me that this is not a bug in sslsplit, points to OpenBSD. Did the developer point to something specific, or just say that this problem isn't being seen on other OS? Please, any advice, help or tip?? Looking at the packaging bits, it appears the sslsplit program changes uid after starting. This means that if it's coredumping, you can easily capture the core files by following the example at the bottom of the sysctl(1) manpage, doing something like the following as root: mkdir /var/crash/sslsplit chmod 700 /var/crash/sslsplit sysctl kern.nosuidcoredump=3 I suggest you *first* compile it yourself, with debugging information. You'll need to unpack the ports source for the version of OpenBSD you're running, then cd /usr/ports/security/sslsplit make CFLAGS=-ggdb reinstall Then do the mkdir/chmod/sysctl steps above so that any core files are left in /var/crash/sslsplit/, then run it and see if the restarts are leaving behind core files there. If they are, then include the gdb backtrace in your report here. Philip Guenther Here is her answer: Hi C.L., This is very likely not a bug in sslsplit itself. I cannot support the OpenBSD packages or OpenBSD monit functionality. You will have to use whatever mechanism OpenBSD provides to support their system and packages. I am not familiar with what or how that would be. Daniel Ok, I will try these recommendations Phillip. Many thanks. Additionally to Philip's advice, the package does not include an rc.d script so you have written your own. Please also include a copy of this script and the command line flags you're using. Can you replicate the problem if you run sslsplit in the foreground or better still in debug mode (-D)? (Did the upstream developer ask you to do this? If not, I am *very* surprised). Ideally run it from gdb in debug mode (obviously replace the set args line with whatever you normally use, plus -D): # gdb `which sslsplit` set args -c /path/to/cert.pem -D https 127.0.0.1 8585 ipfw run If/when it crashes, backtrace full and thread apply all backtrace, along with the recent debug output might be useful. Yep, it seems the problem is Too many open files message: leapis.com/storage.googleapis.com sproto:TLSv1.2:AES128-SHA dproto:TLSv1.2:ECDHE-ECDSA-CHACHA20-POLY1305 ssl [172.22.55.1]:41558 [74.125.226.170]:443 sni:ci6.googleusercontent.com names:*.googleusercontent.com/*.googleusercontent.com/*.blogspot.com/*.bp.blogspot.com/*.commondatastorage.googleapis.com/*.doubleclickusercontent.com/*.ggpht.com/*.googledrive.com/*.googlesyndication.com/*.googleweblight.com/*.safenup.googleusercontent.com/*.sandbox.googleusercontent.com/*.storage.googleapis.com/blogspot.com/bp.blogspot.com/commondatastorage.googleapis.com/doubleclickusercontent.com/ggpht.com/googledrive.com/googleusercontent.com/googleweblight.com/static.panoramio.com.storage.googleapis.com/storage.googleapis.com sproto:TLSv1.2:AES128-SHA dproto:TLSv1.2:ECDHE-ECDSA-CHACHA20-POLY1305 Warning: Failed to write to content log: Bad file descriptor Warning: Failed to write to content log: Bad file descriptor ssl [172.22.55.1]:50639 [74.125.226.171]:443 sni:ci4.googleusercontent.com names:*.googleusercontent.com/*.googleusercontent.com/*.blogspot.com/*.bp.blogspot.com/*.commondatastorage.googleapis.com/*.doubleclickusercontent.com/*.ggpht.com/*.googledrive.com/*.googlesyndication.com/*.googleweblight.com/*.safenup.googleusercontent.com/*.sandbox.googleusercontent.com/*.storage.googleapis.com/blogspot.com/bp.blogspot.com/commondatastorage.googleapis.com/doubleclickusercontent.com/ggpht.com/googledrive.com/googleusercontent.com/googleweblight.com/static.panoramio.com.storage.googleapis.com/storage.googleapis.com sproto:TLSv1.2:AES128-SHA dproto:TLSv1.2:ECDHE-ECDSA-CHACHA20-POLY1305 Warning: Failed to write to content log: Bad file descriptor Failed to open '/tmp/20150511T113718Z-[172.22.55.1]:50639-[74.125.226.171]:443.log': Too many open files (24) Warning: Failed to write to content log: Bad file descriptor ssl [172.22.55.1]:59905 [74.125.226.160]:443 sni:plus.google.com
Re: sslsplit needs to be restarted every 30 min.
On 05/11/2015 10:59 AM, Stuart Henderson wrote: On 2015-05-11, C.L. Martinez carlopm...@gmail.com wrote: On 05/11/2015 09:00 AM, Philip Guenther wrote: On Mon, May 11, 2015 at 1:13 AM, C.L. Martinez carlopm...@gmail.com wrote: On 05/06/2015 11:15 AM, C.L. Martinez wrote: I have a strange problem with sslsplit (installed from packages) in a OpenBSD 5.7 amd64 host. Every 30 minutes (more or less. It is not exactly), sslsplit needs to be restarted: ... I have contacted with the developer last week and told me that this is not a bug in sslsplit, points to OpenBSD. Did the developer point to something specific, or just say that this problem isn't being seen on other OS? Please, any advice, help or tip?? Looking at the packaging bits, it appears the sslsplit program changes uid after starting. This means that if it's coredumping, you can easily capture the core files by following the example at the bottom of the sysctl(1) manpage, doing something like the following as root: mkdir /var/crash/sslsplit chmod 700 /var/crash/sslsplit sysctl kern.nosuidcoredump=3 I suggest you *first* compile it yourself, with debugging information. You'll need to unpack the ports source for the version of OpenBSD you're running, then cd /usr/ports/security/sslsplit make CFLAGS=-ggdb reinstall Then do the mkdir/chmod/sysctl steps above so that any core files are left in /var/crash/sslsplit/, then run it and see if the restarts are leaving behind core files there. If they are, then include the gdb backtrace in your report here. Philip Guenther Here is her answer: Hi C.L., This is very likely not a bug in sslsplit itself. I cannot support the OpenBSD packages or OpenBSD monit functionality. You will have to use whatever mechanism OpenBSD provides to support their system and packages. I am not familiar with what or how that would be. Daniel Ok, I will try these recommendations Phillip. Many thanks. Additionally to Philip's advice, the package does not include an rc.d script so you have written your own. Please also include a copy of this script and the command line flags you're using. Can you replicate the problem if you run sslsplit in the foreground or better still in debug mode (-D)? (Did the upstream developer ask you to do this? If not, I am *very* surprised). Ideally run it from gdb in debug mode (obviously replace the set args line with whatever you normally use, plus -D): # gdb `which sslsplit` set args -c /path/to/cert.pem -D https 127.0.0.1 8585 ipfw run If/when it crashes, backtrace full and thread apply all backtrace, along with the recent debug output might be useful. Many thanks Stuart. I will try it as soon as possible.
sslsplit needs to be restarted every 30 min.
Hi all, I have a strange problem with sslsplit (installed from packages) in a OpenBSD 5.7 amd64 host. Every 30 minutes (more or less. It is not exactly), sslsplit needs to be restarted: May 6 09:50:14 obsd57 monit[23714]: Monit start delay set -- pause for 120s May 6 09:52:14 obsd57 monit[16338]: 'localhost' Monit started May 6 09:53:14 obsd57 monit[16338]: 'sslsplit' process is not running May 6 09:53:14 obsd57 monit[16338]: 'sslsplit' trying to restart May 6 09:53:14 obsd57 monit[16338]: 'sslsplit' start: /etc/rc.d/sslsplit May 6 09:53:44 obsd57 monit[16338]: 'sslsplit' process is running with pid 22344 May 6 10:27:45 obsd57 monit[16338]: 'sslsplit' process is not running May 6 10:27:45 obsd57 monit[16338]: 'sslsplit' trying to restart May 6 10:27:46 obsd57 monit[16338]: 'sslsplit' start: /etc/rc.d/sslsplit May 6 10:28:16 obsd57 monit[16338]: 'sslsplit' process is running with pid 5788 May 6 11:00:19 obsd57 monit[16338]: 'sslsplit' process is not running May 6 11:00:19 obsd57 monit[16338]: 'sslsplit' trying to restart May 6 11:00:19 obsd57 monit[16338]: 'sslsplit' start: /etc/rc.d/sslsplit May 6 11:00:49 obsd57 monit[16338]: 'sslsplit' process is running with pid 1295 Is this a normal behavior?? Or maybe exists some problem in this OpenBSD host? From the other side, all other services running in this box, works without problems: dnscrypt_proxy, pf, opensmtpd, etc ... Thanks.
