Temporary "Restart Server after Crash" Software-Solution - Windows

[exter]

Hey guys,

I love sabnzbd, however as I'm using RC3 it crashes from time to time. Since I don't want to tinker with my registry in order to start some sort of service, I've looked around for other tools that restart crashed software automatically.

I found "Application Monitor" by JockerSoft and so far it works like a charm.

Basically you can set the intervall when App Monitor is supposed to check wether software is still running. (Mine's set at 30 seconds)

So yeah, google for it.

Best regards,
exter

p.s. even works with Win 7 64bit

[shypike]

In what way does it crash?

[exter]

Well it crashes.. randomly afaik.. no more process in the taskmanager...
Cache and queue are preserved though..

Version: 0.5.0 RC3
OS: Windows 7 Pro 64 bit
Install-type: Windows Installer
Skin (if applicable): Plush
Firewall Software: Win 7 64 bit Firewall
Are you using IPV6? no
Is the issue reproducible? not that I know of...

[shypike]

Does the SABnzbd log file say anything worthwhile?
What are the last 20 lines after it "crashes"?

[exter]

Unfortunately I don't have a log of the last crash (yesterday) as the logfiles and their backups seem to cover only an hour each.
However, the last time I checked the log after a crash I wasn't able to find anything...

I'll post the log after the next crash.

[exter]

Code: Select all

2010-02-03 20:47:39,621::DEBUG::[articlecache:144] cache_size -> 0
2010-02-03 20:47:39,621::INFO::[__init__:643] Saving data for SABnzbd_article_fe20_l in C:\Users\xxx\AppData\Local\sabnzbd\cache\SABnzbd_article_fe20_l
2010-02-03 20:47:39,663::INFO::[downloader:745] Thread [email protected]:443: BODY [email protected]
2010-02-03 20:47:39,717::INFO::[downloader:671] Thread [email protected]:443: [email protected] done
2010-02-03 20:47:39,719::INFO::[decoder:92] Decoding <Article: [email protected], bytes=398605, partnum=40, art_id=None>
2010-02-03 20:47:39,729::INFO::[articlecache:143] Flushing <Article: [email protected], bytes=398605, partnum=40, art_id=SABnzbd_article_kutk9w> to disk
2010-02-03 20:47:39,730::DEBUG::[articlecache:144] cache_size -> 0
2010-02-03 20:47:39,730::INFO::[__init__:643] Saving data for SABnzbd_article_kutk9w in C:\Users\xxx\AppData\Local\sabnzbd\cache\SABnzbd_article_kutk9w
2010-02-03 20:47:39,772::INFO::[downloader:745] Thread [email protected]:443: BODY [email protected]
2010-02-03 20:48:01,102::INFO::[sabnzbd:942] --------------------------------
2010-02-03 20:48:01,102::INFO::[sabnzbd:943] SABnzbd.exe-0.5.0RC3 (rev=3240)
2010-02-03 20:48:01,806::INFO::[sabnzbd:951] Platform=Windows-Vista-6.1.7600 (=Vista+ x64) Class=nt
2010-02-03 20:48:01,808::INFO::[sabnzbd:954] Python-version = 2.5.4 (r254:67916, Jan 29 2009, 12:02:11) [MSC v.1310 32 bit (Intel)]

[shypike]

Weird.
It looks like it just stops.
There's 20 sec between the last logging and the new signon.
Are you sure there isn't some other program that stops SABnzbd for some reason.
Your tool isn't jumping to conclusions?

Parts of SABnzbd may hangup, but an altogether abort I have never seen.

Is the program folder of SABnzbd writable?
Is there a file called sabnzbd.exe.log in that folder?
What's in it?

[remarks]

Version: 0.5.0 RC3
OS: Windows 7 Pro 64 bit
Install-type: Windows Installer
Skin (if applicable): Plush
Firewall Software: Win 7 64 bit Firewall
Are you using IPV6? no
Is the issue reproducible? not that I know of...

I have the same problem too.

Running Win 7 32bit though.

Windows logs show the following entry:

Code: Select all

Faulting application name: SABnzbd.exe, version: 0.0.0.0, time stamp: 0x4917df95
Faulting module name: libeay32.dll, version: 0.9.8.7, time stamp: 0x471caf4a
Exception code: 0xc0000005

The service crashes at least once a day.  I have a fairly clean OS (fresh install recently) and pretty much only run it is a media PC so not a lot of software.

I have had this problem with the last two RCs.

[shypike]

Right, this is an old "friend", the SSL library libeay32.dll.
We've had problems with this one before.
Should have been solved by including the "correct" one in SABnzbd.

I'll look further into this.
I never had the crash myself, but then I never run SABnzbd for 24h on my Win7 system.
My Windows Home Server runs it for weeks without any glitch.

I'll get in touch with you and may ask you to try different SSL dll-s.

BTW: we are including the same DLLs since Beta1.

[exter]

After looking into the Windows log (damn.. should've thought of that earlier) I can confirm, that I get the same exact error message.

BTW: we are including the same DLLs since Beta1."

Again srry, for not checking the Windows logs earlier.. as you could see the sabnzb log didn't show anaything weird..

Next I checked the sabnzbd program folder: it was write-protected.

Furthermore I found a sabnzbd.exe - textfile which was roughly 321 mb large. It contained the same thing over and over:

Code: Select all

Traceback (most recent call last):
  File "logging\handlers.pyo", line 74, in emit
  File "logging\handlers.pyo", line 131, in doRollover
WindowsError: [Error 32] Der Prozess kann nicht auf die Datei zugreifen, da sie von einem anderen Prozess verwendet wird (="Process cannot access file as it is being used by another process")
Traceback (most recent call last):
  File "logging\handlers.pyo", line 73, in emit
  File "logging\handlers.pyo", line 147, in shouldRollover
ValueError: I/O operation on closed file

I kept the file.. but renamed it to sabnzbd.exe.bak, furthermore I got rid of the write-protection.

[shypike]

I know what to look for now.
SABnzbd is now very robust itself and is very hard to truly crash.
However, we have no defense against errors in the language runtime system
and external DLLs like those of OpenSSL.

[exter]

So.. is there anything we can do to help?

[shypike]

Not much for now.
The only way we can upgrade the OpenSSL dll-s is by basing the Windows binary on Python 2.6.
The reason is that more recent DLLs will crash SABnzbd at startup (when using https).
Updating Python is not something we will do just before the final release of 0.5.0.

However as soon as 0.5.0 is out, a 0.5.1Beta1 will follow that will be based on Python 2.6.