Bug 1315098 - ejabberd-16.01-3 fails to start due to "Application p1_zlib exited"
ejabberd-16.01-3 fails to start due to "Application p1_zlib exited"
Status: CLOSED RAWHIDE
Product: Fedora
Classification: Fedora
Component: erlang-p1_zlib (Show other bugs)
24
x86_64 Linux
unspecified Severity high
: ---
: ---
Assigned To: Randy Barlow
Randy Barlow
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2016-03-06 11:39 EST by Randy Barlow
Modified: 2016-03-06 12:31 EST (History)
3 users (show)

See Also:
Fixed In Version: erlang-p1_zlib-1.0.0-2.fc24, erlang-p1_zlib-1.0.1-2.fc25
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2016-03-06 12:31:02 EST
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Randy Barlow 2016-03-06 11:39:06 EST
ejabberd does not start correctly, seemingly due to the p1_zlib package not providing a shared object that it can find. Here is what I see in the ejabberd log file:

2016-03-06 11:09:28.773 [info] <0.7.0> Application lager started on node ejabberd@localhost
2016-03-06 11:09:28.889 [info] <0.7.0> Application crypto started on node ejabberd@localhost
2016-03-06 11:09:28.938 [info] <0.7.0> Application sasl started on node ejabberd@localhost
2016-03-06 11:09:28.986 [info] <0.7.0> Application asn1 started on node ejabberd@localhost
2016-03-06 11:09:28.986 [info] <0.7.0> Application public_key started on node ejabberd@localhost
2016-03-06 11:09:29.022 [info] <0.7.0> Application ssl started on node ejabberd@localhost
2016-03-06 11:09:29.085 [info] <0.7.0> Application p1_yaml started on node ejabberd@localhost
2016-03-06 11:09:29.173 [info] <0.7.0> Application p1_tls started on node ejabberd@localhost
2016-03-06 11:09:29.223 [info] <0.7.0> Application p1_xml started on node ejabberd@localhost
2016-03-06 11:09:29.328 [info] <0.7.0> Application p1_stringprep started on node ejabberd@localhost
2016-03-06 11:09:29.384 [error] <0.123.0> failed to load zlib driver: cannot open shared object file: Not a directory
2016-03-06 11:09:29.384 [error] <0.123.0> CRASH REPORT Process <0.123.0> with 0 neighbours exited with reason: {open_error,-10} in gen_server:init_it/6 line 344
2016-03-06 11:09:29.384 [error] <0.122.0> Supervisor ezlib_sup had child undefined started with ezlib:start_link() at undefined exit with reason {open_error,-10} in context start_error
2016-03-06 11:09:29.384 [critical] <0.38.0>@ejabberd:exit_or_halt:133 failed to start application 'p1_zlib': {error,
                                        {{shutdown,
                                          {failed_to_start_child,ezlib,
                                           {open_error,-10}}},
                                         {ezlib_app,start,[normal,[]]}}}
2016-03-06 11:09:29.384 [error] <0.120.0> CRASH REPORT Process <0.120.0> with 0 neighbours exited with reason: {{shutdown,{failed_to_start_child,ezlib,{open_error,-10}}},{ezlib_app,start,[normal,[]]}} in application_master:init/4 line 134
2016-03-06 11:09:29.385 [info] <0.7.0> Application p1_zlib exited with reason: {{shutdown,{failed_to_start_child,ezlib,{open_error,-10}}},{ezlib_app,start,[normal,[]]}}

When I look at the p1_zlib installation, I notice that the shared object is just called "lib", which doesn't seem right but it does seem to be the correct .so:
# ldd /usr/lib64/erlang/lib/p1_zlib-1.0.0/priv/lib 
	linux-vdso.so.1 (0x00007ffc598d8000)
	libz.so.1 => /lib64/libz.so.1 (0x00007f926b1c7000)
	libc.so.6 => /lib64/libc.so.6 (0x00007f926adf9000)
	/lib64/ld-linux-x86-64.so.2 (0x000056174697d000)

I'm not sure what the .so should be named, but I am pretty sure lib is not correct.
Comment 1 Randy Barlow 2016-03-06 11:47:24 EST
The issue was that the spec file installs the ezlib_drv.so to $RPM_BUILD_ROOT%{_erllibdir}/%{srcname}-%{version}/priv/lib instead of to $RPM_BUILD_ROOT%{_erllibdir}/%{srcname}-%{version}/priv/lib/. At least it's an easy fix!

Note You need to log in before you can comment on or make changes to this bug.