[syslog-ng] load failures in afsocket and afsql

Martin Holste mcholste at gmail.com
Tue Dec 14 23:34:18 CET 2010 

I do recall that spoof-source would not work on SLES 10--I had to
upgrade to SLES 11.2 in order to get the non-broken libnet.

On Tue, Dec 14, 2010 at 4:18 PM, Matthew Hall <mhall at mhcomputing.net> wrote:
> megahall at logproxy2:~$ readelf -d /home/y/lib64/syslog-ng/libafsocket.so
>
> Dynamic section at offset 0x19978 contains 29 entries:
>  Tag        Type                         Name/Value
>  0x0000000000000001 (NEEDED)             Shared library: [libsyslog-ng.so.0]
>  0x0000000000000001 (NEEDED)             Shared library: [libssl.so.108]
>  0x0000000000000001 (NEEDED)             Shared library: [libcrypto.so.108]
>  0x0000000000000001 (NEEDED)             Shared library: [libdl.so.2]
>  0x0000000000000001 (NEEDED)             Shared library: [libz.so.1]
>  0x0000000000000001 (NEEDED)             Shared library: [libwrap.so.0]
>  0x0000000000000001 (NEEDED)             Shared library: [libpthread.so.0]
>  0x0000000000000001 (NEEDED)             Shared library: [libc.so.6]
>  0x000000000000000e (SONAME)             Library soname: [libafsocket-tls.so]
>  0x000000000000000f (RPATH)              Library rpath: [/home/y/lib64:/usr/lib64]
>  ...
>
> It looks to me like libafsocket itself is built broken because it does
> not declare its libnet dependency that it picks up when spoof source is
> enabled.
>
> Matthew.
>
> On Tue, Dec 14, 2010 at 03:39:20PM -0600, Martin Holste wrote:
>> What does it do if you configure with --enable-static-linking or
>> switch it to --enable-dynamic-linking?  Since it sounds like you're
>> running out of ideas, messing with a few configure options are some
>> easy things to try.
>>
>> On Tue, Dec 14, 2010 at 2:41 PM, Matthew Hall <mhall at mhcomputing.net> wrote:
>> > More information:
>> >
>> > Trying to open module; module='afsocket', filename='/home/y/lib64/syslog-ng/libafsocket.so'
>> >
>> > Breakpoint 1, 0x00002b1af55db9ba in g_module_open () from /home/y/lib64/libgmodule-2.0.so.0
>> > (gdb) bt
>> > #0  0x00002b1af55db9ba in g_module_open () from /home/y/lib64/libgmodule-2.0.so.0
>> > #1  0x00002b1af538f82b in plugin_load_module (module_name=0x2b1af53976f1 "afsocket", cfg=0x471e2b0, args=0x0) at plugin.c:206
>> > #2  0x00002b1af5360110 in cfg_set_version (self=0x471e2b0, version=770) at cfg.c:282
>> > #3  0x00002b1af5383c57 in cfg_lexer_lex (self=0x47254a0, yylval=0x7fffcd074a80, yylloc=0x7fffcd074a60) at cfg-lexer.c:707
>> > #4  0x00002b1af5394245 in pragma_lex (yylval=0x7fffcd074a80, yylloc=0x7fffcd074a60, lexer=0x47254a0) at pragma-parser.c:50
>> > #5  0x00002b1af5393520 in pragma_parse (lexer=0x47254a0, result=0x7fffcd074bc8) at pragma-grammar.c:2733
>> > #6  0x00002b1af5383db0 in cfg_parser_parse (self=0x2b1af55c0b00, lexer=0x47254a0, instance=0x7fffcd074bc8) at cfg-parser.h:82
>> > #7  0x00002b1af53839f6 in cfg_lexer_lex (self=0x47254a0, yylval=0x7fffcd076f70, yylloc=0x7fffcd076f50) at cfg-lexer.c:646
>> > #8  0x00002b1af538c039 in main_lex (yylval=0x7fffcd076f70, yylloc=0x7fffcd076f50, lexer=0x47254a0) at cfg-parser.c:149
>> > #9  0x00002b1af538cf77 in main_parse (lexer=0x47254a0, dummy=0x7fffcd077140) at cfg-grammar.c:2957
>> > #10 0x00002b1af5360658 in cfg_parser_parse (self=0x2b1af55c05e0, lexer=0x47254a0, instance=0x7fffcd077140) at cfg-parser.h:82
>> > #11 0x00002b1af536058d in cfg_run_parser (self=0x471e2b0, lexer=0x47254a0, parser=0x2b1af55c05e0, result=0x7fffcd077140)
>> >    at cfg.c:378
>> > #12 0x00002b1af5360710 in cfg_read_config (self=0x471e2b0, fname=0x402d18 "/home/y/etc/syslog-ng.conf", syntax_only=0,
>> >    preprocess_into=0x0) at cfg.c:400
>> > #13 0x0000000000402803 in initial_init (cfg=0x7fffcd0771c8) at main.c:277
>> > #14 0x0000000000402b8c in main (argc=1, argv=0x7fffcd0772c8) at main.c:426
>> >
>> > (gdb) step
>> > Single stepping until exit from function g_module_open,
>> > which has no line number information.
>> > plugin_load_module (module_name=0x2b1af53976f1 "afsocket", cfg=0x471e2b0, args=0x0) at plugin.c:207
>> > 207     in plugin.c
>> > (gdb) step
>> > 208     in plugin.c
>> > (gdb) step
>> > 210     in plugin.c
>> > (gdb) step
>> > msg_limit_internal_message () at messages.c:91
>> > 91      in messages.c
>> > (gdb)
>> >
>> >
>> > 201    msg_debug("Trying to open module",
>> > 202              evt_tag_str("module", module_name),
>> > 203              evt_tag_str("filename", plugin_module_name),
>> > 204              NULL);
>> > 205
>> > 206    mod = g_module_open(plugin_module_name, G_MODULE_BIND_LOCAL);
>> > 207    g_free(plugin_module_name);
>> > 208    if (!mod)
>> > 209      {
>> > 210        msg_error("Error opening plugin module",
>> > 211                  evt_tag_str("module", module_name),
>> > 212                  evt_tag_str("error", g_module_error()),
>> > 213                  NULL);
>> > 214        g_free(module_init_func);
>> > 215        return FALSE;
>> > 216      }
>> > 217    g_module_make_resident(mod);
>> >
>> > According to the glib API:
>> >
>> > First of all g_module_open() tries to open file_name as a module. If that
>> > fails and file_name has the ".la"-suffix (and is a libtool archive) it tries
>> > to open the corresponding module. If that fails and it doesn't have the
>> > proper module suffix for the platform (G_MODULE_SUFFIX), this suffix will be
>> > appended and the corresponding module will be opended. If that fails and
>> > file_name doesn't have the ".la"-suffix, this suffix is appended and
>> > g_module_open() tries to open the corresponding module. If eventually that
>> > fails as well, NULL is returned.
>> >
>> > So in order for 210 to get executed to write the message, g_module_open must
>> > have had NULL retval.
>> >
>> > As above, this could happen when:
>> >
>> > opening as a module fails
>> > opening as a module.la fails
>> > opening as a module.platform_suffix fails
>> > opening as a module.platform_suffix.la fails
>> >
>> > The error returned from g_module_error gets output as:
>> >
>> > /home/y/lib64/syslog-ng/libafsocket.so: undefined symbol: libnet_build_ipv4
>> > /home/y/lib64/syslog-ng/libafsql.so: undefined symbol: dbi_result_free
>> >
>> > Wondering what to try now to debug it further.
>> >
>> > Matthew.
>> >
>> > On Tue, Dec 14, 2010 at 11:18:37AM -0800, Matthew Hall wrote:
>> >> Hello,
>> >>
>> >> I'm aware of rpath overall but not an expert at its usage as I have not
>> >> needed it for previous environments I've used. I have been using:
>> >>
>> >> export CFLAGS="-I /home/y/include"
>> >> export LDFLAGS="-Wl,-rpath,/home/y/lib64"
>> >>
>> >> and my libs are:
>> >>
>> >> /home/y/lib64/libnet.so.1.5.0:      ELF 64-bit LSB shared object, AMD x86-64, version 1 (SYSV), stripped
>> >> /home/y/lib64/libdbi.so.1.0.0:      ELF 64-bit LSB shared object, AMD x86-64, version 1 (SYSV), not stripped
>> >> /home/y/lib64/dbd/libdbdmysql.so:   ELF 64-bit LSB shared object, AMD x86-64, version 1 (SYSV), not stripped
>> >> /home/y/lib64/dbd/libdbdsqlite3.so: ELF 64-bit LSB shared object, AMD x86-64, version 1 (SYSV), not stripped
>> >>
>> >> with all the usual symlinks.
>> >>
>> >> The readelf shows the rpath is as follows on each:
>> >>
>> >> Library rpath: [/home/y/lib64]
>> >>
>> >> Strace seems to show that the libnet and libdbi don't get opened
>> >> (whether I follow parent or child syslog-ng).
>> >>
>> >> What could I try next? My thought was perhaps GDB but that will get very
>> >> messy very quickly. :-(
>> >>
>> >> Matthew.
>> >>
>> >> On Tue, Dec 14, 2010 at 02:58:47PM +0100, Sandor Geller wrote:
>> >> > Hello,
>> >> >
>> >> > I don't think this is related to glib at all, sounds like a linker
>> >> > issue due to missing RPATHs.
>> >> >
>> >> > `libnet-config --libs` doesn't give library paths, just outputs
>> >> > '-lnet'. Similarly 'libnet-config --defines' doesn't contain header
>> >> > location so CFLAGS and LDFLAGS should get adjusted by the build
>> >> > environment.
>> >> >
>> >> > I added  "-I<libnet_prefix>/include" to CFLAGS and
>> >> > "-L<libnet_prefix>/lib -Wl,-rpath,<libnet_prefix>/lib" to LDFLAGS.
>> >> >
>> >> > Without the -rpath linker option the app could get built but won't run.
>> >> >
>> >> > Don't know about DBI as I'm not using it. In theory its pkgconfig
>> >> > should contain all needed paths. AFAIK upstream libdbi still doesn't
>> >> > have pkgconfig support so probably a cvs snapshot should get used.
>> >> >
>> >> > hth,
>> >> >
>> >> > Sandor
>> >> >
>> >> > On Tue, Dec 14, 2010 at 6:17 AM, Martin Holste <mcholste at gmail.com> wrote:
>> >> > > Hm, I know I ran into something similar to this a long time ago, but
>> >> > > I'm having a hard time remembering exactly how I fixed it.  I do
>> >> > > believe that it had something to do with needing to install some dev
>> >> > > RPM's, but I don't want to go on record as saying that will definitely
>> >> > > fix this.  Obviously, though, it might be good to triple-check that
>> >> > > you've got -devel on everything.
>> >> > >
>> >> > > Also, since your libs are in a non-standard place, it could also be a
>> >> > > bug in that values that work during the configure step are not getting
>> >> > > passed as macros everywhere they need to be in the make step.  You may
>> >> > > want to try editing your ld.so.conf to include your custom lib
>> >> > > location if you haven't already and running ldconfig -v to make sure
>> >> > > it's being linked.
>> >> > >
>> >> > > Finally, if you're building the dependency libs from source as well,
>> >> > > making sure that there aren't any other "make" steps that need to be
>> >> > > done is another one to check off.  I believe some libs need "make
>> >> > > shared" (libpcap, for one).
>> >> > >
>> >> > > I don't know if any of these will fix the problem, but they can't hurt
>> >> > > to verify.
>> >> > >
>> >> > > On Mon, Dec 13, 2010 at 8:12 PM, Matthew Hall <mhall at mhcomputing.net> wrote:
>> >> > >> I am getting the following on load:
>> >> > >>
>> >> > >> Error opening plugin module; module='afsocket', error='/home/y/lib64/syslog-ng/libafsocket.so: undefined symbol: libnet_build_ipv4'
>> >> > >> Error opening plugin module; module='afsql', error='/home/y/lib64/syslog-ng/libafsql.so: undefined symbol: dbi_result_free'
>> >> > >> Error opening plugin module; module='afsocket', error='/home/y/lib64/syslog-ng/libafsocket.so: undefined symbol: libnet_build_ipv4'
>> >> > >>
>> >> > >> The rpath looks OK:
>> >> > >>
>> >> > >> megahall at logproxy2:~$ readelf -a /home/y/lib64/syslog-ng/libafsocket.so | fgrep -i rpath
>> >> > >>  0x000000000000000f (RPATH)              Library rpath: [/home/y/lib64]
>> >> > >> megahall at logproxy2:~$ readelf -a /home/y/lib64/syslog-ng/libafsql.so | fgrep -i rpath
>> >> > >>  0x000000000000000f (RPATH)              Library rpath: [/home/y/lib64]
>> >> > >> megahall at logproxy2:~$
>> >> > >>
>> >> > >> megahall at logproxy2:~$ ldd /home/y/lib64/syslog-ng/libafs* | fgrep -i '(dbi|net)'
>> >> > >> megahall at logproxy2:~$
>> >> > >>
>> >> > >> The libraries are in a reasonable location:
>> >> > >>
>> >> > >> /home/y/lib64/libdbi.so.1.0.0
>> >> > >> /home/y/lib64/libnet.so.1.5.0
>> >> > >> /home/y/lib64/dbd/libdbdsqlite3.so
>> >> > >> /home/y/lib64/dbd/libdbdmysql.so
>> >> > >> /home/y/lib64/libnet.so.1
>> >> > >> /home/y/lib64/libdbi.so.1
>> >> > >> /home/y/lib64/libdbi.so
>> >> > >>
>> >> > >> Reading through the glib docs for glib modules, it seems like the .la
>> >> > >> files are maybe not containing the right library dependencies, or
>> >> > >> something like this. However adding the library directories using
>> >> > >> LD_LIBRARY_PATH as a temporary test does not help.
>> >> > >>
>> >> > >> Because this step fails, it's not possible to use tcp, udp, or any of
>> >> > >> the other important drivers you need to collect logs.
>> >> > >>
>> >> > >> I could really use some advice on this one!
>> >> > >>
>> >> > >> Matthew.
>> >> > >> ______________________________________________________________________________
>> >> > >> Member info: https://lists.balabit.hu/mailman/listinfo/syslog-ng
>> >> > >> Documentation: http://www.balabit.com/support/documentation/?product=syslog-ng
>> >> > >> FAQ: http://www.campin.net/syslog-ng/faq.html
>> >> > >>
>> >> > >>
>> >> > > ______________________________________________________________________________
>> >> > > Member info: https://lists.balabit.hu/mailman/listinfo/syslog-ng
>> >> > > Documentation: http://www.balabit.com/support/documentation/?product=syslog-ng
>> >> > > FAQ: http://www.campin.net/syslog-ng/faq.html
>> >> > >
>> >> > >
>> >> > ______________________________________________________________________________
>> >> > Member info: https://lists.balabit.hu/mailman/listinfo/syslog-ng
>> >> > Documentation: http://www.balabit.com/support/documentation/?product=syslog-ng
>> >> > FAQ: http://www.campin.net/syslog-ng/faq.html
>> >> >
>> >> ______________________________________________________________________________
>> >> Member info: https://lists.balabit.hu/mailman/listinfo/syslog-ng
>> >> Documentation: http://www.balabit.com/support/documentation/?product=syslog-ng
>> >> FAQ: http://www.campin.net/syslog-ng/faq.html
>> >>
>> > ______________________________________________________________________________
>> > Member info: https://lists.balabit.hu/mailman/listinfo/syslog-ng
>> > Documentation: http://www.balabit.com/support/documentation/?product=syslog-ng
>> > FAQ: http://www.campin.net/syslog-ng/faq.html
>> >
>> >
>> ______________________________________________________________________________
>> Member info: https://lists.balabit.hu/mailman/listinfo/syslog-ng
>> Documentation: http://www.balabit.com/support/documentation/?product=syslog-ng
>> FAQ: http://www.campin.net/syslog-ng/faq.html
>>
> ______________________________________________________________________________
> Member info: https://lists.balabit.hu/mailman/listinfo/syslog-ng
> Documentation: http://www.balabit.com/support/documentation/?product=syslog-ng
> FAQ: http://www.campin.net/syslog-ng/faq.html
>
>

More information about the syslog-ng mailing list