Webui stops responding on https

[hanker]

I've been running sabnzbd (0.6.14) under Debian for several months, no problem. Now a little weirdness has cropped up: the webui, which has responded on https for months, stopped responding on https. The web page just times out. Same in Chrome, Firefox, and Safari. The webui responds on http just fine.

If I stop and restart sabnzbd,

Code: Select all

# service sabnzbdplus stop
# service sabnzbdplus start

then the webui will respond on https again, but after a few days it will quit responding and I'll have to stop and start sab again. I haven't changed any port forwarding or anything like that. I connect by https like so

https://[my.ip.address]:9090/sabnzbd

Port 9090 is forwarded to the machine that runs sab. canyouseeme.org sees port 9090 as open.

This is no real big deal, but any ideas how I might fix this other than stopping and starting sab are appreciated!

[sander]

Could it be this: http://wiki.sabnzbd.org/faq#toc32 ? Check out with the netstat command as described there.

[hanker]

> Could it be this: http://wiki.sabnzbd.org/faq#toc32 ?

That's it. Thank you for your reply

That command produces hundreds of lines of

tcp 347 0 192.168.1.172:9090 [ip_address:port] CLOSE_WAIT 22765/python off (0.00/0/0)

I'm not running any plugins, BTW.

Is there no way short of stopping and starting sab to get it to close those half-open connections ?

[sander]

> Could it be this: http://wiki.sabnzbd.org/faq#toc32 ?

That's it. Thank you for your reply

That command produces hundreds of lines of

tcp 347 0 192.168.1.172:9090 [ip_address:port] CLOSE_WAIT 22765/python off (0.00/0/0)

I'm not running any plugins, BTW.

Is there no way short of stopping and starting sab to get it to close those half-open connections ?

The ip_address: was that your own IP address?

No plugins? No sabconnect++ etc? No other progams than your plain webbrowser?


I think it is a bug in (EDIT: the HTTPS part of) the web server framework ("cherrypy") that SAB uses. Maybe it is caused by faulty plugins / communciation, but IMHO a framework should protect itself against such probelms.
The CLOSE_WAIT stuff is pretty low level TCP stuff, and difficult to understand. I don't know cherrypy at all, so I can't help you much further there.

I don't experience the problem myself, but as a workaround you could write a crontab entry that checks the number of CLOSE_WAIT connections each hour. If that number is aboven 100 or 200, do a automatic service restart. That should clean things up.

[hanker]

> Could it be this: http://wiki.sabnzbd.org/faq#toc32 ?

That's it. Thank you for your reply

That command produces hundreds of lines of

tcp 347 0 192.168.1.172:9090 [ip_address:port] CLOSE_WAIT 22765/python off (0.00/0/0)

I'm not running any plugins, BTW.

Is there no way short of stopping and starting sab to get it to close those half-open connections ?

The ip_address: was that your own IP address?

No plugins? No sabconnect++ etc? No other progams than your plain webbrowser?


I think it is a bug in the web server framework ("cherrypy") that SAB uses. Maybe it is caused by faulty plugins / communciation, but IMHO a framework should protect itself against such probelms.
The CLOSE_WAIT stuff is pretty low level TCP stuff, and difficult to understand. I don't know cherrypy at all, so I can't help you much further there.

I don't experience the problem myself, but as a workaround you could write a crontab entry that checks the number of CLOSE_WAIT connections each hour. If that number is aboven 100 or 200, do a automatic service restart. That should clean things up.

Yes, ip_address is the ip address of the machine out on the internet on which I was using a web browser to display the sab webui. No plugins, nothing but a web browser.

BTW, if I stop and restart sab in the middle of a download, would that mess up the download?

Anyway, this is not a big thing to deal with. Hopefully the devs will have a look at this

[sander]

It's no problem at all to stop/start/restart in the middle of a download

#devs: as it is not reproducible, it is hard to investigate. I tried a lot of wget-commands, but that did not reproduce the problem. I tried to use some ugly socket-commands to SAB, but it could not get that program working correctly.

I don't know if cherrypy itself can see the CLOSE_WAIT connections. If so, maybe a cherrypy.engine.restart() could be a workaround for this problem. And even if so, I don't know how the devs think about such a workaround.

[shypike]

We will be moving to a new CherryPy release in 0.8.0, hopefully that will be more robust.

[hanker]

We will be moving to a new CherryPy release in 0.8.0, hopefully that will be more robust.

Ok - good enough. Thank you for your reply.