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.
Behavior:
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-
Rebooted
-Same result-
dietpi-software reinstall 139
reboot
-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!
Hi,
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 127.0.0.1:32401 (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 127.0.0.1:41843 (LISTEN)
Plex\x20T 11694 plex 13u IPv4 62415 0t0 TCP 127.0.0.1:32600 (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 127.0.0.1:43161 (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/SABnzbd.py -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/filesystem.py", line 598, in create_all_dirs
os.mkdir(path_part_combined)
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 
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.
