[6.6.0-rc4] Docker Containers Being Randomly Deleted

Start with upgrading to Unraid version 6.6.5 and retest.

Changed Status to Retest

Great, I didn't realize that this newer version was available. I've upgraded and everything looks okay now (after having reinstalled those two docker containers). I'll update if anything changes.

So, I spoke too soon. This evening I saw that LetsEncrypt had an update available, so I clicked "update container" in the docker menu. This process stalled without completing while "removing the image" and I eventually had to reload a new docker page and delete the orphaned image. I then went to the Community Apps section in order to install LetsEncrypt again only to find that it stalls halfway through the install at around the "Pulling fs layer" part of the process. However, I opened a dashboard page and found that the container did finish installing (though the original page never showed the install completing). But, strangely enough, the container show's as having an available update... I'm not installing this update, so as to avoid chasing my own tail, but I suspect that it would lead to the same situation described above. 

 

Here is the (seemingly) relevant log section:

Nov 21 00:52:09 vulfTower nginx: 2018/11/21 00:52:09 [error] 12502#12502: *89462 upstream timed out (110: Connection timed out) while reading upstream, client: 192.168.1.1, server: , request: "POST /Apps/UpdateContainer?xmlTemplate=user:/boot/config/plugins/dockerMan/templates-user/my-letsencrypt.xml HTTP/1.1", upstream: "fastcgi://unix:/var/run/php5-fpm.sock:", host: "192.168.1.107", referrer: "http://192.168.1.107/Apps/UpdateContainer?xmlTemplate=user:/boot/config/plugins/dockerMan/templates-user/my-letsencrypt.xml"

 

Any ideas?

Edited November 21, 2018 by zandrsn

Start with posting your diagnostics file. See Tools -> Diagnostics

 

As a quick test start your system in safemode and see if the problem persists.

On 11/21/2018 at 1:31 AM, bonienl said:

Start with posting your diagnostics file. See Tools -> Diagnostics

 

As a quick test start your system in safemode and see if the problem persists.

Sorry for the delay, I was away from my server. After upgrading to 6.6.5 auto-updating seems to work fine, but I do find that whenever I try to update containers manually it usually stalls, resulting in an orphaned image and need to reinstall the container app, and when I try to stop or restart a container I usually get an "Execution error" message and have to reload the docker page to see if the container actually stopped or restarted.

 

I've attached my diagnostics below:

vulftower-diagnostics-20181127-0926.zip

Edited November 27, 2018 by zandrsn
clarified container restarting problem

I'm also getting this in my system log. It may be totally unrelated, so apologies if so, but I thought it was strange because I don't have a drive called sdk1
 

Nov 27 09:27:46 vulfTower kernel: fat__get_entry: 6 callbacks suppressed
Nov 27 09:27:46 vulfTower kernel: FAT-fs (sdk1): Directory bread(block 8364) failed
Nov 27 09:27:46 vulfTower kernel: FAT-fs (sdk1): Directory bread(block 8365) failed
Nov 27 09:27:46 vulfTower kernel: FAT-fs (sdk1): Directory bread(block 8366) failed
Nov 27 09:27:46 vulfTower kernel: FAT-fs (sdk1): Directory bread(block 8367) failed
Nov 27 09:27:46 vulfTower kernel: FAT-fs (sdk1): Directory bread(block 8368) failed
Nov 27 09:27:46 vulfTower kernel: FAT-fs (sdk1): Directory bread(block 8369) failed
Nov 27 09:27:46 vulfTower kernel: FAT-fs (sdk1): Directory bread(block 8370) failed
Nov 27 09:27:46 vulfTower kernel: FAT-fs (sdk1): Directory bread(block 8371) failed
Nov 27 09:27:46 vulfTower kernel: FAT-fs (sdk1): Directory bread(block 8372) failed
Nov 27 09:27:46 vulfTower kernel: FAT-fs (sdk1): Directory bread(block 8373) failed

 

Edited November 27, 2018 by zandrsn
added code

17 minutes ago, zandrsn said:

FAT-fs

Your flashdrive most likely dropped offline.  Use a different port (preferably USB2).  You will have to reboot.

6 minutes ago, Squid said:

Your flashdrive most likely dropped offline. 

1

 

That's what I thought as well, because of the FAT-fs, but it's still showing as mounted at sda.

My server is running a parity check right now, but I'll reboot afterward and see if the error persists.
 

Edited November 27, 2018 by zandrsn
spelling

Sure, make me actually read the diagnostics

 

Nov 25 23:55:05 vulfTower kernel: scsi 18:0:0:0: Direct-Access     Kindle   Internal Storage 0100 PQ: 0 ANSI: 2

	Nov 25 23:55:05 vulfTower kernel: sd 18:0:0:0: Attached scsi generic sg11 type 0

	Nov 25 23:55:05 vulfTower kernel: sd 18:0:0:0: Power-on or device reset occurred

	Nov 25 23:55:05 vulfTower kernel: sd 18:0:0:0: [sdk] Attached SCSI removable disk

 

its your kindle 

10 hours ago, Squid said:

its your kindle 

 

Weird... there wasn't a kindle attached. Maybe some sort of lingering mount point from when one was previously charging off of the server. 

 

Thanks for checking out the diagnostics. Did you happen to see anything that might indicate why docker container manual updating is failing (and orphaning images) so frequently, and restarting or stopping so often results in an execution error?

... it might be related to a (the) ssl bug i saw here somewhere? 

 

besides this i also notcied that sometimes manual updating / installing dockers result in a hanging webpage until it shows in the log upstream timeout... but never happend in auto update *knock on wood* but since unraid istnw orking since i updated to the newest rc i cant tell for sure.

 

edit there it is:

 

 

Edited January 24, 2019 by nuhll

You might also want to put the flash drive in a Windows box and check it for errors.