yukonhijack Posted November 6, 2016 Share Posted November 6, 2016 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 Quote Link to comment
Squid Posted November 6, 2016 Share Posted November 6, 2016 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 Quote Link to comment
yukonhijack Posted November 6, 2016 Share Posted November 6, 2016 Thanks. Went in and deleted the Docker image, reinstalled all my containers, and it is fixed. I appreciate the help! Quote Link to comment
ufopinball Posted November 6, 2016 Share Posted November 6, 2016 Upgraded from 6.2.2 to 6.2.3, no problems. Parity sync completed in 33117sec, which is slightly faster than the 6.2.0 run of 35531sec. Now I see 6.2.4 is out, so I guess that's next on the list... Quote Link to comment
interwebtech Posted November 10, 2016 Share Posted November 10, 2016 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. Quote Link to comment
kode54 Posted November 10, 2016 Share Posted November 10, 2016 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. Quote Link to comment
interwebtech Posted November 10, 2016 Share Posted November 10, 2016 This started with this version. Everything is on cache. I have triple checked five times. Sent from my Nexus 5X using Tapatalk Quote Link to comment
RobJ Posted November 10, 2016 Share Posted November 10, 2016 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? Quote Link to comment
interwebtech Posted November 10, 2016 Share Posted November 10, 2016 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. Quote Link to comment
RobJ Posted November 10, 2016 Share Posted November 10, 2016 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. Quote Link to comment
interwebtech Posted November 10, 2016 Share Posted November 10, 2016 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 Quote Link to comment
gfjardim Posted November 10, 2016 Share Posted November 10, 2016 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. Quote Link to comment
interwebtech Posted November 10, 2016 Share Posted November 10, 2016 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. Quote Link to comment
eschultz Posted November 10, 2016 Share Posted November 10, 2016 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... Quote Link to comment
RobJ Posted November 10, 2016 Share Posted November 10, 2016 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). Quote Link to comment
interwebtech Posted November 10, 2016 Share Posted November 10, 2016 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. Quote Link to comment
interwebtech Posted November 10, 2016 Share Posted November 10, 2016 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. Quote Link to comment
Recommended Posts
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.