Rreceiving "Lock file to RocksDB is currently held by another process"

I have been working on the deployment of the dremio container in the kubernetes cluster. Well everything works fine with the new volume mounted in Azure. But the thing is when there is the new version of dremio in the docker hub and applying the new deployment with the latest tag, the container fails to initialize with the error message

Lock file to RocksDB is currently held by another process.

In this case I just have to delete the volume mount and start over again. I have tried to run the dremio-admin upgrade command. But none of the dremio-admin command works that is in /opt/dremio/bin folder.

Any suggestions for me?

1 Like


This suggests there is a second coordinator trying to come up and when trying to get the lock file to the database it is already held by another Dremio process. This happens when we setup HA, when RocksDB is on NAS and we have one coordinator up reading/writing to the NAS and a second coordinator is brought up and it waits on this mode, if the primary gets killed the standby gets the lock

So when you are trying to deploy, are we sure the old coordinator is brought down? Also, what kind of Volume is on Azure?

Why not store the metadata in relation database like mysql?

@balaji.ramaswamy I was using the dremio docker image directly to my minikube cluster mounting the volume on azure storage. Is there any way to setup the dremio-oss image directly to the cluster without any issues and be able to run the dremio-admin commands?


Are you looking for something like the below?