tiphae

That's what I've been trying to investigate, with the memtest and replacing the PSU. I'm just not sure what to check next. If it was the cache ssd I'd think that would just go unavaiable; not sure if the appdata ssd would cause a reboot. GPU is used for transcoding only, not sure if that could cause it. Maybe a CPU but not sure how to test, etc.

A week ago I noticed my server was randomly rebooting itself. The first time I noticed it rebooted twice in a row (noticed the two post beep sequences). I thought maybe memory so ran memtest for ~4 days, and no issues. Kept happening, so I replaced the power supply. Initially after replacing the PSU it wouldn't make it into unraid, but when I came back to it about an hour later it got all the way in and then crashed as soon as I started docker engine. After that, docker engine and dockers seem to start and run alright while I continued to troubleshoot. Since then it's rebooted 1-3 times daily. Looking for some help figuring out what's going on. Diagnostics and syslog attached, the last known crash/reboot in the syslog file is apx. 8/18/21 @ 1945. Thanks in advance ! syslog tower-diagnostics-20210818-2031.zip

Yeah the same thing happened to me on 6.9.1, and I'd read in some similar posts folks resolving it by going to 6.9.2 - but it didn't resolve for me. The Nvidia driver drama prevents me from going back to 6.8.x sadly.

Since upgrading to 6.9.2 shortly after stable release I've had continuous disk spin-ups for SMART reads. I do not have Telegraf/Grafana or the like installed, have tried uninstalling different plugins, leaving dockers stopped, etc. and cannot seem to pin it down. Jul 17 18:00:51 Tower emhttpd: spinning down /dev/sdo Jul 17 18:00:53 Tower emhttpd: spinning down /dev/sdm Jul 17 18:00:53 Tower emhttpd: spinning down /dev/sdj Jul 17 18:00:53 Tower emhttpd: spinning down /dev/sdk Jul 17 18:00:53 Tower emhttpd: spinning down /dev/sdg Jul 17 18:00:53 Tower emhttpd: spinning down /dev/sdd Jul 17 18:00:53 Tower emhttpd: spinning down /dev/sde Jul 17 18:00:53 Tower emhttpd: spinning down /dev/sdf Jul 17 18:00:53 Tower emhttpd: spinning down /dev/sdc Jul 17 18:00:53 Tower emhttpd: spinning down /dev/sdl Jul 17 18:01:52 Tower emhttpd: spinning down /dev/sdi Jul 17 18:01:52 Tower emhttpd: spinning down /dev/sdp Jul 17 18:20:28 Tower emhttpd: spinning down /dev/sdq

Same errors as above, proxy sites worked late yesterday but after an overnight update getting the following (example) and no sites reachable: nginx: [emerg] "proxy_redirect" directive is duplicate in /config/nginx/proxy-confs/freshrss.subdomain.conf:38

Since upgrading to 6.9.1 all of my HDD spin up for a SMART read every 15 min. (some events pasted below), then spin back down. Some older google results led me to setting the disk spin down delay to be longer than the poll time (1 hour delay and 3700 second poll time), but that hasn't helped. Another recent thread [ here ] marked as closed, but I'm not running any of those dockers. I'm hoping for some additional troubleshooting advice. Mar 15 06:47:39 Tower emhttpd: read SMART /dev/sdd Mar 15 06:47:50 Tower emhttpd: read SMART /dev/sdn Mar 15 06:48:01 Tower emhttpd: read SMART /dev/sdc Mar 15 06:48:12 Tower emhttpd: read SMART /dev/sdo Mar 15 07:15:34 Tower emhttpd: read SMART /dev/sdm Mar 15 07:17:40 Tower emhttpd: spinning down /dev/sdd Mar 15 07:17:52 Tower emhttpd: spinning down /dev/sdn Mar 15 07:18:13 Tower emhttpd: spinning down /dev/sdo Mar 15 07:18:15 Tower emhttpd: spinning down /dev/sdc Mar 15 07:19:02 Tower emhttpd: read SMART /dev/sdc Mar 15 07:49:07 Tower emhttpd: spinning down /dev/sdc Mar 15 08:03:21 Tower emhttpd: read SMART /dev/sdg Mar 15 08:03:33 Tower emhttpd: read SMART /dev/sdc Mar 15 08:03:43 Tower emhttpd: read SMART /dev/sdo Mar 15 08:03:54 Tower emhttpd: read SMART /dev/sdk Mar 15 08:04:03 Tower emhttpd: read SMART /dev/sde Mar 15 08:04:27 Tower emhttpd: read SMART /dev/sdq Mar 15 08:04:42 Tower emhttpd: read SMART /dev/sdj Mar 15 08:04:52 Tower emhttpd: read SMART /dev/sdn Mar 15 08:05:03 Tower emhttpd: read SMART /dev/sdi Mar 15 08:05:43 Tower emhttpd: read SMART /dev/sdb

I have some other dockers using the binhex-rtorrentvpn docker for VPN, and cannot access their UIs. My workflow had been to add a port variable to the binhex docker with the UI port of the other docker (following a SpaceInvader video I think). Summarizing Q25 from the FAQ, add ports to 'ADDITIONAL_PORTS' env var value for the VPN container," should I delete all those port entries? I have also updated this docker, but don't see the ADDITIONAL_PORTS env variable - just add it? edit: Just adding the variable worked. Also had to go into each docker and change config from IP to localhost (Q24).

I'm having the same issue as above - linuxserver NZBGet and NZBHydra2 UIs are no longer reachable through VPN by IP:PORT as per SpaceInvader's tutorial (had been working for.. years). Linuxserver Radarr and Sonarr are fine and reachable through bridge/Letsencrypt reverse proxy, and both say that NZBGet and Hydra2 are reachable. Changing to bridge network type allows accessing UIs again. This morning both Radarr and Sonarr said they couldn't reach either NZBGet or Hydra2, which went away after an unrelated reboot. I see no errors in either the application or Unraid logs. edit: figured it out, I use binhex-rtorrentvpn docker for VPN access, and the docker recently tweaked how access is granted (Had to add a new variable of ports and change docker configs to use localhost rather than IP).

Hoping for some help with the docker image in Unraid - it was running fine for the longest time, but I went to check something recently and couldn't access the tautulli page. Checking the Unraid docker logs, I see the following: I haven't changed anything recently, and a reinstall didn't help. Thanks in advance!