You might encounter these issues during an update.
Service doesn't start
Rarely, a system deployment, service management action, or system update fails because a service fails to start. When this happens, the System Management application is inaccessible from the instance where the failure occurred.
The logs in the watchdog-service log folder contain this error:
Error response from daemon: Conflict. The name "service-name" is already in use by container Docker-container-id. You have to remove (or rename) that container to be able to reuse that name.To resolve this issue, restart the Docker service on the instance where the service failed to start. For example, if you are using systemd to run Docker, run:
systemctl restart dockerAfter restarting Docker, try the system deployment, service management action, or system update again.
PUT and GET calls on encrypted objects fail
After you turn on encryption, PUTS and GETS of objects require the key management server (KMS) to be up and unsealed. During an update the KMS can restart multiple times, including when the master nodes and services are upgraded and when the Vault service is updated. When the KMS service restarts, it is sealed, which can interrupt service.
If you are using encryption, monitor the Vault service closely during an update to prevent interruptions. Whenever the service restarts and gets sealed, unseal it.
If you have access to the Aspen administration app, you can monitor the health of the KMS by checking for the alert "Failed to connect to KMS server." When you see this alert, you know that the KMS is either down or sealed.
Another approach is to load the KMS page, which is at port 8200 of the system. The status of the KMS is displayed in the upper right corner. A red dot indicates that it is sealed.