Sabnzbd locking up after a period of time under win7 64bit

[Maxtastic]

Hello all,

I have been running Sabnzbd for a rather long time without issue under an old install of 32bit Win XP. I recently (about a month now) rebuilt that box and upgraded to 64bit Win 7 to handle more ram for various tasks.

Since doing so, Sabnzbd will launch and run fine, but after a day or so it becomes unresponsive. I need to kill the process and restart to get control of the service again.

I have found the different threads with suggestions but nothing has worked so far. I have disabled the 64bit tools and also increased my refresh time up to 5 minutes, but its still happening.

1. Anyone experience the same issue and find the root cause?
2. is there a way to enable logging for Sabnzbd to possibly see what the last actions are that are causing the process to lock up?

[shypike]

What you report is rather rare, but non completely unheard of.
The usual suspects are third-party programs that hammer the API.
There may be bugs too, but so far we've never been able to reproduce the behaviour.
Only using the "Classic" skin with a very large queue or history is known to have issues.

One "work-around" is to run SABnzbd as a Windows service.
The setup is a bit complicated, but when running as a service,
SABnzbd runs an additional watchdog service that will automatically
reset it when it becomes unresponsive.
More info: http://wiki.sabnzbd.org/sabnzbd-as-a-windows-service

As for diagnostics, you probably won't find info in SABnzbd's own log
(but you can try).
However, check for events in Windows own event logger.

[Maxtastic]

thanks for the info!

I will set it as a service and see how that goes.

I do run Sickbeard along with sab, and I thought maybe that was a cause of the issue. I killed Sickbeard for a few days but the issue was still occurring.

[Maxtastic]

ok that was honestly rather simple to setup, its running as a service now.

I will update this thread on how that works out.

again, thanks for your help!

[Maxtastic]

Unfortunately the problem is still here.

One thing that does happen since sabnzbd is running as a service, I can see that when it locks up, the service is still running. Since that happens, the helper service does not restart sabnzbd.

Is there anyway to enable logging to see what is hanging the process?

[shypike]

If it hangs up in the runtime libraries, then maybe you can see something in the Windows event log.
Nothing interesting in SABnzbd's own log files?

One alternative (albeit a very crude one) is to put a restart event in SABnzbd's scheduler.
Just make the interval lower than the time that SABnzbd does keep working.
If you want to restart multiple times per day, you need to enter multiple events.

[Vdub]

I noticed the SABnzbd web interface got very/totally unresponsive from time to time. I changed the web browser from Firefox to Chrome and the problem disappeared completely. Maybe worth a try in case you are a Firefox user.

[shypike]

I noticed the SABnzbd web interface got very/totally unresponsive from time to time. I changed the web browser from Firefox to Chrome and the problem disappeared completely. Maybe worth a try in case you are a Firefox user.

I use Firefox all the time for SABnzbd development, never had this.

[Vdub]

I noticed the SABnzbd web interface got very/totally unresponsive from time to time. I changed the web browser from Firefox to Chrome and the problem disappeared completely. Maybe worth a try in case you are a Firefox user.

I use Firefox all the time for SABnzbd development, never had this.

I find it strange as well. I first experienced this issue with Firefox on "PC 1" and changed to Chrome = problem resolved. Today, "PC 2" that previously had no issues with the web interface and Firefox got slow/unresponsive. I changed to Chrome = problem resolved.

I used Firefox for a couple of years before I suddenly got these problems (started ~8 months back). Never had issues before...

[Maxtastic]

when I was running WinXP I had no problems with Sabnzbd and Firefox, but I am still using Firefox under Win7.

Ill switch over to chrome and see if that makes a difference.

maybe its a Firefox + Win7 64bit issue?

Thanks for the suggestion.

[shypike]

I use Firefox on Win7-64bit.
However, it seems that Firefox user profiles can get corrupted too.
Mine shows odd behavior (unrelated to SABnzbd) which it doesn't have on
other Win7-64bit systems.
I will soon start with a new profile, maybe you should do the same?

[Maxtastic]

ill try with a new profile as well.

if this does not work, my next step was to disable HTTPS and see if that makes a difference. For those that are running successfully under Win7 64bit, are you using SSL or not?

[shypike]

I use https too.
Although my SABnzbd tends to run during short periods, development...
My "production" system runs on Linux, which gives me twice the
performance compared to Windows on the old Atom netbook I use.
That one sometimes runs for weeks.

[Maxtastic]

I use https too.
Although my SABnzbd tends to run during short periods, development...
My "production" system runs on Linux, which gives me twice the
performance compared to Windows on the old Atom netbook I use.
That one sometimes runs for weeks.

hmm.. maybe its time to setup a dedicated sabnzbd box running linux

[sander]

I'm joining this thread a bit late, but isn't this the known problem with plugins (like Sabconnect++) keeping a lot of (HTTPS) connections open, resulting in SAB's webinterface not responding anymore?

"meten is weten", so check the open connections to port 8080 and 9090 (change accordingly if you use different ports)
on Linux, use

Code: Select all

netstat -apon | grep -e 8080 -e 9090

on Windows, use

Code: Select all

netstat -aon | find "8080"
netstat -aon | find "9090"

If you get tens/hundreds of sessions to SABnzbd, that's the reason SAB's webinterface is not responding anymore. Workarounds to try:
- turn off HTTPS; the problems seem to occur with HTTPS, not HTTP
- find the plugin / application that is hammering SAB, as Shypike said earlier.


Example output of normal situations on Linux and Windows:

Code: Select all

sander@R540:~$ netstat -apon | grep -e 8080 -e 9090
(Not all processes could be identified, non-owned process info
 will not be shown, you would have to be root to see it all.)
tcp        0      0 0.0.0.0:8080            0.0.0.0:*               LISTEN      22978/python     off (0.00/0/0)
tcp        0      0 127.0.0.1:8080          127.0.0.1:51841         TIME_WAIT   -                timewait (17.02/0/0)
tcp        0      0 127.0.0.1:51846         127.0.0.1:8080          ESTABLISHED 32264/chromium-brow keepalive (44.07/0/0)
tcp        0      0 127.0.0.1:8080          127.0.0.1:51840         TIME_WAIT   -                timewait (17.02/0/0)
tcp        0      0 127.0.0.1:8080          127.0.0.1:51846         ESTABLISHED 22978/python     off (0.00/0/0)
tcp        0      0 127.0.0.1:8080          127.0.0.1:51847         ESTABLISHED 22978/python     off (0.00/0/0)
tcp        0      0 127.0.0.1:51847         127.0.0.1:8080          ESTABLISHED 32264/chromium-brow keepalive (44.07/0/0)
sander@R540:~$

Code: Select all

C:\>netstat -aon | find "8080"
  TCP    [::]:8080              [::]:0                 LISTENING       580
  TCP    [::1]:8080             [::1]:49821            TIME_WAIT       0
  TCP    [::1]:8080             [::1]:49822            TIME_WAIT       0
  TCP    [::1]:8080             [::1]:49823            TIME_WAIT       0
  TCP    [::1]:8080             [::1]:49824            TIME_WAIT       0
  TCP    [::1]:8080             [::1]:49825            TIME_WAIT       0
  TCP    [::1]:8080             [::1]:49826            TIME_WAIT       0
  TCP    [::1]:8080             [::1]:49834            TIME_WAIT       0
  TCP    [::1]:8080             [::1]:49835            TIME_WAIT       0
  TCP    [::1]:8080             [::1]:49844            TIME_WAIT       0
  TCP    [::1]:8080             [::1]:49845            TIME_WAIT       0

C:\>netstat -aon | find "9090"

C:\>