Hello,

 

I stopped docker to increase it's alloted vdisk size as I noticed it was filling up a bit yeasteday before I cleanred out some logs. I shut down all the docker containers and disabled docker. I increased it's disk size setting and restarted docker. However the docker page would not load and whne I checked the logs it said  "docker.img is in-use, cannot mount". I decided I was going to try a clean restart to free up whatever was locking the file (I tried lsof and fuser on the docker image file and got no hits). The mover was running so I couldn't stop the array so I ran `mover stop` and then I could stop the array. However now it is complaining that my cache pool where appdata goes is busy and it won't stop the array:

 

Oct  1 17:10:05 HaynesTower emhttpd: shcmd (1537): umount /mnt/cache-apps
Oct  1 17:10:05 HaynesTower root: umount: /mnt/cache-apps: target is busy.
Oct  1 17:10:05 HaynesTower emhttpd: shcmd (1537): exit status: 32

 

Maybe the same thing that was locking the docker.img file? I tried to dump diagnostics but now all I'm seeing is a gray screen. However it looks like a file was created on my flash drive:
haynestower-diagnostics-20231001-1706.zip

 

Not sure if I should do a dirty bounce at this point or if there is a way around /mnt/cache-apps being busy and hanging the shutdown. What a mess.

Thanks!

Edited October 1, 20232 yr by manofoz

This command got rid of the target is busy messages:
 

fuser -kmv /mnt/cache-apps

 

That seemed to do the trick but some a few odd things happened. My VM doesn't have my array mounted and Windows acted like it was installed for the first time. It also wanted to run a Parity check when it came back up which was not normal. 

 

I also deleted the docker.img thinking that was holding things up but it seems easy enough to restore those from previoulsly downloaded apps. 

Everything I’ve checked seems to be running at the level it was before the server freaked out. Was pretty scary being unable to stop the array and reboot the server, would love some insight on what could have gone wrong so I can prevent this from happening again.
 

I was able to get the VM to re-mount /mnt/user by rebooting. Still no idea why a parity check started when the system back back online.