Can't start SABnzbd [Debian-OMV]

[chillerkiller]

Hello,

hopefully someone can help me. I installed SABnzbd a couple of weeks ago. Everything worked really fine. Today i started my N40L with OMV it didn't run. So i opened Putty and tried to start it manually.
When i try to open the SABnzbd. py file I get the following:

Code: Select all

    2013-01-10 00:00:44,249::INFO::[SABnzbd:1256] --------------------------------
    2013-01-10 00:00:44,249::INFO::[SABnzbd:1257] SABnzbd.py-0.7.9 (rev=c237ddfef464649ec3713d43c441def6c8656f46)
    2013-01-10 00:00:44,250::INFO::[SABnzbd:1269] Platform = posix
    2013-01-10 00:00:44,250::INFO::[SABnzbd:1270] Python-version = 2.6.6 (r266:84292, Dec 27 2010, 00:02:40)
    [GCC 4.4.5]
    2013-01-10 00:00:44,250::INFO::[SABnzbd:1271] Arguments = ./SABnzbd.py
    2013-01-10 00:00:44,251::INFO::[SABnzbd:1284] Read INI file /SABnzbd/sabnzbd.ini
    2013-01-10 00:00:44,252::INFO::[__init__:928] Loading data for bookmarks.sab from /SABnzbd/admin/bookmarks.sab
    2013-01-10 00:00:44,252::INFO::[__init__:931] /SABnzbd/admin/bookmarks.sab missing, trying old cache
    2013-01-10 00:00:44,253::INFO::[__init__:934] /SABnzbd/cache/bookmarks.sab missing
    2013-01-10 00:00:44,253::INFO::[__init__:928] Loading data for rss_data.sab from /SABnzbd/admin/rss_data.sab
    2013-01-10 00:00:44,254::INFO::[__init__:931] /SABnzbd/admin/rss_data.sab missing, trying old cache
    2013-01-10 00:00:44,254::INFO::[__init__:934] /SABnzbd/cache/rss_data.sab missing
    2013-01-10 00:00:44,254::INFO::[__init__:928] Loading data for totals9.sab from /SABnzbd/admin/totals9.sab
    2013-01-10 00:00:44,255::INFO::[__init__:931] /SABnzbd/admin/totals9.sab missing, trying old cache
    2013-01-10 00:00:44,255::INFO::[__init__:934] /SABnzbd/cache/totals9.sab missing
    -bash: Zeile 6:  2794 Speicherzugriffsfehler

Can someone help me? I guess it is something wrong with Python. But don't know what???

[shypike]

Bug in Python or just bad memory (or not enough of it).
Speicherzugriffsfehler means memory error, doesn't it?

[chillerkiller]

I deinstalled Python with apt-get remove python and installed it again without success.
I have my Debian on an USB-Stick with 4GB. Could that be the problem?

Speicherzugriffsfehler means segmentation fault or no memory access.

Thanks for your help.

[shypike]

To be honest, I have no idea.
Resident Linux gurus, any bright ideas?

[jcfp]

Best guess: a problem with the python binary or hardware failure. Run a memtest (from the bootloader or live-cd)? This type of problem is unlikely to be caused by sab.

[kbunny]

I am no guru, but I think I have the same issue on my Synology107 (still going strong, yet slow) with 0.7.9 on Python2.5. I'm seeing the same logmessages you posted, however, I also see :

Code: Select all

2013-01-14 22:44:45,687::INFO::[__init__:928] Loading data for totals9.sab from /volume1/opt/share/SABnzbd/admin/totals9.sab
2013-01-14 22:44:45,690::INFO::[__init__:931] /volume1/opt/share/SABnzbd/admin/totals9.sab missing, trying old cache
2013-01-14 22:44:45,695::INFO::[__init__:934] /volume1/public/download/temp/totals9.sab missing

after the rss-stuff.

To help pinpoint the problem, I modified a few files, most importantly database.py (I'll just post the relevant bit in class HistoryDB, function __init__ ):

Code: Select all

        if sabnzbd.WIN32 and isinstance(db_path, str):
            self.con = sqlite3.connect(db_path.decode('latin-1').encode('utf-8'))
        else:
            logging.debug('Setting up connection to %s', db_path)
            self.con = sqlite3.connect(db_path)
        logging.debug('Connected')

Now i'm seeing (ignore the path, that's just my local setup):

Code: Select all

2013-01-14 22:44:45,712::DEBUG::[database:84] __init__ called with path /volume1/opt/share/SABnzbd/admin/history1.db
2013-01-14 22:44:45,715::DEBUG::[database:92] Setting up connection to /volume1/opt/share/SABnzbd/admin/history1.db

No more lines (so no "Connected"), no response on the web interface, I have to use kill to end the process.
This suggest to me that the sqlite3 connect fails somehow. I've checked file permissions and even made the history1.db file -rw-rw-rw-.
The code should auto-create the DB, so I tried removing the file, but it just creates a 0-byte file and won't connect.

I'm not 100% sure your issue is identical, but you might try to insert the above logging-lines to confirm. Delete the cached database.pyo before you run sabnzbd, or python will just use the binary pyo instead of your modified code.
I'm kinda stuck at this point, but perhaps somebody else might know a bit about sqlite connect issues?

[kbunny]

Downgrading to python2.5 SABnzbd 0.5.6 (from ipkg) cleared this up, though I wonder what's so different between 0.5.6 and 0.7.9 - er... db-wise I mean, I've seen that the sabnzbd code has seen massive cleanup as well as new features ;-)

In the meantime I've tried to install Sickbeard, which is also a python application and seems to use sqlite3 as well. I couldn't get this to run either, so I went ahead and added some debug logging to console at strategic points and whaddya know: the job just kinda freezes on sqlite3.connect

So, it really seems to be sqlite3. But what I don't really understand: SABnzbd 0.5.6 uses sqlite3 as well. It has a fallback to something called pysqlite2, but I've confirmed that the sqlite3 import succeeds. I am aware that my aging synology107+ has limited memory, but there does seem to be enough mem free.
I'll try and look into the version of python that SABnzbd 0.5.6 and 0.7.9, and the lastest Sickbeard from GitHub are using on my NAS, perhaps that can explain why 0.5.6 does not, but 0.7.9 does proceed past sqlite3.connect.
In the meantime, if the above rings a bell for anyone, please share your insights.

[shypike]

Are you using a ready-made package for the NAS?
Be aware that we do not create those and don't what the package creator bundles in such a package.
The only thing we deliver are the plain Python files and the web interfaces.
Additional Python libraries (possibly also sqlite3), par2, unzip, unrar are all supplied by the package creator.
Some even patch our sources to get them running.