Can you please send the full logs about this container (just grep 680d3849-2b2a-4549-8842-8ef358599478 in agent log)? And is there anything left in the staging directory (`--docker_store_dir/staging/`) when this issue happens?
Regards, Qian Zhang On Wed, Aug 28, 2019 at 7:07 PM Marc Roos <[email protected]> wrote: > I had this again. > > E0828 12:51:46.146246 2663200 slave.cpp:6486] Container > '680d3849-2b2a-4549-8842-8ef358599478' for executor > 'ldap.instance-afee8840-c981-11e9-8333-0050563001a1._app.1' of framework > d5168fcd-51be-48c3-ba64-ade27ab23c4e-0000 failed to start: Container is > being destroyed during provisioning > > > > -----Original Message----- > From: Qian Zhang [mailto:[email protected]] > Sent: dinsdag 20 augustus 2019 1:12 > To: user > Subject: Re: Large container image failing to start 'first' time > > > > > Large container image failing to start 'first' time Did you see any > errors/warnings in agent logs when the container failed to start? > > > Regards, > Qian Zhang > > > On Mon, Aug 19, 2019 at 10:46 PM Marc Roos <[email protected]> > wrote: > > > > I have a container image of around 800MB. I am not sure if that is > a > lot. But I have noticed it is probably to big for a default setup > to get > it to launch. I think the only reason it launches eventually is > because > data is cached and no timeout expires. The container will launch > eventually when you constrain it to a host. > > How can I trace where this timeout occurs? Are there options to > specify > timeouts? > > > > > > > > > > >
