sando38
commented
3 months ago @badlop as discussed
Closed sando38 closed 1 month ago
sando38
commented
3 months ago @badlop as discussed
badlop
commented
3 months ago I've tested compilation of ejabberd master git from source code with different Erlang/OTP versions and the results are:
ODBC: received unexpected info: {tcp_closed,#Port<0.75>}Same problem with the ghcr.io/processone/ejabberd:latest container image.
Using git bisect on erlang, I found that the problematic commit is https://github.com/erlang/otp/commit/53ef5df40c733ce3d8215c5c98805f99f378f656
Using erlang OTP-27.0-rc1 and reverting that commit, ejabberd works perfectly with mssql.
Right now the only way to reproduce the problem is using ejabberd... I found no way to provoke the problem in odbc without using ejabberd.
Trying to find some reproduction steps that wouldn't involve ejabberd:
Setup:
cat >"/tmp/odbcinst.ini" <<-'EOF'
[ODBC]
Driver = libtdsodbc.so
EOFThis works correctly and returns {updated,undefined}:
erl
os:putenv("ODBCSYSINI", "/tmp/").
odbc:start().
{ok, Ref} = odbc:connect("DRIVER=ODBC;SERVER=mssql;DATABASE=ejabberd_test;UID=ejabberd_test;PWD=ejabberd_Test1;PORT=1433;CLIENT_CHARSET=UTF-8;", []).
erlang:process_info(Ref).
odbc:sql_query(Ref, "CREATE TABLE EMPLOYEE (NR integer, FIRSTNAME char varying(20), LASTNAME char varying(20), GENDER char(1), PRIMARY KEY(NR))").
odbc:describe_table(Ref, "EMPLOYEE").Interestingly, if we provoke some error in erlang, the odbc query fails with {error,connection_closed}:
erl
os:putenv("ODBCSYSINI", "/tmp/").
odbc:start().
{ok, Ref} = odbc:connect("DRIVER=ODBC;SERVER=mssql;DATABASE=ejabberd_test;UID=ejabberd_test;PWD=ejabberd_Test1;PORT=1433;CLIENT_CHARSET=UTF-8;", []).
erlang:process_info(Ref).
odbc:describe_table(Ref, "EMPLOYEE").
aa:bb().
erlang:process_info(Ref).
odbc:describe_table(Ref, "EMPLOYEE").One wild hypothesis: maybe, when using erlang 26.0-rc2 or higher, ejabberd provokes some error that closes the odbc connection. That error is not provoked with older erlang versions. And the error itself is being silenced, so we are not aware of it.
petertirrell
commented
1 month ago I think I am experiencing this exact same issue, on ejabberd 24.02. We're using the OTP that came with that. Is the current solution to try and load and use a specific working version of OTP?
badlop
commented
1 month ago I think I am experiencing this exact same issue, on ejabberd 24.02. We're using the OTP that came with that.
Aha, the binary installers and containers for ejabberd 24.02 include Erlang/OTP 26.2, and are affected by this problem.
Is the current solution to try and load and use a specific working version of OTP?
Yes, either using Erlang 26.0-rc2 or older...
Or compile Erlang/OTP from source with a small patch that revers the problematic commit.
I've applied that solution in branch 24.02-otp-patch-mssql. This is just ejabberd 24.02 with a small patch for Erlang 26.2 that reverts the problematic commit.
There are available binary installers and containers. I've tried the amd64 container and seems to work: at least it starts, connects to MSSQL and I can register an account.
badlop
commented
1 month ago As a temporary workaround, the ejabberd binary installers now include a patch that reverts the problematic commit in Erlang/OTP.
Environment
26.2Configuration (only if needed): grep -Ev '^$|^\s*#' ejabberd.yml
Errors from error.log/crash.log
Bug description
I started updating the ejabberd helm chart to newest
24.02. While doing that and updating the corresponding container image I found that there is a problem with MS SQL. Therefore, I tested the officialghcr.io/processone/ejabberd:24.02as well to see if it depends on my custom image, but it does not (see error message above).reason: {port_exit,memory_allocation_failed}What solved the issue was reverting the container build from erlang 26.2 / elixir 16.1 to erlang 25.3 / elixir 14.4 . I haven't tested anything in between.
It most likely is unrelated to Alpine packages, because I also tried it with a custom Debian based variant with the same combination erlang 26.2 / elixir 16.1 .