dchamb

Spoke too soon. Up to 14,635 sync errors now

I was concerned after so many crashes under 6.9.2 with the uncorrected parity check starting automatically and never completing. When I rolled back to 6.8.3 it came up saying parity was valid. I ran a correcting parity check thinking I'd rather be safe than sorry and it reported 50 sync errors. I hope I haven't screwed something up.

Ok that makes sense. I had shutdown docker while running 6.9.2. That's when I first tried mover but the system eventually crashed. So if I can get mover to put these folders and files on the cache pool while docker is down, the cache pool will be opened and used by the docker apps once docker is reactivated? Will my CA backup use the cache pool as the source and make a copy of it back to the array backup folder?

Just for my clarification regarding the role of parity and the parity check: 1. I have 2 parity drives plus 4 data drives in my array. 2. All disks are functioning normally (no errors). 3. Running parity check so far has reported 50 sync errors corrected. When a sync error is detected and corrected, the only thing modified is the parity, not the data drives, correct? If a sync error is detected, there is no data loss provided my data drives are still fully intact, correct? Thanks Dale

tower-diagnostics-20211127-1421.ziptower-diagnostics-20211127-1510.zip I did find these logs for when I was running 6.9.2. I don't know if they will tell anything about why 6.9.2 was crashing since on the days they were grabbed the system had not crashed yet. But I did find a switch in the appdata backup that allows me to select which docker apps to shutdown during the backup. I am currently running a parity check while the backup is is running and my dockers are still running. Keeping fingers crossed!

Given that my backups are scheduled to start at 3AM daily and the diagnostics were taken around 3:25 PM suggests that the backup failed and did not restart the dockers upon failure. Since this happens only when the parity check is running (at the end of each month), and noting that the backup WILL shutdown the dockers before beginning, could the parity check have interfered with the the backup causing it to fail? If so, how can I set the backup to not start if a parity check is running?

I have encountered the same issue. Running 6.8.3 flawlessly for 462 days. I "upgraded" to 6.9.2 and almost immediately experienced system freezes, slow degradation in connectivity (i.e. webgui not responding, unable to connect via telnet), failure to shutdown the array or the system gracefully, and unable to get diagnostics. After a couple of days I rolled back to 6.8.3 and the system has been running great. So I know it isn't a hardware problem. Unfortunately, I can't get a diagnostic dump to help figure out the problems with 6.9.2. My signature has my hardware configuration listed if that helps. Dale

Just to be clear if I post Diagnostics it will be for version 6.8.3 because each time I tried under 6.9.2 it failed to complete.

I rolled back to 6.8.3 and I was able to do the steps you outlined. However, I don't think the mover did what it was supposed to do (see the attached screen print). Don't I need to change the pathnames in the Docker settings to point to the folder in the pool?

Update: I rolled back to 6.8.3. Everything except the cache drive came back. I restored the cache drive setting and I am now able to run mover to transfer some files to the array that never were moved under 6.9.2. I reenabled Dockers and all my docker containers came back and started. Plex is running again! I'd say at least for me 6.9.2 is a no-go.

Another problem: I cannot access any of my shares from the network. It shows the array is up and a parity check is running, but I have no access to any folders from my Windows PC.

Thanks but it seems that unRaid is crashing on me so it is constantly running parity checks. I was able to stop the Docker service, I had no VM services active, I set the appdata and system to Use Cache Pool: Prefer, then ran the mover. I don't see anything changing in the cache. I ran unRaid 6.8.3 for nearly 500 days straight with no issues. I updated to 6.9.2 and it's been a nightmare each day.

I'd like to roll back to 6.8.3. That was a stable OS version. This one is crashing on me. I can't get diagnostics to run, it invokes a non-correcting parity check which cannot be stopped. This 6.9.2 version is a disaster!

I have seen posts from others about the same problem I am experiencing, i.e. dockers shutdown during a parity check. It does look like there is an interaction between the appdata backup running at the same time as the parity check. Other posts suggest moving the docker.img to cache along with appdata but I'm not sure how to do that properly.

My parity check runs monthly at the end of the month. It runs for more than 24 hours due to the size of the array. I also have an appdata backup that runs each day around 2am. However, the only time the docker servers are stopped are monthly at the end of the month. Once the parity check completes, the dockers resume automatically.

That is correct. The containers restart after the parity check finishes. But I also have an appdata backup that runs during the time the parity check runs. My parity checks run a little more than 24 hours.

Is there a way to prevent my docker apps from being stopped during a parity check? All of them including Plex are in a stopped state every month when the parity check runs.

Thanks. I removed the orphan, went back a few hours later and Plex came back. Any insight as to the cause of why unRaid did not shutdown cleanly?

Thanks!

Update: I forced an update to the stopped Plex container and it allowed me to start the Plex docker. However, the Plex clients do not see the server, even though it shows started. I am using the linuxserver/plex container. In addition, there is an (orphan image) that is stopped. I am not sure if it is interfering in any way or what is the best way to remove it other than remove it. Here is the Plex log: [s6-init] making user provided files available at /var/run/s6/etc...exited 0. [s6-init] ensuring user provided files have correct perms...exited 0. [fix-attrs.d] applying ownership & permissions fixes... [fix-attrs.d] done. [cont-init.d] executing container initialization scripts... [cont-init.d] 01-envfile: executing... [cont-init.d] 01-envfile: exited 0. [cont-init.d] 10-adduser: executing... ------------------------------------- _ () | | ___ _ __ | | / __| | | / \ | | \__ \ | | | () | |_| |___/ |_| \__/ Brought to you by linuxserver.io ------------------------------------- To support LSIO projects visit: https://www.linuxserver.io/donate/ ------------------------------------- GID/UID ------------------------------------- User uid: 99 User gid: 100 ------------------------------------- [cont-init.d] 10-adduser: exited 0. [cont-init.d] 40-chown-files: executing... [cont-init.d] 40-chown-files: exited 0. [cont-init.d] 45-plex-claim: executing... [cont-init.d] 45-plex-claim: exited 0. [cont-init.d] 50-gid-video: executing... [cont-init.d] 50-gid-video: exited 0. [cont-init.d] 60-plex-update: executing... Atempting to upgrade to: 1.25.0.5246-cb2507e4d 2021-11-27 15:43:02 URL:https://downloads.plex.tv/plex-media-server-new/1.25.0.5246-cb2507e4d/debian/plexmediaserver_1.25.0.5246-cb2507e4d_amd64.deb [76591506/76591506] -> "/tmp/plexmediaserver_1.25.0.5246-cb2507e4d_amd64.deb" [1] (Reading database ... 10560 files and directories currently installed.) Preparing to unpack .../plexmediaserver_1.25.0.5246-cb2507e4d_amd64.deb ... PlexMediaServer install: Pre-installation Validation. PlexMediaServer install: Docker detected. Preinstallation validation not required. Unpacking plexmediaserver (1.25.0.5246-cb2507e4d) over (1.24.5.5173-8dcc73a59) ... Setting up plexmediaserver (1.25.0.5246-cb2507e4d) ... PlexMediaServer install: Docker detected. Postinstallation tasks not required. Continuing. [cont-init.d] 60-plex-update: exited 0. [cont-init.d] 90-custom-folders: executing... [cont-init.d] 90-custom-folders: exited 0. [cont-init.d] 99-custom-scripts: executing... [custom-init] no custom files found exiting... [cont-init.d] 99-custom-scripts: exited 0. [cont-init.d] done. [services.d] starting services Starting Plex Media Server. [services.d] done. Critical: libusb_init failed connect: Operation timed out

I upgraded to 6.9.2 recently after being up for 462 days 7 hours on 6.8.3. Initial impressions are that 6.8.3 was more stable. I just ran into a problem where my Plex docker seemed to be hung up (never had this problem before) and I tried to restart with clean shutdown with no success. I then tried shutting down the array and had no success with that either. Eventually I was forced to shutdown the system hard which caused a Parity Check to start. My Plex docker will not start and shows it is stopped. Any help will be most welcome! Dale tower-diagnostics-20211127-1421.zip

What should the Disk Settings be set to if you do not have VM Manager enabled?

I have the same issue. Whenever my monthly parity check starts or if I need to do a parity rebuild, all my docker apps are stopped automatically. As soon as the parity check/rebuild is complete, the docker apps are restarted automatically. I still have access to the array, just not the docker apps. Plex is one of them. My diagnositic logs are attached. Please note I took these logs during a parity rebuild. I had tried to start Plex from the Docker tab but it would not work. Dale tower-diagnostics-20211122-1525.zip

462 days 7 hours