Cannot connect to the Docker daemon at unix:///home/tentacle/.docker/run/docker.sock. Is the docker daemon running?

Hey there, I’m suddenly receiving an error in the ‘Acquire packages’ step about Docker:

Cannot connect to the Docker daemon at unix:///home/tentacle/.docker/run/docker.sock. Is the docker daemon running?

This has been working up till now. It is a dynamic worker using the Ubuntu Latest machine image.

The machine name from the error is pkrvmv2eoauxeuv

Hi Dylan,

Thanks for getting in touch, and welcome!

I’m sorry to see you’re hitting this issue suddenly. We’d like to have a look at this directly, and hopefully we can get this fixed up quickly. Could you tell me your instance URL?

Best regards,

Kenny

Hey Kenneth,

It’s https://kolmeo.octopus.app/

Regards,
Jeremy

Hi Jeremy,

I can see that a new Ubuntu worker has been leased for this instance. Are you still experiencing problems with the deployment?

Regards,
Paul

Hey Paul, yes it does look like deployments are running again since around 5pm. For my knowledge is there a way we can kill the lease on the worker to have a new one come online?

Unfortunately not, the worker lease does expire after a couple hours of inactivity but it can’t be manually deleted from within the instance.

This issue with docker not running is one that we experienced a lot a while back and resulted in several additional checks being added to the Worker creation process that did seem to resolve the issue.
If you do experience this again, please let us know and we will investigate further to see if there has been a regression on the worker image somewhere.

1 Like

Sorry to report, but we are getting this issue too (orgflow.octopus.app).

We had a deployment succeed at 11:19 BST, but the same project has consistently failed with this issue since about 13:24. (Ran on: OctopusServerNodes-octopus-i008578-fd9fdbc54-7jxph)

Are we stuck now until the lease expires?

I guess we could change the process to alter the worker pool to force a new worker be assigned to us, but I’d rather not, given that this is a deployment to our production env.

Hi Chris,

Apologies that this is occurring for you.

I’ve marked that worker for deletion and your next deployment should lease a new worker. If you experience any issues with that one let me know and I’ll keep disabling them until we get you a working one.

Regards,
Paul

That’s fixed it, thanks for the super fast response!

I see the known tag on this thread- is there a fix on the way for this issue? It’s a bit cumbersome to have to get someone to manually re-assign us a lease whenever this happens.

Also- is this specific to the Ubuntu workers? Could we use one of the Windows ones instead as a workaround?

It is being investigated, I believe that an issue within Docker is causing it to cease working after some time but I am querying this internally to get more details.

I haven’t seen this occur on Windows workers, so, if switching isn’t too cumbersome then that may be smoother for you at the moment.

1 Like

Hi, sorry to jump on this but we’re also experiencing this issue at floww.octopus.app, is there any chance you can mark this machine name for deletion: pkrvmif7lt0nrsi

Many thanks

I’ve marked the Ubuntu worker you had leased for deletion. A new one should be leased on your next deployment.

Same deal for our cloud instance: https://defiance.octopus.app/

Also set the worker to delete.

Thanks for the quick response Paul, back up and running for us, cheers!
Mike

1 Like

Confirmed that the next deploy worked! Appreciate the quick response @paul.calvert !!

1 Like