unRAID has been so stable for me lately, I haven't really noticed when this started happening, but I think it's been in the last point release or so (currently running 6.2.4).

 

It seems when I update a container, or even just stop it, that there's a long webui lag of 30+ seconds.  When it finally becomes responsive again, most (but not all) of my disks go from an idle state to spun up.  This most recent time happened with Plex (linuxserver), but it happens any time I update any of my containers as well.

 

Any thoughts on what I can do to troubleshoot this?  Nothing in the syslog at all.

 

Thanks!

Where is your docker.img?

if your dockers are on cache, I am having similar problem since 6.2.3.

 

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

Also keep in mind that many docker apps (eg: plex & cp) have options to rescan their libraries upon starting / updating which will indeed cause drives to spin up.

 

And since docker attempts to gracefully exit a running container before forcibly killing it, the exit routine of the container might be causing the spin ups on stopping the container.

 

Thanks for all the replies.

 

Where is your docker.img?

/mnt/cache/.docker/docker.img

 

if your dockers are on cache, I am having similar problem since 6.2.3.

 

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

Yep. That's me as well. As I mentioned before, it started happening a few point releases ago. Never an issue before. All data exists on the cache.

 

If this were just related to Plex, I'd understand why all (most) my drives are spinning up, but since this will happen when I restart or stop any of my containers, I feel like it might be related to some change to the underlying Docker handling?

 

Also keep in mind that many docker apps (eg: plex & cp) have options to rescan their libraries upon starting / updating which will indeed cause drives to spin up.

 

And since docker attempts to gracefully exit a running container before forcibly killing it, the exit routine of the container might be causing the spin ups on stopping the container.

I might need to test this again, but weeks ago when I first started investigating, it seemed that there was little rhyme or reason which of my disks would not spin up. There were always like 2 or 3 that would stay spun down, some which even share user shares with others that are spun up. Strange for sure!

 

Not sure then if there's anything I can do then.

Had some Docker container updates today, so I thought I'd try to nail down what containers experience the webgui hang, then spin up the drives. I think I have some good observations that someone may find helpful to aid in troubleshooting.

 

First container I updated was an already shut down sabnzbd Docker. It updated without issue.

 

Next container was a running NZBGet container. It seemed hung at the "Stopping container" portion.  After about a minute, I got "Error: Error code" and the update completed as expected. No entries in the syslog except 9 entries about port 4 entering a disabled or forwarding state, and a couple about promiscuous mode. This in turn spun up 11 of 14 drives (including parity), none with temperature being reported. But I finally realized what drives don't spin up: the 3 that are formatted xfs. What would be the reason for this?

 

All other containers updated virtually instantly and without any webgui hang.

reiserfs will spin up disks if there is a 'sync' executed somewhere.

 

For these kinds of problems please post diagnostics: webGui/Tools/Diagnostics

reiserfs will spin up disks if there is a 'sync' executed somewhere.

 

For these kinds of problems please post diagnostics: webGui/Tools/Diagnostics

 

In my original thread

 

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