SABnzbd Forums

What do you have at "hotel" end. Just a laptop with a browser?
I assume all the other software is running on your server.
It is possible to have SABnzbd listen on both HTTP and HTTPS, on different ports.
Just make sure that only the HTTPS port is made available for internet access by your router.
SickBeard and CouchPotato can use the internal-only HTTP port.

Why HTTPS is leaving so many sockets open, I don't know.
Sander: any idea whether these are left open by SABnzbd or by the other two apps?

shypike wrote:What do you have at "hotel" end. Just a laptop with a browser?
I assume all the other software is running on your server.
It is possible to have SABnzbd listen on both HTTP and HTTPS, on different ports.
Just make sure that only the HTTPS port is made available for internet access by your router.
SickBeard and CouchPotato can use the internal-only HTTP port.

Why HTTPS is leaving so many sockets open, I don't know.
Sander: any idea whether these are left open by SABnzbd or by the other two apps?

That is how I had it setup before it crashed the most recent time. All the apps are using the internal HTTP connection (Sickbeard, Couchpotato, and Headphones). It was purely the laptop/phone using the hotel's wifi that had crashed it.

sander wrote:As a workaround, you could try to restart SABnzbd each hour from crontab. A simple wget / curl / lynx should work. See http://wiki.sabnzbd.org/api#toc21

Disclaimer: I assume but I'm not 100% sure a restart solves the half open connections. So ... test it. :-)

EDIT:

easier method: let SABnzbd restart itself via the builtin scheduler. See http://localhost:8080/config/scheduling/

I was going to say, in sudo's crontab I could just add a service sabnzbdplus restart. I didn't even think about using the scheduler... I go home tomorrow, next time I'm away if I run into the problem again I can try that.

Like I said, I have no explanation for the crashes.
My own downloading is done on a small Ubuntu 12.04 server,
on which SABnzbd runs for weeks with https.
Sander: any bright ideas?
BTW: do you also use a browser plugin like nzbStatus?

shypike wrote: Why HTTPS is leaving so many sockets open, I don't know.
Sander: any idea whether these are left open by SABnzbd or by the other two apps?

I would say: something wrong in the TCP handling / handshake between client and server (=cherrypy, right?) See http://en.wikipedia.org/wiki/File:Tcp_s ... _fixed.svg

I can easily imagine that some small plugin code does not handle that state diagram as it should.
Another possible cause: the certificate for SAB's HTTPS is not an official one. Browsers give a warning. Maybe embedded code leaves some session open?

Anyway: I think it's cherrypy's fault it does not clean up those old, half open sessions; cherrypy should protect itself against those sessions and clean them up after some time.

But why is it not a problem for everyone else?
Is there something "special" in FlexibleToast's setup?

shypike wrote:But why is it not a problem for everyone else?
Is there something "special" in FlexibleToast's setup?

I'm not sure. Things that might play a role:
- HTTPS. I'm quite sure it only happens on HTTPS, not on HTTP. If so, that is important information in root-causing the problem
- the Operating System SAB is running on? Does it only happen with Linux (or even only Ulubuntu), or also on Windows, OSX?
- plugins that are used to access SAB? Might be a caused by a nasty plugin: high frequency, or not beautifully programmed
- non-official HTTPS certificate?
- HTTP version used: 0.9, 1.0 or 1.1?
- cherrypy version? Which cherry version does SAB use on Windows?
- known bug in cherrypy?

It would be nice if we could reproduce the problem in a controlled environment. I tried myself yesterday evening: a lot of wget's against SAB's https, and the number of open connections went up (which is strange; the wgets had already finished), but they disappeared automatically after a few minutes (which is good). So, so far I can't reproduce the problem.

Until the root cause has been found, I think a patch would be useful:

I wonder if Cherrypy itself can see it's open connections. And if Cherrypy can close old, hanging connection. A kind of garbage collection
If not, SAB could use a netstat method, and restart itself if the number goes above a certain threshold.

I found a HTTPS load generator for Linux: "siege".

I ran it for a few minutes, and ... alas no problems: no (half) open sessions in netstat ...

shypike wrote:BTW: do you also use a browser plugin like nzbStatus?

Yes, I have an extension for Chrome, it's called Sab Connect, I believe.

shypike wrote:But why is it not a problem for everyone else?
Is there something "special" in FlexibleToast's setup?

It must be something somewhat common. The solution was discovered in the Frequently Asked Questions.
I only ever had this problem when I was at the hotel though. I always connect from outside my network at my dyndns.org site vs the actual local IP. I'm thinking that how the hotel's network handled connections was the problem.

FlexibleToast wrote:

shypike wrote:BTW: do you also use a browser plugin like nzbStatus?

Yes, I have an extension for Chrome, it's called Sab Connect, I believe.

Ah, SABconnect++, right? That is certainly a suspect. Can you disable it, or let it use plain HTTP?

EDIT:

SABconnect++ should be the first item to check for in the case of unresponding HTTPS:

http://forums.sabnzbd.org/viewtopic.php ... tps#p63784

sander wrote:

FlexibleToast wrote:

shypike wrote:BTW: do you also use a browser plugin like nzbStatus?

Yes, I have an extension for Chrome, it's called Sab Connect, I believe.

Ah, SABconnect++, right? That is certainly a suspect. Can you disable it, or let it use plain HTTP?

EDIT:

SABconnect++ should be the first item to check for in the case of unresponding HTTPS:

http://forums.sabnzbd.org/viewtopic.php ... tps#p63784

I can switch it to local ip and http so it only connects if I'm connected by vpn. However, like I said before, while at home it works just fine and it connects to the external address.