Troubleshooting

Save PDF

Last Updated: April 14, 2026
3 minute read

MarkLogic Server
Documentation

Note:

For the commands below, provide the namespace name when the chart is deployed to a different namespace than the current kubectl context. Use -n <your-namespace> to apply the command to a specific namespace, or use -A to apply the command to all namespaces.

Retrieve the status of deployed resources

Get the status of the Helm deployment by entering this command:

helm list

Get the status of all pods in the current namespace by entering this command:

kubectl get pods

Note:

The commands above retrieve all pods running in the current namespace.

Get the status of all pods in a MarkLogic deployment by entering this command:

kubectl get pods --selector="app.kubernetes.io/name=marklogic" --all-namespaces

To list all the pods for a specific release:

kubectl get pods --selector="app.kubernetes.io/instance=<RELEASE-NAME>

To get detailed information, use the kubectl describe command:

kubectl describe pods <POD-NAME>

Note:

After entering this command, use the Events list at the bottom for debugging.

Statuses for MarkLogic pods

Pending

This status indicates that the Kubernetes system has accepted the pod, but the container within the pod has not started yet. If a pod remains in this phase, use the kubectl describe pods <POD-NAME> command to get more information. Often, the Events list at the bottom displays a detailed warning. For example, if no nodes meet the scheduling requirements, a FailedScheduling warning event appears in the Events list.

Running

This status indicates that the system has scheduled the pod to a node and all containers in the pod are running.

Access logs

To access container logs for specific pod, use this command:

kubectl logs <pod-name>

To access all the logs in MarkLogic server:

Use the kubectl exec command to get access into a specific MarkLogic container:
```
kubectl exec -it <POD-NAME> -- /bin/bash
```
Go to /var/opt/MarkLogic/Logs/ to view all the logs.

Note:

It is recommended that you set up log forwarding in production environments.

Common issues

ImagePullBackOff

When a pod enters ImagePullBackOff status, Kubernetes was unable to download the container image for the pod's container. This could be caused by a network issue or incorrect image tags.
By default, the image registry is Docker Hub. Test the connection from the node to Docker Hub to make sure that the Kubernetes node has access to the registry.
If you provide a customized value for the image repository or tag during the installation, use this command to test if the image is valid:
```
kubectl run marklogic --image=marklogicdb/marklogic-db:latest
```

CrashLoopBackOff

When a pod enters CrashLoopBackOff status, the pod's containers have exited with an error, causing Kubernetes to restart them.

This issue could be caused by several reasons:

Probe Failure - The MarkLogic container uses a liveness probe to perform a container health check. If the liveness probe fails a certain number of times, the container will restart.
Insufficient Resources, such as CPU or Memory - Double-check the resource limits and requests specified in the values.yaml file.
Application Failure - Check the container or MarkLogic Server logs to see if there are any errors or messages related to the crashes.

Note:

To see MarkLogic Server for a crashed container, you need a logs forwarder solution. (FluentBit is enabled in the Helm Chart).

Common debug procedures

Get pod statuses by using kubectl get pods.
Get detailed information by using kubectl describe pods.
Get container logs and MarkLogic logs.

Recommended guides for debug procedures in Kubernetes

For more information about how to troubleshoot in Kubernetes, see A visual guide on troubleshooting Kubernetes deployments.

MarkLogic® Server on Kubernetes