[syslog-ng] load failures in afsocket and afsql

Matthew Hall mhall at mhcomputing.net
Tue Dec 14 21:41:21 CET 2010 

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
>

More information about the syslog-ng mailing list