Version of Rocket.Chat Server: working: 4.0.0 → update to 4.3.3 or higher
Operating System: Ubuntu 20.04.4 LTS
Deployment Method: tar/etc
Number of Running Instances: 1
DB Replicaset Oplog: rs01
NodeJS Version: v14.19.3
MongoDB Version: v4.4.1
Proxy: nginx
Firewalls involved: no
Problem:
I would like to update my Rocket.Chat Server to 4.3.3. or higher. I made an Backup with mongodump and restore it successfully with mongorestore.
As soon as I start the Rocketchat service it gives me this error:
Jun 07 11:44:17 chat-prod rocketchat[2988]: at TCP.onStreamRead (internal/stream_base_commons.js:188:23)
Jun 07 11:44:17 chat-prod rocketchat[2988]: at TCP.callbackTrampoline (internal/async_hooks.js:130:17) {
Jun 07 11:44:17 chat rocketchat[2988]: library: 'SSL routines',
Jun 07 11:44:17 chat rocketchat[2988]: function: 'ssl3_get_record',
Jun 07 11:44:17 chat rocketchat[2988]: reason: 'wrong version number',
Jun 07 11:44:17 chat rocketchat[2988]: code: 'ERR_SSL_WRONG_VERSION_NUMBER',
Jun 07 11:44:17 chat rocketchat[2988]: source: 'socket'
Jun 07 11:44:17 chat rocketchat[2988]: }
Jun 07 11:44:17 chat systemd[1]: rocketchat.service: Main process exited, code=exited, status=1/FAILURE
Jun 07 11:44:17 chat-prod systemd[1]: rocketchat.service: Failed with result 'exit-code'.
Nginx: /etc/nginx/ssl.conf (default):
ssl_protocols TLSv1 TLSv1.1 TLSv1.2; ....
I’am not using the SMTP E-Mail Function, so here are the default settings.
We are experiencing the same issue in a containerized environment.
We were using an older version 3.18.7 - had no issues so far and configured smtp and direct reply.
After realizing that direct reply is broken in Version 3.18.7 we tried to upgrade to version 4.8.6.
During the upgrade we experienced that rc was apparently trying to connect to our mail server and got the same ssl error messages as above. That lead to a failure of the container during the migration and we ran into a crashloop.
After deleting all the mail settings the container started without an issue. I will create and issue an github, because wrong mail settings shouldn’t lead to a failure of the container.
The same error message occured after using the mail settings again, but this time the server didn’t crash.