ejabberd - Comments for "badarg, [{ets, lookup, [crypto_server_table, port]},"

I found a solution for my system - might work for some of you

Ross Hansen — Tue, 04 Mar 2008 23:35:29 +0000

Hey folks,

I ran into this read error problem when installing (from source) ejabberd 2.0.0 on a RHEL 5 64bit Dell PowerEdge 1950.

Dell PowerEdge 1950
RHEL 5
Erlang R11B-5 (compiled from source)
expat 2.01 (compiled from source)
ejabberd 2.0.0 (compiled from source)
gcc 4.1

My old server was a 32bit desktop system that I was able to use a install package on. With our new 64bit server I was unable to find one that would work so I set about building from source.

What I found was an issue with compiling erlang with the defaults. I did NOT have to uninstall anything. I had to rebuild and install erlang.

From within my existing erlang src directory I entered the following commands:

./configure
make

Then I navigated to: %ERL_TOP%/lib/crypto/c_src
and entered this command:

gcc -shared  -o ../priv/lib/x86_64-unknown-linux-gnu/crypto_drv.so ../priv/obj/x86_64-unknown-linux-gnu/crypto_drv.o /usr/lib64/libcrypto.so

After this I moved back to the root of my erlang source folder and entered:

make install

After this all I had to do was stop, and then start my ejabberd server and all was well with the world. I found the reference to this fix here:
http://www.erlang.org/pipermail/erlang-patches/2007-November/000196.html

Hope this helps anyone else who may encounter this issue. Keep up the good work fellas!

Peace
Ross

Hi, I've had the same

Tom de Waha — Wed, 04 Jul 2007 17:40:40 +0000

Hi,
I've had the same problem but following workaround seems to work:
I don't know why but when i strace the erlang shell while starting crypto() i
see it searching for libcrypto.so.0.9.8 in lib/linux-x86 but the installer came with
libcrypto.so.0.9.7, after symlinking libcrypto.so.0.9.7 to libcrypto.so.0.9.8 crypto() started
without any other problems. Ejabberd also seems to work now.

Regards.

Can't resolve this problem on Ubuntu6.1

Anonymous — Mon, 28 May 2007 04:45:04 +0000

Hi.. I'm having this same symptom... I've tried symlinking the libssl and libcryto .so files into /usr/local/lib... I've tried renaming those symlinks as libssl.so and libcrypto.so explicitly, instead of the long version names of the actual libs... I've tried reinstalling ejabberd after doing all that... still PSI cannot log in while Spark can... what can this mean?

crypto_drv.so

Zxinn — Fri, 30 Mar 2007 11:58:04 +0000

I had this problem today, and solved it with some tinkering.

I would guess this will only occur if the crypto server could not be started. To test this open an erlang shell and start the crypto server. You do this by entering "crypto:start()." without the quotation. If the crypto server can not be started this should yield alot of error messages when the server tries to start multiple times.

You can try loading the file like the crypto_server does. In crypto-1.5 it's done something like this:

crypto_server:init/0 wrote:

erl_ddll:start(),
PrivDir = code:priv_dir(crypto),
LibDir1 = filename:join([PrivDir, "lib"]),
erl_ddll:load_driver(LibDir1, crypto_drv).

erl_ddll:load_driver() returns ok on success and {error,Reason} on fail. The crypto_server tries with a different path after the first fail, but has no error handling for an error during this second load and just tries to run with it regardless of the outcome.

Among the error messages printed you will get a line, "sh: exec: crypto_drv not found", or something of the like. I've seen different versions of this error message on different platforms. One reason for this, and the reason my crypto server would not start, is that the crypto_server could not load crypto_drv.so because it's not linked properly. The file should be located in your erlang lib, under crypto-/priv/lib/, or something similar.

If this file exists, it's quite possible that the path it tries to find ssl libs for dynamic loading is wrong. I had to rebuild my crypto_drv.so file from the priv/obj folder with my Makefile's SO_SSL_LIBDIR variable changed to correspond to the location of my libssl.so and libcrypto.so files. Another way to fix this could be to symlink or copy the corresponding libssl.so and libcrypto.so files to /usr/local/lib, which I think is the default path to look for them.

If you have this error and this solution fixes it, you may also have some trouble with your lib/ssl-/priv/bin/ssl_esock file's dynamic library loading. Rebuilding this file, or copying or symlinking the lib files to /usr/local/lib might solve this issue too.

/Zxinn