Troubleshooting

Procedure

• Run the following command to check the version information:

  $ microshift version

  Copy to Clipboard Toggle word wrap

  Example output

  Red Hat build of MicroShift Version: 4.14-0.microshift-e6980e25
  Base OCP Version: 4.14

  Copy to Clipboard Toggle word wrap

Procedure

• To get the version number using the OpenShift CLI (oc), view the kube-public/microshift-version config map by running the following command:

  $ oc get configmap -n kube-public microshift-version -o yaml

  Copy to Clipboard Toggle word wrap

  Example output

  apiVersion: v1
  data:
    major: "4"
    minor: "13"
    version: 4.13.8-0.microshift-fa441af87431
  kind: ConfigMap
  metadata:
    creationTimestamp: "2023-08-03T21:06:11Z"
    name: microshift-version
    namespace: kube-public

  Copy to Clipboard Toggle word wrap

• Not waiting several minutes after a system start to successfully stop MicroShift. The system must complete health checks and any other background processes before a back up can succeed.

• If MicroShift stopped running because of an error, you cannot perform a backup of the data.

  • Make sure the system is healthy.
  • Stop it in a healthy state before attempting a backup.
• If you do not have sufficient storage for the data, the backup fails. Ensure that you have enough storage for the MicroShift data.
• If you do not have sufficient permissions, a backup can fail. Ensure you have the correct user permissions to create a backup and perform the required configurations.

• Logs print to the console during manual backups.

• Logs are automatically generated for rpm-ostree system automated backups as part of the MicroShift journal logs. You can check the logs by running the following command:

  $ sudo journalctl -u microshift

  Copy to Clipboard Toggle word wrap

Procedure

• You can check the system status, which returns the cluster status, by running the following command:

  $ sudo systemctl status microshift

  Copy to Clipboard Toggle word wrap

  If MicroShift is failing to start, this command returns the logs from the previous run.

• Optional: You can view the logs by running the following command:

  $ sudo journalctl -u microshift

  Copy to Clipboard Toggle word wrap

• Optional: If MicroShift is running, you can see active pods by entering the following command:

  $ oc get pods -A

  Copy to Clipboard Toggle word wrap

Procedure

• Edit the /etc/microshift/config.yaml file to set the memoryLimitMB value.

  etcd:
    memoryLimitMB: 128

  Copy to Clipboard Toggle word wrap
  Note

  The minimum permissible value for memoryLimitMB on MicroShift is 128 MB. Values close to the minimum value are more likely to impact etcd performance. The lower the limit, the longer etcd takes to respond to queries. If the limit is too low or the etcd usage is high, queries time out.

Procedure

• Check the MicroShift journal logs by running the following command:

  $ sudo journalctl -u microshift

  Copy to Clipboard Toggle word wrap

• Check the greenboot journal logs by running the following command:

  $ sudo journalctl -u greenboot-healthcheck

  Copy to Clipboard Toggle word wrap

• Check the journal logs for a boot of a specific service by running the following command:

  $ sudo journalctl --boot <boot> -u <service-name>

  Copy to Clipboard Toggle word wrap

• Examining the comprehensive logs of a specific boot uses two steps. First list the boots, then select the one you want from the list you obtained:

  • List the boots present in the journal logs by running the following command:

    $ sudo journalctl --list-boots

    Copy to Clipboard Toggle word wrap

  • Check the journal logs for the boot you want by running the following command:

    $ sudo journalctl --boot <-my-boot-number>

    Copy to Clipboard Toggle word wrap

Procedure

• To see a report of health check status, use the following command:

  $ systemctl show --property=SubState --value greenboot-healthcheck.service

  Copy to Clipboard Toggle word wrap
  • An output of start means that greenboot checks are still running.
  • An output of exited means that checks have passed and greenboot has exited. Greenboot runs the scripts in the green.d directory when the system is a healthy state.
  • An output of failed means that checks have not passed. Greenboot runs the scripts in red.d directory when the system is in this state and might restart the system.

• To see a report showing the numerical exit code of the service where 0 means success and non-zero values mean a failure occurred, use the following command:

  $ systemctl show --property=ExecMainStatus --value greenboot-healthcheck.service

  Copy to Clipboard Toggle word wrap

• To see a report showing a message about boot status, such as Boot Status is GREEN - Health Check SUCCESS, use the following command:

  $ cat /run/motd.d/boot-status

  Copy to Clipboard Toggle word wrap

Prerequisites

• You have installed jq.
• You have access to the cluster as a user with the cluster-admin role.