Mathervius

Members
  • Posts

    43
  • Joined

  • Last visited

Everything posted by Mathervius

  1. I ended up switching out my supermicro board for an old Intel DQ77MK board and have had 9+ days of uptime. I'm not sure what the issue is with the supermicro board and any UNRAID versions past 6.8.3 but it just made it unstable. If I stayed on 6.8.3 everything ran perfectly but I didn't want to be stuck on that version.
  2. Hi guys, I've been trying to capture this issue in my syslog and have been coming up empty. I am mirroring syslog to my flash drive but there doesn't seem to be anything noteworthy. What is strange was that on 6.8.3 this hardware would just run without issue. My uptime before updating the OS from 6.8.3 was ~200 days. This issue happened on the 6.9.* series as well but I thought maybe I'd get lucky with 6.10.0-RC1. Sometimes I will get crashes every day and then like this last one I had almost 4 days of uptime before a crash. Here is a bit of the syslog prior to the crash this morning: Sep 17 20:00:01 Tower root: Starting Mover Sep 17 20:00:01 Tower root: ionice -c 2 -n 0 nice -n 0 /usr/local/emhttp/plugins/ca.mover.tuning/age_mover start 1 0 0 '' '' '' '' no 70 '' '' Sep 17 20:00:01 Tower emhttpd: read SMART /dev/sdf Sep 17 20:10:20 Tower emhttpd: read SMART /dev/sdj Sep 17 20:12:59 Tower emhttpd: cmd: /usr/local/emhttp/plugins/dynamix/scripts/tail_log syslog Sep 17 20:15:01 Tower emhttpd: read SMART /dev/sdf Sep 17 20:23:34 Tower emhttpd: read SMART /dev/sdh Sep 17 20:30:01 Tower emhttpd: read SMART /dev/sdf Sep 17 20:30:01 Tower emhttpd: spinning down /dev/sdh Sep 17 20:33:39 Tower emhttpd: read SMART /dev/sdh Sep 17 20:34:21 Tower emhttpd: spinning down /dev/sdb Sep 17 20:34:22 Tower emhttpd: read SMART /dev/sdb Sep 17 20:45:01 Tower emhttpd: read SMART /dev/sdf Sep 17 20:45:02 Tower emhttpd: spinning down /dev/sdh Sep 17 20:45:03 Tower emhttpd: spinning down /dev/sdj Sep 17 20:49:36 Tower emhttpd: read SMART /dev/sdg Sep 17 20:50:18 Tower emhttpd: read SMART /dev/sdj Sep 17 21:00:02 Tower root: Starting Mover Sep 17 21:00:02 Tower root: ionice -c 2 -n 0 nice -n 0 /usr/local/emhttp/plugins/ca.mover.tuning/age_mover start 1 0 0 '' '' '' '' no 70 '' '' Sep 17 21:00:02 Tower emhttpd: spinning down /dev/sdg Sep 17 21:12:48 Tower emhttpd: read SMART /dev/sdg Sep 17 21:15:01 Tower emhttpd: spinning down /dev/sdg Sep 17 21:15:02 Tower emhttpd: spinning down /dev/sdj Sep 17 21:15:55 Tower emhttpd: read SMART /dev/sdg Sep 17 21:20:28 Tower emhttpd: read SMART /dev/sdh Sep 17 21:29:05 Tower emhttpd: read SMART /dev/sdj Sep 17 21:30:01 Tower emhttpd: spinning down /dev/sdh Sep 17 21:45:02 Tower emhttpd: spinning down /dev/sdj Sep 17 21:47:22 Tower emhttpd: read SMART /dev/sdj Sep 17 22:00:01 Tower root: Starting Mover Sep 17 22:00:01 Tower root: ionice -c 2 -n 0 nice -n 0 /usr/local/emhttp/plugins/ca.mover.tuning/age_mover start 1 0 0 '' '' '' '' no 70 '' '' Sep 17 22:00:01 Tower emhttpd: spinning down /dev/sdg Sep 17 22:15:01 Tower emhttpd: read SMART /dev/sdf Sep 17 22:15:03 Tower emhttpd: spinning down /dev/sdj Sep 17 22:22:23 Tower emhttpd: read SMART /dev/sdj Sep 17 22:30:01 Tower emhttpd: read SMART /dev/sdf Sep 17 22:31:36 Tower emhttpd: read SMART /dev/sdg Sep 17 22:33:46 Tower emhttpd: spinning down /dev/sdf Sep 17 22:33:46 Tower emhttpd: spinning down /dev/sdq Sep 17 22:45:01 Tower emhttpd: spinning down /dev/sdg Sep 17 22:46:02 Tower emhttpd: read SMART /dev/sdg Sep 17 22:53:58 Tower emhttpd: read SMART /dev/sdh Sep 17 23:00:01 Tower root: Starting Mover Sep 17 23:00:01 Tower root: ionice -c 2 -n 0 nice -n 0 /usr/local/emhttp/plugins/ca.mover.tuning/age_mover start 1 0 0 '' '' '' '' no 70 '' '' Sep 17 23:00:01 Tower emhttpd: spinning down /dev/sdg Sep 17 23:00:02 Tower emhttpd: spinning down /dev/sdh Sep 17 23:00:03 Tower emhttpd: spinning down /dev/sdj Sep 17 23:01:02 Tower emhttpd: read SMART /dev/sdg Sep 17 23:02:46 Tower emhttpd: read SMART /dev/sdf Sep 17 23:02:46 Tower emhttpd: read SMART /dev/sdq Sep 17 23:19:12 Tower emhttpd: read SMART /dev/sdj Sep 17 23:31:49 Tower emhttpd: read SMART /dev/sdh Sep 17 23:45:01 Tower emhttpd: spinning down /dev/sdg Sep 17 23:45:02 Tower emhttpd: read SMART /dev/sdg Sep 18 00:00:01 Tower Docker Auto Update: Community Applications Docker Autoupdate running Sep 18 00:00:01 Tower Docker Auto Update: Checking for available updates Sep 18 00:00:01 Tower root: Starting Mover Sep 18 00:00:01 Tower root: ionice -c 2 -n 0 nice -n 0 /usr/local/emhttp/plugins/ca.mover.tuning/age_mover start 1 0 0 '' '' '' '' no 70 '' '' Sep 18 00:00:02 Tower emhttpd: spinning down /dev/sdh Sep 18 00:00:02 Tower kernel: sd 7:0:7:0: [sdi] tag#1462 UNKNOWN(0x2003) Result: hostbyte=0x00 driverbyte=0x08 cmd_age=0s Sep 18 00:00:02 Tower kernel: sd 7:0:7:0: [sdi] tag#1462 Sense Key : 0x5 [current] Sep 18 00:00:02 Tower kernel: sd 7:0:7:0: [sdi] tag#1462 ASC=0x21 ASCQ=0x0 Sep 18 00:00:02 Tower kernel: sd 7:0:7:0: [sdi] tag#1462 CDB: opcode=0x42 42 00 00 00 00 00 00 00 18 00 Sep 18 00:00:02 Tower kernel: blk_update_request: critical target error, dev sdi, sector 976773104 op 0x3:(DISCARD) flags 0x800 phys_seg 1 prio class 0 Sep 18 00:00:08 Tower kernel: sd 7:0:3:0: [sde] tag#1579 UNKNOWN(0x2003) Result: hostbyte=0x00 driverbyte=0x08 cmd_age=0s Sep 18 00:00:08 Tower kernel: sd 7:0:3:0: [sde] tag#1579 Sense Key : 0x5 [current] Sep 18 00:00:08 Tower kernel: sd 7:0:3:0: [sde] tag#1579 ASC=0x21 ASCQ=0x0 Sep 18 00:00:08 Tower kernel: sd 7:0:3:0: [sde] tag#1579 CDB: opcode=0x42 42 00 00 00 00 00 00 00 18 00 Sep 18 00:00:08 Tower kernel: blk_update_request: critical target error, dev sde, sector 975896140 op 0x3:(DISCARD) flags 0x800 phys_seg 1 prio class 0 Sep 18 00:00:46 Tower kernel: sd 7:0:1:0: [sdc] tag#1286 UNKNOWN(0x2003) Result: hostbyte=0x00 driverbyte=0x08 cmd_age=0s Sep 18 00:00:46 Tower kernel: sd 7:0:1:0: [sdc] tag#1286 Sense Key : 0x5 [current] Sep 18 00:00:46 Tower kernel: sd 7:0:1:0: [sdc] tag#1286 ASC=0x21 ASCQ=0x0 Sep 18 00:00:46 Tower kernel: sd 7:0:1:0: [sdc] tag#1286 CDB: opcode=0x42 42 00 00 00 00 00 00 00 18 00 Sep 18 00:00:46 Tower kernel: blk_update_request: critical target error, dev sdc, sector 973078547 op 0x3:(DISCARD) flags 0x0 phys_seg 1 prio class 0 Sep 18 00:00:46 Tower kernel: BTRFS warning (device sdc1): failed to trim 1 device(s), last error -121 Sep 18 00:00:51 Tower sSMTP[22487]: Creating SSL connection to host Sep 18 00:00:51 Tower sSMTP[22487]: SSL connection using TLS_AES_256_GCM_SHA384 Sep 18 00:00:52 Tower sSMTP[22487]: Authorization failed (535 5.7.8 https://support.google.com/mail/?p=BadCredentials g141sm8008970pfb.128 - gsmtp) Sep 18 00:01:51 Tower Docker Auto Update: Stopping mariadb Sep 18 00:01:55 Tower kernel: veth44be009: renamed from eth0 Sep 18 00:01:55 Tower Docker Auto Update: Stopping swag Sep 18 00:01:59 Tower kernel: veth4c56537: renamed from eth0 Sep 18 00:01:59 Tower Docker Auto Update: Installing Updates for mariadb swag Sep 18 00:04:21 Tower Docker Auto Update: Restarting mariadb Sep 18 00:04:21 Tower kernel: eth0: renamed from vethabaf5de Sep 18 00:04:21 Tower Docker Auto Update: Restarting swag Sep 18 00:04:22 Tower kernel: eth0: renamed from vethe6bca19 Sep 18 00:04:22 Tower Docker Auto Update: Community Applications Docker Autoupdate finished Sep 18 00:04:41 Tower emhttpd: read SMART /dev/sdh Sep 18 00:15:01 Tower emhttpd: spinning down /dev/sdg Sep 18 00:15:02 Tower emhttpd: spinning down /dev/sdh Sep 18 00:24:57 Tower emhttpd: read SMART /dev/sdg Sep 18 00:25:40 Tower emhttpd: read SMART /dev/sdh Sep 18 00:30:01 Tower emhttpd: spinning down /dev/sdg Sep 18 00:30:02 Tower emhttpd: spinning down /dev/sdh Sep 18 00:31:26 Tower emhttpd: read SMART /dev/sdg Sep 18 00:45:01 Tower emhttpd: spinning down /dev/sdg Sep 18 01:00:01 Tower root: Starting Mover Sep 18 01:00:01 Tower root: ionice -c 2 -n 0 nice -n 0 /usr/local/emhttp/plugins/ca.mover.tuning/age_mover start 1 0 0 '' '' '' '' no 70 '' '' Sep 18 01:00:01 Tower emhttpd: read SMART /dev/sdf Sep 18 01:00:02 Tower emhttpd: spinning down /dev/sdj Sep 18 01:00:12 Tower emhttpd: read SMART /dev/sdg Sep 18 01:15:01 Tower emhttpd: spinning down /dev/sdg Sep 18 01:24:26 Tower emhttpd: read SMART /dev/sdg Sep 18 01:29:34 Tower emhttpd: spinning down /dev/sds Sep 18 01:30:01 Tower emhttpd: spinning down /dev/sdg Sep 18 01:35:49 Tower emhttpd: spinning down /dev/sdo So I don't see any kernel panics or anything. I know there is the trim error for the ssd but that happened with 6.8.3 as well. tower-diagnostics-20210918-1430.zip
  3. It's really strange behavior for my array. The disks would not spin down for ~3 days and then they did spin down for ~3 days. Now they are back to not spinning down again.
  4. I am not using a Marvel controller. My plugins: CA Auto Turbo Write Mode CA Auto Update Applications CA Backup / Restore Appdata CA Config Editor CA Mover Tuning Community Applications Custom Tab Dynamix Active Streams Dynamix Local Master Dynamix SSD TRIM Dynamix System Statistics Dynamix System Temperature Fix Common Problems GUI Links GUI Search Nerd Tools Network UPS Tools (NUT) Parity Check Tuning Recycle Bin Speedtest Command Line Tool Theme Engine Tips and Tweaks Unassigned Devices Unassigned Devices Plus User Scripts I uninstalled my CA Auto Turbo Write Mode plugin and it didn't seem to help. What's really strange is that today my drives have started spinning down again. The only change I made was to uninstall the CA Auto Turbo Write Mode plugin and then reinstalled it later.
  5. This is exactly what I posted about a few days ago. Same thing happening for me!
  6. I knew that, sorry about that... tower-diagnostics-20210830-1610.zip
  7. I've had good results with this release as compared to the 6.9.* releases which crashed my server quite a bit. Anyway, I have one issue and I'm not quite sure what's happening. My drives try to spin down after the designated time frame but as soon as they spin down they spin right back up. These are SATA drives. Here's an example in the logs: Aug 30 08:51:02 Tower emhttpd: spinning down /dev/sdr Aug 30 08:51:10 Tower emhttpd: spinning down /dev/sdp Aug 30 08:51:12 Tower emhttpd: read SMART /dev/sdp Aug 30 08:51:12 Tower emhttpd: read SMART /dev/sdr So as soon as they spin down it reads the SMART data and spins it back up. Is there anything I can do to help diagnose the issue? Could the CA Auto Turbo Write Mode plugin cause this behavior? It never was an issue in the past. EDIT: I removed the CA Auto Turbo Write Mode plugin and the behavior persists so I don't think it is the problem.
  8. I was finally able to get everything up and running! I added the dns rewrite to adguard home and it still wasn't working so I added a dns flag to the extra parameters of the invidious container pointing to my adguard home container and it's working well. --dns="192.168.20.1"
  9. I tried to setup this container today following the new instructions (it failed to work yesterday with the original instructions). Unfortunately, it still has the same error for me as yesterday. Both containers are on my bro.10 network with static IPs. config.yml db: user: kemal password: kemal host: 192.168.20.231 port: 5432 dbname: invidious error from invidious log from lib/db/src/db/database.cr:57:16 in '->' from /usr/share/crystal/src/primitives.cr:266:3 in 'build_resource' from lib/db/src/db/pool.cr:47:34 in 'initialize' from lib/db/src/db/pool.cr:40:5 in 'new:initial_pool_size:max_pool_size:max_idle_pool_size:checkout_timeout:retry_attempts:retry_delay' from lib/db/src/db/database.cr:56:15 in 'initialize' from lib/db/src/db/database.cr:49:5 in 'new' from lib/db/src/db.cr:155:5 in 'build_database' from lib/db/src/db.cr:119:5 in 'open' from /usr/share/crystal/src/kernel.cr:386:3 in '???' from src/invidious.cr:38:1 in '__crystal_main' from /usr/share/crystal/src/crystal/main.cr:110:5 in 'main_user_code' from /usr/share/crystal/src/crystal/main.cr:96:7 in 'main' from /usr/share/crystal/src/crystal/main.cr:119:3 in 'main' from src/env/__libc_start_main.c:94:2 in 'libc_start_main_stage2' Caused by: Cannot establish connection (PQ::ConnectionError) from lib/pg/src/pq/connection.cr:34:9 in 'initialize' from lib/pg/src/pq/connection.cr:19:5 in 'new' from lib/pg/src/pg/connection.cr:13:23 in 'initialize' from lib/pg/src/pg/connection.cr:7:5 in 'new' from lib/pg/src/pg/driver.cr:3:5 in 'build_connection' from lib/db/src/db/database.cr:57:16 in '->' from /usr/share/crystal/src/primitives.cr:266:3 in 'build_resource' from lib/db/src/db/pool.cr:47:34 in 'initialize' from lib/db/src/db/pool.cr:40:5 in 'new:initial_pool_size:max_pool_size:max_idle_pool_size:checkout_timeout:retry_attempts:retry_delay' from lib/db/src/db/database.cr:56:15 in 'initialize' from lib/db/src/db/database.cr:49:5 in 'new' from lib/db/src/db.cr:155:5 in 'build_database' from lib/db/src/db.cr:119:5 in 'open' from /usr/share/crystal/src/kernel.cr:386:3 in '???' from src/invidious.cr:38:1 in '__crystal_main' from /usr/share/crystal/src/crystal/main.cr:110:5 in 'main_user_code' from /usr/share/crystal/src/crystal/main.cr:96:7 in 'main' from /usr/share/crystal/src/crystal/main.cr:119:3 in 'main' from src/env/__libc_start_main.c:94:2 in 'libc_start_main_stage2' Caused by: Hostname lookup for postgres failed: No address found (Socket::Addrinfo::Error)
  10. Just throwing my hat in with the same problem. Syslog server hasn't been working properly for me so I can't attach logs. I rolled back to 6.8.3 for the time being. Before the update to 6.9.1 I had over 200 days of uptime but after updating I was getting daily crashes and my family uses the server too much for that to happen. I don't have any VMs, no GPU, just about 20 docker containers.
  11. I get the same issue everyday after my Auto Backup finishes and restarts Emby. I've posted on the Emby forums and got nowhere with it. What's strange is that it was gone for a while but the bug was reintroduced with an update a while back. I wish I had paid closed attention to when the error started up again
  12. Can you try to put in the containers IP rather than the container name and see if that makes a difference? Did set/change the ombi base URL? What errors show when you try to load ombi(500/401 etc...)? Did you remember to restart the letsencrypt container after making adjustments to conf files? Do any other containers work properly through the reverse proxy? Anything in firewall logs indicating an issue? Side note: it's a lot easier to lend a hand if you make your links actual links so people don't have to copy/paste everything to see what you're talking about. It might help you get more responses. Also make sure to read through the support thread for the actual container if it has one. Most have a dedicated thread.
  13. You should be able to assign a static IP to the container using an IP within your LAN subnet. I have a couple networks setup for my docker containers. One uses a VLAN (br1.10) and I manually set static IPs for those containers and then the containers on my LAN just get an IP assigned to them from the server but I could just as easily assign static IPs for them as well.
  14. While this is mostly true I recently did a complete new build and there was one pretty decent headache involving networking. I went from a quad port NIC (used as two bonded connections) to a dual port NIC. When I booted the server there was a mess involving my docker containers networking (they're a mix of VLAN/custom IPs/VPN) and also the MAC address was different so my static mapping from my router wasn't picking up the server properly. I ended up deleting my network config file and then rebooted into GUI mode and made my network adjustments. Everything works great now but it's definitely something to keep in mind.
  15. I think you could go either way but I prefer using the letsencrypt container for it.
  16. So in your conf file you have something like this: location / { include /config/nginx/proxy.conf; resolver 127.0.0.11 valid=30s; set $upstream_whatever <IP_ADDRESS>; proxy_pass http://$upstream_whatever:<PORT_NUMBER>; proxy_set_header Range $http_range; proxy_set_header If-Range $http_if_range; } You will use the containers IP address instead of its name. In your case you would use the VPN containers IP address and whatever port you use to access the service locally. Don't forget to enable some sort of security if you are exposing these services to the web. Most of the conf files have something like this that you can use to get basic http auth setup at least: # enable the next two lines for http auth #auth_basic "Restricted"; #auth_basic_user_file /config/nginx/.htpasswd;
  17. I've done this by just using the containers IP address/port in the letsencrypt conf file for each service.
  18. When I've had issues with community apps not loading in the past it was caused by a DNS issue on the network. Not sure if you've looked into that yet but sometimes I forget to check the simple stuff first.
  19. This will come down to firewall rules on your pfSense box. I was having a bunch of issues getting communication between VLAN/LAN and every time it came down to firewall rules. I would suggest posting or searching on the netgate forums as that's where I had the best luck,
  20. Are you using the latest version? I started getting a lot of failed downloads and servers not being able to connect errors with the latest version. I realized it was caused by them removing python 2 and my scripts were relying on it to run properly.
  21. @Merson I couldn't get FakeDetector or Completion working even with the 2to3 converter. Any tips if you are using these scripts? I loaded up Sab instead and I'm actually impressed with how well it works but I've always used nzbget in the past.
  22. Mine UNRAID box shows up in the left-side menu under "Locations".
  23. That has always worked for me. Are you able to connect through Finder (not using the connect to server function)?
  24. I went ahead and assigned br2 a static IP address. My hope was to add the br2 static IP to an Alias in pfSense and then use that to route that traffic through a VPN. Kind of like if the docker containers were using Host as their network and Host was being router through a VPN. Unfortunately, that plan does not do what I intended. It works fine but the dockers using br2 do not get router through the VPN as if they were on Host network. I've managed to just manually give IPs to each container and then add those IPs to the pfSense alias and it works fine. I'm not sure how some of this works but I thought with br2 on its own NIC that you could sort of replicate the Host network behavior on the docker containers.
  25. Shorter version: I currently have docker assigned to br2, which has its own NIC and I manually designate IP addresses to containers from the DHCP pool range I set in the docker settings page. If I change the network setting for br2 from IPv4 address assignment: None to IPv4 address assignment: Static will it mess up my current docker network which utilizes br2?