jaso

Solved by rolling back t previous version, by changing the template entry for 'repository' from linuxserver/sickchill to linuxserver/sickchill:2024.3.1-ls192

Like the title says, sickchill won't start since the last sickchill update. I have updated Unraid from 6.12.9 to 6.12.10, but it still won't start. The following errors where appearing in my Unraid syslog, before and after the upgrade of Unraid. I have confirmed the errors are sourced from sickchill by starting and stopping each docker. The errors only appear when sickchill is started (and stop when sickchill is stopped): Apr 9 20:57:32 Tower kernel: traps: python3[11080] trap invalid opcode ip:15276047f14e sp:7ffc5821ba10 error:0 in etree.cpython-311-x86_64-linux-musl.so[15276044d000+32a000] Apr 9 20:57:34 Tower kernel: traps: python3[11220] trap invalid opcode ip:148d0ee7f14e sp:7ffd670c8300 error:0 in etree.cpython-311-x86_64-linux-musl.so[148d0ee4d000+32a000] Apr 9 20:57:38 Tower kernel: traps: python3[11325] trap invalid opcode ip:14c0dca7f14e sp:7ffec052d360 error:0 in etree.cpython-311-x86_64-linux-musl.so[14c0dca4d000+32a000] Apr 9 20:57:42 Tower kernel: traps: python3[11418] trap invalid opcode ip:146ccec7f14e sp:7ffdcacc9050 error:0 in etree.cpython-311-x86_64-linux-musl.so[146ccec4d000+32a000] Apr 9 20:57:45 Tower kernel: traps: python3[11550] trap invalid opcode ip:14d71687f14e sp:7ffe90072fc0 error:0 in etree.cpython-311-x86_64-linux-musl.so[14d71684d000+32a000] Apr 9 20:57:48 Tower kernel: traps: python3[11640] trap invalid opcode ip:14a154e7f14e sp:7fffe7b38550 error:0 in etree.cpython-311-x86_64-linux-musl.so[14a154e4d000+32a000] I have attached screenshots of: * unraid logs * sickchill docker settings * sickchill logs I am assuming it's probably some silly config setting I am neglecting, but I just can't figure it out. I would be great if someone can point me in the right direction. Cheers, Jaso

Just wanted to do two things: 1. A big thankyou to itimpi for the unRAIDFindDuplicates script. I have had a few copy/move errors over the last decade and itempi's script just found nearly 400GB of dupes scattered over my 42GB unraid array. 2. I banged together a little script that looks at the output of the itimpi's script, and deletes the dupes. Note that you must do a bit of cleaning of itimpi's output file first - delete everything except the file paths. That is, remove the lines at beginning of duplicates.txt that look like this: (also delete file size warnings, and the lines for files associated to the warnings) COMMAND USED: ./unRAIDFindDuplicates.sh Duplicate Files --------------- Here is my script - I called it 'delete-dupes.sh'. Execute it like this: bash ./delete-dupes.sh '/boot/duplicates.txt' #!/bin/bash # Check if the file exists if [ ! -f "$1" ]; then echo "File not found!" exit 1 fi # Read the file line by line while IFS= read -r line; do # Check if the line is empty if [ -n "$line" ]; then # Prepend "/mnt/user/" to the line path="/mnt/user/$line" # Delete the file path rm -v "$path" fi done < "$1" Be careful. If you execute the delete-dupes script twice in a row it will delete the remaining (now unique) files. I had thousands of files that were duplicated, without the script I would have been manually deleting duplicate files for weeks. Thanks again itempi!

Sickchill died for me recently after updating to latest docker version of sickchill via unraid docker screen "check for updates" button. I am on Unraid 6.9.1. Sickchill container ID: 46be26380d7a. I have restarted the sickchill docker a few times but no joy. Any ideas? Edit: I also tried editing the docker config to run sickchill in "Privileged" mode. Still no joy There are a few errors appearing when I view the logs: warnings.warn("urllib3 ({}) or chardet ({})/charset_normalizer ({}) doesn't match a supported " Checking poetry sickchill installed: True /usr/lib/python3.9/site-packages/requests/__init__.py:102: RequestsDependencyWarning: urllib3 (1.26.7) or chardet (5.0.0)/charset_normalizer (2.0.7) doesn't match a supported version! warnings.warn("urllib3 ({}) or chardet ({})/charset_normalizer ({}) doesn't match a supported " Traceback (most recent call last): File "/usr/bin/SickChill", line 8, in <module> sys.exit(main()) File "/usr/lib/python3.9/site-packages/SickChill.py", line 345, in main SickChill().start() File "/usr/lib/python3.9/site-packages/SickChill.py", line 90, in start settings.DATA_DIR = choose_data_dir(settings.PROG_DIR) File "/usr/lib/python3.9/site-packages/sickchill/helper/common.py", line 404, in choose_data_dir if location.joinpath(check).exists(): File "/usr/lib/python3.9/pathlib.py", line 1424, in exists self.stat() File "/usr/lib/python3.9/pathlib.py", line 1232, in stat return self._accessor.stat(self) PermissionError: [Errno 13] Permission denied: '/root/sickchill/sickbeard.db' EDIT 2: A new image of sickchill was released [Image ID: 357610432]. Pulled new image. Everything fixed.

Here's a snapshot of my unRaid network settings. Is your's different?:

My understanding of the root cause is that <something> is impeding your unraid from getting packets to/from servers that host the docker images/updates. That something could be mis-configuration of routes, your ISP playing silly-buggers, lots of things. To take your ISP out of the equation (at least a little bit) you could change the DNS settings from the ISP's default to something like google DNS: IPv4 DNS server: 8.8.8.8 IPv4 DNS server 2: 8.8.4.4 Or, OpenDNS: IPv4 DNS server: 208.67.222.222 IPv4 DNS server 2: 208.67.220.22 You can make this change just for unraid: Settings > Network settings > IPv4 DNS server and IPv4 DNS server 2 Alternatively, you can update your DNS servers at the router and make the change to your entire household network. When I had the same issue that you are facing I found that option C from previous post, in combination with using OpenDNS as my DNS servers (on both router and unraid) fixed my problem. Good luck If this doesn't work, I'd suggest the following to narrow down the root cause: Shut down *everything* else in your network and try again with just unraid and router. Log on to unraid local UI and see if you can get it to update docker images. If still no good I'd build a second unraid box for testing purposes to see if it can host a docker image and get updates. If the second unraid works AOK you are looking at FUBAR config somewhere in your original unraid... HTH, Jaso

Regarding the router troubleshooting. When you say 'reset my router' - did you: a) turn the router off and on again b) reset the router back to factory settings c) reset the router back to factory settings AND update to latest router firmware I found that c) was what worked for me. There is one other thing to try, but if you can confirm the above questions we can go from there. Cheers, Jaso

My router was not playing nice. Not exactly sure what I did to make it fail, but a firmware upgrade to latest and a factory reset did the trick. Everything AOK now.

Solved. My router was not playing nice. Not exactly sure what I did to make it fail, but a firmware upgrade to latest and a factory reset did the trick.

So it get's even weirder - I checked Settings --> Fix Common Problems and got this: Maybe I just need to reset my router. Maybe back to factory condition and set it up again. Sigh. (Note that I am not seeing any symptoms of misbehaving router on 30+ other devices on the network)

ooh. I am getting this too (just posted here). Now that you mention it started just after i updated community apps. Mmm suspicious. I wonder if it's a weird combination of apps/dockers/plugins/configs not playing nicely?

Hi everyone, I am getting this error whenever I check for docker updates: Jun 22 20:52:37 Tower nginx: 2020/06/22 20:52:37 [error] 8724#8724: *3066436 upstream timed out (110: Connection timed out) while reading response header from upstream, client: 10.10.0.12, server: , request: "POST /plugins/dynamix.docker.manager/include/DockerUpdate.php HTTP/1.1", upstream: "fastcgi://unix:/var/run/php5-fpm.sock", host: "10.10.0.3", referrer: "http://10.10.0.3/Docker" It stays in "checking" for ages, then reverts to orange text "not available" P.S. I am also getting a weird error in the "transmission VPN" docker. Do you think these could be related? (It dumps the connection after one minute, tries to reconnect, dumps connection after one minute). I haven't changed any configs for docker overall or the transmission_VPN docker. Mon Jun 22 16:47:43 2020 [UNDEF] Inactivity timeout (--ping-exit), exiting Both errors started at the same time. A few days ago. Kind Regards, Jason

Yep - it seems to have been a cabling issue. I recall moving the box around when I was diagnosing the raid card fault. After checking each sata cable and power cable and turning it back on (and being super gentle sliding the box back into place) everything was AOK.

I've got the diags zip from before I shut it down and after I turned it on again. I've also uploaded an image of a notification I got saying "Array turned good". It seems that the array is pretty happy with itself...but I haven't had the balls to actually start the array yet - maintenance mode or normal. Cheers, Jaso tower-diagnostics-20200607-1502 BEFORE.zip tower-diagnostics-20200607-2215 AFTER REBOOT.zip

@johnnie.black I've attached the syslog. Do you need any of the other diag files? Cheers - much appreciated. syslog.2.txt