Hello All - I have verified that for the last three months (though issue has been happening for quite awhile) when my monthly parity check finishes all my docker applications enter a stopped state.  I looked in the log file to see what is up, but I do not see the parity check being written in the log.

It has a monthly schedule now I have seen instances of the CA App BU stopping docker but that is not happening here as I tested that with a daily BU and all is well there.

 

As to the log for the parity check, is it written elsewhere or just not at all?

 

Thanks...

A parity check does not even know about dockers so it will not be that stopping them but something else.

 

for anyone to be able to give any sort of sensible suggestions as to why this is happening to you then you will need to provide your system’s diagnostics with the logs in them covering a period when this happens.

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

On 11/22/2021 at 4:35 PM, dchamb said:

I had tried to start Plex from the Docker tab but it would not work.

What happened?

 

Plex was stopped automatically due to the backup happening, but the backup did not finish at the time of your grabbing the diagnostics.  

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?

 

 

16 hours ago, dchamb said:

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?

The two actions are independent of each other, although a parity check running will degrade array performance which may make the backup take longer than normal.

Any thoughts on preventing the backup from starting if a parity check is running?

2 minutes ago, dchamb said:

Any thoughts on preventing the backup from starting if a parity check is running?

Schedule them so they avoid each other.

Thanks but I am not finessed enough in Cron to know how to say "run every day at 3am except on the last day of month"

Maybe something less complicated that would be just as good. You can change both schedules, so you aren't limited to only making backup complicated.

 

http://corntab.com/

 

Or just forget about it and restart the containers when it happens.

Simply set it so there are no possible overlap.

 

For example, I set my appdata backup on Wednesdays and my parity checks for one Thursday's a month (the parity check scheduling allows that).

Do you feel a daily backup is unnecessary? 

1 hour ago, dchamb said:

Do you feel a daily backup is unnecessary? 

How much appdata will you loose if you have to go back one week ?

For me, that is not that big an issue.

 

Plex will re-scan a few show or movies; I'll loose a few play status.

I might also loose one week of server statistics but I can live with it.

 

I can't make that decision for your use case obviously.

Thanks for your thoughts.  It helps to have a someone else's perspective.  I have a tendency to go overboard lol!

Original poster here - all I know is I did not run parity check this month and the docker crash did not happen. Will start one manually on 12-10 and see what happens, will post logs.