> For the complete documentation index, see [llms.txt](https://docs.digit.org/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.digit.org/complaints-management/cms-v2.11/deploy/setup/faq.md).

# FAQ

This page provides guidance on resolving common issues

## Pod Stuck in Init State

### 1. What does **Pod in `Init:Error` state** mean?

#### Possible Causes

* **Git Sync Container Failure**
  * Occurs when a service needs to sync configuration from Git (e.g., Persister, indexer, mdms config).
  * Common reasons:
    * Incorrect Git SSH keys.
    * Extra spaces, invalid characters, or indentation issues in the SSH key.
* **DB Migration Container Failure**
  * Occurs when Flyway migrations fail during initialisation.
  * Common reasons:
    * Database connection issues.
    * Invalid or corrupted Flyway SQL migration files.

#### Resolution Steps

1. Check the pod description:

   ```bash
   kubectl describe pod <pod_name> -n <namespace>
   ```
2. Review container logs for detailed error messages:

   ```bash
   kubectl logs <pod_name> -n <namespace> -c git-sync
   kubectl logs <pod_name> -n <namespace> -c db-migration
   ```
3. Fix the underlying issue (e.g., update SSH keys, correct SQL files).
4. Restart the pod once resolved.

***

### 2. Pod in `Init:ConfigMapKeyMissing` State

#### Cause

This error occurs when a pod tries to read a configuration key that does not exist in the referenced **ConfigMap** or **Secret**.

Example:

```yaml
- name: STATE_LEVEL_TENANT_ID
  valueFrom:
    configMapKeyRef:
      name: egov-config
      key: state-level-tenant-id
```

If the key `state-level-tenant-id` is not defined in the `egov-config` ConfigMap, the pod will fail with this state. Add the missing key in the ConfigMap and redeploy a service.

#### Resolution Steps

1. Describe the pod to identify the missing key:

   ```bash
   kubectl describe pod <pod_name> -n <namespace>
   ```
2. Locate the missing key/secret in the output.
3. Update the ConfigMap/Secret with the required key-value pair:

   ```bash
   kubectl edit configmap egov-config -n <namespace>
   ```
4. Restart the pod to apply the changes.

***

### 3. Pod in `Init:CrashLoopBackOff` State

#### Cause

This state indicates that one or more init containers are **repeatedly crashing**. Common failing containers include:

* `git-sync` (Git configuration issues)
* `db-migration` (database/Flyway issues)
* Service Dependency Failure
  * A service pod may fail if it depends on another service that is not yet running.
  * Example:
    * The **User service** requires **MDMS data** to initialise.
    * If the **MDMS service** is not up, the User service will crash repeatedly.
    * Once the MDMS service is running, the dependent User service will start successfully.

#### Resolution Steps

1. Describe the pod to identify the failing container:

   ```bash
   kubectl describe pod <pod_name> -n <namespace>
   ```
2. Check the logs of the specific container:

   ```bash
   kubectl logs <pod_name> -n <namespace> -c git-sync
   kubectl logs <pod_name> -n <namespace> -c db-migration
   kubectl logs <pod_name> -n <namespace> -f
   ```
3. Verify dependencies:
   * Ensure required services (e.g., MDMS) are deployed and running.
   * Check connectivity between services.
4. Fix the reported error (e.g., database connectivity, missing configs, Git issues, Service Dependency Failure).
5. Restart the pod once the issue is resolved.

***

✅ **Tip:** Always start by running `kubectl describe pod` to identify the exact cause before applying fixes.


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation by asking a question.

Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters:

```
GET https://docs.digit.org/complaints-management/cms-v2.11/deploy/setup/faq.md?ask=<question>&goal=<user_goal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.