Sabnzbd web interface unresponsive since upgrade to v6.33.3

I’m not sure if this is related but I believe it to be the only thing that’s changed on my system. Did have a power outtage though!

I first noticed this maybe a day after upgrading to DietPi 6.33.3 and then some hours later a power outtage for a few seconds. After some time I checked services to ensure everything was up and running correctly.

Radarr/Sonarr Etc indicate “All download clients are unavailable due to failures” (Went in to the download configuration did a test to test the api and it worked, and clears the red error flag)

Tried to open Sabnzbd web page http://dietpi:8080/ No luck. Browser just spins for what seems like an eternity before timing out.

Attempted Remedies:
Restarted all services. (Sabnzbd service is starting)
-Same result-
-Same result-
dietpi-software reinstall 139
-Same result-

Before I do an uninstall and re-install and then have to reconfigure Sabnzbd hoping for some pointers or guidance to logs that might give me additional hints to what is wrong.

Thank you!


many thanks for your message. You could check if the service is running. Next to this, you could have a look to logs

systemctl status sabnzbd.service
cat /var/log/sabnzbd/sabnzbd.log

Thanks for the speedy reply.

The service is running.
There are strangely no log files in var/log/sabnzbd No files at all actually. The directory is there.

I have also retested the connection to Sab from Sonarr/lidarr/radarr and it is now failing in all three. Not sure why it worked previously in my original post but apologies if that caused confusion.

The service is running but it can’t seem to be connected to from those clients or the web. When connecting from chrome on another machine(local network) I get “ERR_CONNECTION_REFUSED”

When I try from firefox on dietpi I get “Firefox can’t establish a connection to the server at localhost:8080”

Time to uninstall then install from scratch again you think?

I do have a backup pre 6.33.3 but I’m still not 100% sold that the upgrade is whats broke it. May have been the power outage some how.

usually there should be a log file. The folder has correct permissions ?
As well you can check if your application os LISTEN to correct port

lsof -i -P -n | grep LISTEN

might be that lsof is missing. If yes, just install using apt install lsof

lsof - awesome. Thank you for showing me that. Very useful info there.

The service is running. I verified permissions on the directory and restarted the service and it’s running, but no log file. Here is the output from lsof. - There is NO item for port 8080 and NO listing for sabnzbd!? I’m assuming there should be an entry, i’m wondering how there isn’t one if there was previously now. How do I add it back?

root@DietPi:~# lsof -i -P -n | grep LISTEN
mono        325  www-data    5u  IPv4  13234      0t0  TCP *:8084 (LISTEN)
dropbear    559      root    3u  IPv4  14738      0t0  TCP *:22 (LISTEN)
dropbear    559      root    4u  IPv6  14739      0t0  TCP *:22 (LISTEN)
Xvnc-core   665      root    0u  IPv6  15640      0t0  TCP *:6001 (LISTEN)
Xvnc-core   665      root    1u  IPv4  15641      0t0  TCP *:6001 (LISTEN)
Xvnc-core   665      root    6u  IPv6  15653      0t0  TCP *:5901 (LISTEN)
Xvnc-core   665      root    7u  IPv4  15654      0t0  TCP *:5901 (LISTEN)
smbd      11481      root   29u  IPv6  63943      0t0  TCP *:445 (LISTEN)
smbd      11481      root   30u  IPv6  63944      0t0  TCP *:139 (LISTEN)
smbd      11481      root   31u  IPv4  63945      0t0  TCP *:445 (LISTEN)
smbd      11481      root   32u  IPv4  63946      0t0  TCP *:139 (LISTEN)
librespot 11497 raspotify   18u  IPv4  63307      0t0  TCP *:41981 (LISTEN)
Plex\x20M 11510      plex   60u  IPv6  64214      0t0  TCP *:32400 (LISTEN)
Plex\x20M 11510      plex   61u  IPv4  64216      0t0  TCP (LISTEN)
mono      11542    sonarr   10u  IPv4  65902      0t0  TCP *:8989 (LISTEN)
mono      11552    radarr    7u  IPv4  62438      0t0  TCP *:7878 (LISTEN)
mono      11563    lidarr    4u  IPv4  66582      0t0  TCP *:8686 (LISTEN)
vhusbd    11591      root    4u  IPv4  64889      0t0  TCP *:7575 (LISTEN)
Plex\x20S 11612      plex    8u  IPv4  62378      0t0  TCP (LISTEN)
Plex\x20T 11694      plex   13u  IPv4  62415      0t0  TCP (LISTEN)
Plex\x20D 11695      plex   14u  IPv4  64941      0t0  TCP *:1466 (LISTEN)
Plex\x20D 11695      plex   20u  IPv4  64948      0t0  TCP *:32469 (LISTEN)
Plex\x20S 16137      plex    4u  IPv4  83422      0t0  TCP (LISTEN)

yeah you would need a line like this

python3  1500  sabnzbd    5u  IPv4  19483      0t0  TCP *:8080 (LISTEN)

But this is nothing you could add. lsof is displaying the available applications only. Means sabnzbd is not running, dosn’t matter what the service is telling your. Can you check if a process is running?

ps -ef | grep sabnzbd

Process is running.

sabnzbd  17176     1  1 12:54 ?        00:00:44 /usr/bin/python3 -OO /etc/sabnzbd/ -b 0 -f /etc/sabnzbd/sabnzbd.ini
root     21721 21692  0 14:09 pts/1    00:00:00 grep sabnzbd

Ok and seeing that, I went to etc/sabnzbd/log/sabnzbd.log

OSError: [Errno 19] No such device: '/mnt/shortterm/download'
2020-10-19 11:49:39,006::ERROR::[filesystem:313] Cannot create directory /mnt/shortterm/download/incomplete
2020-10-19 11:52:39,503::ERROR::[filesystem:496] Cannot change permissions of /mnt/shortterm/download/incomplete
2020-10-19 11:58:40,505::ERROR::[filesystem:604] Failed making (/mnt/shortterm/download/incomplete)
Traceback (most recent call last):
  File "/etc/sabnzbd/sabnzbd/", line 598, in create_all_dirs

After seeing this “/mnt/shortterm/” is a 2TB USB sata drive that I use for processing downloads with SAB. When I go to see if I can access it I see this:

The directory/drive that was mounted here as “shortterm” now shows up as a file with “inode/x-corrupted type” in the description

So perhaps my drive became corrupted during the power outtage. Is there a way to do a repair and check on the drive? Or maybe just unmount and remount it?

I’m not worried about data loss. The drive was temporary(shortterm) storage but I may have mistakenly set this path to do be where the SAB log files were kept. That would explain why none were found in var/log.

Appreciate all your assistance!

yes if you configured log on different storage :slight_smile:

You could try to unmount and mount your drive again. Maybe it will be recognised. As well you could perform a file system check

fsck -a /dev/sdXX

sdXX would need to be replaced with your device name.

Or you are going to change directory configuration in /etc/sabnzbd/sabnzbd.ini to point to a different location.

Just thought I’d give you the resolution on this one.

Changing the paths in the .ini worked for about 2 seconds. Becuase the drive was corrupted anytime it was trying to read anything from /mnt it would stall trying to read from the corrupted drive. When I figured out how to identify the drive I did the repair, and gave it a reboot for good measure and it’s all working appropriately now on the new path.

After the repair the drive is empty. So I’ll need to setup my directory structure and access again, but that’s pretty simple.

Thanks for your help, the problem was indeed the power outtage corrupting a drive, NOTHING TO DO WITH V6.33.3.