unRAID Server Version 6.2.3 Available


limetech

Recommended Posts

  • Replies 67
  • Created
  • Last Reply

Top Posters In This Topic

I just updated and when I try to update MariaDB and Plex, I get this error:

 

Error: layers from manifest don't match image configuration

 

I'm going to stop the dockers and restart them to see what that does.

So I pulled the Docker Migrator, ran the command, stopped Docker, restarted Docker, and still get the same error when I try to update my containers.  What am i missing (and sorry for the noobness, this is a learning experience for me).

 

Greg

See the docker FAQ for directions on what to do with regards to that error

Link to comment

I see what you mean about updating a container shouldn't need to spin up all your drives.

 

Where's your appdata at?

 

Could it be something to do with appdata in /mnt/user/

 

You'd only need one or two rogue files on the array in /mnt/user/appdata/plex and that might spin up your array.  Just thinking out loud here.

 

share setting:  appdata Use cache disk: Only

 

docker settings: /config <->  /mnt/cache/appdata/plex/

 

This is a docker plex install several years old now. The array behavior started when I added Parity 2. Never happened before that. And that is the only material change to my server.

Try:

1) Stop Docker service

2) Change your appdata user shares' Use cache disk to 'prefer'

3) run the Movers

4) Start Docker service and see if Plex update still spins up all disks

 

This worked. I did all these (mover didn't have anything to move tho lol). Restarted docker and all except Plex showed updated available. Restarted Plex, no array shenanigans this time. Ran PlexPy update container, again no array spin up.

 

Please explain if you have the time. Curious minds want to know. :)

 

Hate bring this up again but it is still doing the "wake up array when making edit to docker or restarting it". With the recent Roku issue with Plex I have had to change the Version variable several times and each time the array is accessed one disk at a time.

Link to comment

Have you checked whether any of your system or appdata shares' files exist *anywhere* on your array? Or if any folders exist on the array? Perhaps it really is down to either share being "Prefer" rather than "Cache only", combined with the Turbo Writes feature, causing the entire array to be spun up every time Docker is restarted.

Link to comment

Hate bring this up again but it is still doing the "wake up array when making edit to docker or restarting it". With the recent Roku issue with Plex I have had to change the Version variable several times and each time the array is accessed one disk at a time.

You've also reported this with 6.2.4, with the implication that it's something wrong with unRAID.  The thing is, as far as I have seen so far, you are the only one with the issue.  While it's certainly possible that there's a system defect that's only being triggered by something about your system, it seems to me that there's a high probability that it's more likely to be something wrong in your system - perhaps a still undetected write to the array, and therefore that seems where we should concentrate first.  If as suggested above you have Turbo Write enabled (reconstruct write), then ANY write to ANY drive in the array will cause ALL array drives to spin up.  I would check that first, see if md_write_method is set to 'reconstruct write' or 'read/modify/write'.  Then I would look for anything changed recently that may be responsible for a write to the array.  Perhaps you have recently added a new script or plugin, or changed a configured path in a container?

Link to comment

Hate bring this up again but it is still doing the "wake up array when making edit to docker or restarting it". With the recent Roku issue with Plex I have had to change the Version variable several times and each time the array is accessed one disk at a time.

You've also reported this with 6.2.4, with the implication that it's something wrong with unRAID.  The thing is, as far as I have seen so far, you are the only one with the issue.  While it's certainly possible that there's a system defect that's only being triggered by something about your system, it seems to me that there's a high probability that it's more likely to be something wrong in your system - perhaps a still undetected write to the array, and therefore that seems where we should concentrate first.  If as suggested above you have Turbo Write enabled (reconstruct write), then ANY write to ANY drive in the array will cause ALL array drives to spin up.  I would check that first, see if md_write_method is set to 'reconstruct write' or 'read/modify/write'.  Then I would look for anything changed recently that may be responsible for a write to the array.  Perhaps you have recently added a new script or plugin, or changed a configured path in a container?

 

Tunable (md_write_method): auto

 

Is there a way to start with no plugins running but still have dockers? If not I will need to uninstall them all and try it then. Then add them back one by one.

 

Link to comment

Hate bring this up again but it is still doing the "wake up array when making edit to docker or restarting it". With the recent Roku issue with Plex I have had to change the Version variable several times and each time the array is accessed one disk at a time.

You've also reported this with 6.2.4, with the implication that it's something wrong with unRAID.  The thing is, as far as I have seen so far, you are the only one with the issue.  While it's certainly possible that there's a system defect that's only being triggered by something about your system, it seems to me that there's a high probability that it's more likely to be something wrong in your system - perhaps a still undetected write to the array, and therefore that seems where we should concentrate first.  If as suggested above you have Turbo Write enabled (reconstruct write), then ANY write to ANY drive in the array will cause ALL array drives to spin up.  I would check that first, see if md_write_method is set to 'reconstruct write' or 'read/modify/write'.  Then I would look for anything changed recently that may be responsible for a write to the array.  Perhaps you have recently added a new script or plugin, or changed a configured path in a container?

 

Tunable (md_write_method): auto

That means Turbo Write is off, so it's not an issue with a single write to the array.  On a stock system, the only thing that causes writes to all array disks is array start and array stop.  So we have to assume it's reads not writes causing spin ups.  That means something is scanning all drives.

 

One possible cause is CacheDirs, if something has flushed the directory entries out of RAM.  How much RAM do you have?  Any possibility it's almost all used?  Have you provided your diagnostics somewhere?

 

Is there a way to start with no plugins running but still have dockers? If not I will need to uninstall them all and try it then. Then add them back one by one.

 

Put it in unRAID Safe Mode, from the boot menu.  If you're running headless, then you have to edit syslinux.cfg (click the flash drive on the Main page) and move the 'menu default' line to the Safe Mode menu section.

Link to comment

Hate bring this up again but it is still doing the "wake up array when making edit to docker or restarting it". With the recent Roku issue with Plex I have had to change the Version variable several times and each time the array is accessed one disk at a time.

You've also reported this with 6.2.4, with the implication that it's something wrong with unRAID.  The thing is, as far as I have seen so far, you are the only one with the issue.  While it's certainly possible that there's a system defect that's only being triggered by something about your system, it seems to me that there's a high probability that it's more likely to be something wrong in your system - perhaps a still undetected write to the array, and therefore that seems where we should concentrate first.  If as suggested above you have Turbo Write enabled (reconstruct write), then ANY write to ANY drive in the array will cause ALL array drives to spin up.  I would check that first, see if md_write_method is set to 'reconstruct write' or 'read/modify/write'.  Then I would look for anything changed recently that may be responsible for a write to the array.  Perhaps you have recently added a new script or plugin, or changed a configured path in a container?

 

Tunable (md_write_method): auto

That means Turbo Write is off, so it's not an issue with a single write to the array.  On a stock system, the only thing that causes writes to all array disks is array start and array stop.  So we have to assume it's reads not writes causing spin ups.  That means something is scanning all drives.

 

One possible cause is CacheDirs, if something has flushed the directory entries out of RAM.  How much RAM do you have?  Any possibility it's almost all used?  Have you provided your diagnostics somewhere?

 

Is there a way to start with no plugins running but still have dockers? If not I will need to uninstall them all and try it then. Then add them back one by one.

 

Put it in unRAID Safe Mode, from the boot menu.  If you're running headless, then you have to edit syslinux.cfg (click the flash drive on the Main page) and move the 'menu default' line to the Safe Mode menu section.

 

original post with diags

http://lime-technology.com/forum/index.php?topic=53340.msg512657#msg512657

 

I do have CacheDirs. I have 16 GB of RAM. Never had this issue before 6.2.3 so I don't think it is that.

 

Will try Safe Mode later.

 

here is new diags export. The timing for the issue was last night roughly 9PM my time. I don't see anything in syslog.

tower-diagnostics-20161110-0806.zip

Link to comment

This started with this version. Everything is on cache. I have triple checked five times.

 

Sent from my Nexus 5X using Tapatalk

 

So this "wake up array when making edit to docker or restarting it" behavior started on 6.2.4 right? If so this makes a lot of sense. Previous versions of unRAID killed docker apps instead of waiting them to gracefully exit. My 2 cents is now that apps are given time to shutdown/restart properly, some of them are reading/writing to disks previous to their exit, causing disks to spin up.

Link to comment

This started with this version. Everything is on cache. I have triple checked five times.

 

Sent from my Nexus 5X using Tapatalk

 

So this "wake up array when making edit to docker or restarting it" behavior started on 6.2.4 right?

 

6.2.3

 

Another data point is that Plex & PlexPy are the only dockers exhibiting this behavior. My other 2 dockers MySQL & tt-rss dockers do not. Its all in previous posts in this thread. :)

 

Link to comment

This started with this version. Everything is on cache. I have triple checked five times.

 

Sent from my Nexus 5X using Tapatalk

 

So this "wake up array when making edit to docker or restarting it" behavior started on 6.2.4 right?

 

6.2.3

 

Another data point is that Plex & PlexPy are the only dockers exhibiting this behavior. My other 2 dockers MySQL & tt-rss dockers do not. Its all in previous posts in this thread. :)

6.2.3 is when the graceful container stop for Docker was introduced.  Gfjardim might be on to something...

Link to comment

here is new diags export. The timing for the issue was last night roughly 9PM my time. I don't see anything in syslog.

At almost 9pm, all of your array drives except Disk 3 spun down, with no indication they spun back up.  Disk 3 spun down an hour and a half later.  What is particularly noteworthy is that there are no further spin downs within that next hour or two.  In other words, if unRAID had been aware of the drives spinning up, then it would have spun them down after their spin down delay.  It didn't.  I suspect that there were no drive temps on the Main page, except Disk 3.  How sure are you the drives are spinning up, apart from the drive lights flashing?

 

You can detect whether a drive is actually spinning by using the following command ->  hdparm -C /dev/sdX  (replace X with the correct letter for the drive).  If it says 'active/idle', it's spinning, otherwise it should say 'standby' (from memory, may be slightly off).

Link to comment

here is new diags export. The timing for the issue was last night roughly 9PM my time. I don't see anything in syslog.

At almost 9pm, all of your array drives except Disk 3 spun down, with no indication they spun back up.  Disk 3 spun down an hour and a half later.  What is particularly noteworthy is that there are no further spin downs within that next hour or two.  In other words, if unRAID had been aware of the drives spinning up, then it would have spun them down after their spin down delay.  It didn't.  I suspect that there were no drive temps on the Main page, except Disk 3.  How sure are you the drives are spinning up, apart from the drive lights flashing?

 

You can detect whether a drive is actually spinning by using the following command ->  hdparm -C /dev/sdX  (replace X with the correct letter for the drive).  If it says 'active/idle', it's spinning, otherwise it should say 'standby' (from memory, may be slightly off).

I have 3x 5in3 drive cages. Each drive has its own activity LED. The main case LED only lights up for cache activity. What I see is first the pair of parity drives light up together, then each drive in the array one by one lights up. I want to say they went in succession (d1, d2, d3, etc) but can't be sure.

 

Link to comment

here is new diags export. The timing for the issue was last night roughly 9PM my time. I don't see anything in syslog.

At almost 9pm, all of your array drives except Disk 3 spun down, with no indication they spun back up.  Disk 3 spun down an hour and a half later.  What is particularly noteworthy is that there are no further spin downs within that next hour or two.  In other words, if unRAID had been aware of the drives spinning up, then it would have spun them down after their spin down delay.  It didn't.  I suspect that there were no drive temps on the Main page, except Disk 3.  How sure are you the drives are spinning up, apart from the drive lights flashing?

 

You can detect whether a drive is actually spinning by using the following command ->  hdparm -C /dev/sdX  (replace X with the correct letter for the drive).  If it says 'active/idle', it's spinning, otherwise it should say 'standby' (from memory, may be slightly off).

I have 3x 5in3 drive cages. Each drive has its own activity LED. The main case LED only lights up for cache activity. What I see is first the pair of parity drives light up together, then each drive in the array one by one lights up. I want to say they went in succession (d1, d2, d3, etc) but can't be sure.

 

PS. one more data point... if I have restarted the docker and had the wake array behaviour, subsequent restarts will NOT cause the behaviour if preformed within that session (like trying to guess a past Plex version number for roll back but keep getting 404 when it tries to retrieve it). Whether that is due to spin status or what I don't know.

Link to comment

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Restore formatting

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.