Mathervius
Members
-
Joined
-
Last visited
-
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
-
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"
-
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)
-
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.
-
I think you could go either way but I prefer using the letsencrypt container for it.
-
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;
-
I've done this by just using the containers IP address/port in the letsencrypt conf file for each service.
-
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.
-
@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.
-
Have you tried testing with iperf to see the speed between your two devices on your LAN? What OS are you transferring from? MacOS SMB over wifi has been slow for me since I was on High Sierrra. The other thing you might run into is the speed of the disks you are reading from/writing to. I've had much better luck running docker containers on the UNRAID box itself rather than using a separate box.
