You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Several services within our OpenIM deployment are failing to start, entering a CrashLoopBackOff state. The logs indicate an authentication failure using the SCRAM-SHA-1 mechanism during the MongoDB connection handshake. This issue is affecting multiple components, including the openim-msgtransfer, openim-rpc-user, and others, leading to widespread service disruption.
Relevant Logs:
Error: ==> github.com/openimsdk/open-im-server/v3/pkg/common/db/unrelation.(*Mongo).createMongoIndex()@153: CreateIndex: connection() error occurred during connection handshake: auth error: sasl conversation error: unable to authenticate using mechanism "SCRAM-SHA-1": (AuthenticationFailed) Authentication failed.
Service Status:
Several openimserver services are in a CrashLoopBackOff state, including openim-msgtransfer, openim-rpc-conversation, openim-rpc-friend, openim-rpc-group, and openim-rpc-msg.
Events:
Warning BackOff 2m5s (x50214 over 7d14h) kubelet Back-off restarting failed container openim-rpc-user in pod openimserver-openim-rpc-user-7f8f7bd4c6-49smx_openim-lin(3bf29b26-a24f-4397-85be-de97fd2a646f)
What did you expect to happen?
Steps to Reproduce:
Deploy OpenIM version v3.3.0 in a Kubernetes environment.
Observe the pod statuses and logs for the aforementioned services.
Expected Behavior:
Services should start successfully without authentication errors during the MongoDB connection process.
Actual Behavior:
Services are crashing and entering a CrashLoopBackOff state due to authentication failures with SCRAM-SHA-1 during the MongoDB connection handshake.
Additional Information:
Configuration details, if relevant
Any recent changes made to the environment or configuration
Any insights or assistance in resolving this authentication issue would be greatly appreciated.
How can we reproduce it (as minimally and precisely as possible)?
Please ensure you replace placeholders like [Specify version] with actual version numbers from your environment and adjust any additional information to provide a clear and concise description of your issue.
```console
$ {name} version
# paste output here
```
Cloud provider
OS version
```console
# On Linux:
$ cat /etc/os-release
# paste output here
$ uname -a
# paste output here
# On Windows:
C:\> wmic os get Caption, Version, BuildNumber, OSArchitecture
# paste output here
```
Install tools
The text was updated successfully, but these errors were encountered:
What happened?
Several services within our OpenIM deployment are failing to start, entering a CrashLoopBackOff state. The logs indicate an authentication failure using the SCRAM-SHA-1 mechanism during the MongoDB connection handshake. This issue is affecting multiple components, including the
openim-msgtransfer
,openim-rpc-user
, and others, leading to widespread service disruption.Relevant Logs:
Service Status:
openimserver
services are in a CrashLoopBackOff state, includingopenim-msgtransfer
,openim-rpc-conversation
,openim-rpc-friend
,openim-rpc-group
, andopenim-rpc-msg
.Events:
What did you expect to happen?
Steps to Reproduce:
Expected Behavior:
Services should start successfully without authentication errors during the MongoDB connection process.
Actual Behavior:
Services are crashing and entering a CrashLoopBackOff state due to authentication failures with SCRAM-SHA-1 during the MongoDB connection handshake.
Additional Information:
Any insights or assistance in resolving this authentication issue would be greatly appreciated.
How can we reproduce it (as minimally and precisely as possible)?
Please ensure you replace placeholders like
[Specify version]
with actual version numbers from your environment and adjust any additional information to provide a clear and concise description of your issue.Anything else we need to know?
Environment:
- OpenIM version: v3.3.0 - Kubernetes version: [Specify version] - MongoDB version: [Specify version, if involved] - Deployment environment: (e.g., cloud provider, on-prem)
version
Cloud provider
OS version
Install tools
The text was updated successfully, but these errors were encountered: