FAQ
I am experiencing the same problem with a 3.0.1 install.

If I set "enable_inventory_service: false" there are no problems.

ruby: symbol lookup error:
/usr/lib/ruby/gems/1.8/gems/json-1.5.1/ext/json/ext/json/ext/parser.so:
undefined symbol: RSTRING_PTR

ruby 1.8.7 (2012-06-29 patchlevel 370) [x86_64-linux]

# ldd /usr/lib/ruby/gems/1.8/gems/json-1.5.1/ext/json/ext/json/ext/parser.so
linux-vdso.so.1 => (0x00007fff7f920000)
libruby.so.1.8 => /usr/lib64/libruby.so.1.8 (0x00002aeccf1a9000)
libpthread.so.0 => /lib64/libpthread.so.0 (0x00002aeccf4a7000)
libdl.so.2 => /lib64/libdl.so.2 (0x00002aeccf6c3000)
libcrypt.so.1 => /lib64/libcrypt.so.1 (0x00002aeccf8c7000)
libm.so.6 => /lib64/libm.so.6 (0x00002aeccfaff000)
libc.so.6 => /lib64/libc.so.6 (0x00002aeccfd83000)
librt.so.1 => /lib64/librt.so.1 (0x00002aecd00da000)
libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x00002aecd02e3000)
/lib64/ld-linux-x86-64.so.2 (0x00002aecced7c000)

uname -a
Linux Internal-puppet-master 2.6.18-308.20.1.el5xen #1 SMP Tue Nov 13
11:03:56 EST 2012 x86_64 x86_64 x86_64 GNU/Linux
On Tuesday, November 27, 2012 1:41:17 PM UTC-8, jcbollinger wrote:


On Tuesday, November 27, 2012 9:53:35 AM UTC-6, alaric wrote:


On Nov 27, 2012, at 9:57 AM, Alaric wrote:


On Nov 27, 2012, at 9:45 AM, jcbollinger wrote:


On Tuesday, November 27, 2012 8:27:37 AM UTC-6, Matthew Burgess wrote:
On Tue, Nov 27, 2012 at 2:09 PM, Alaric wrote:
Yup, I get the same error:

/usr/bin/ruby: symbol lookup error:
/usr/lib64/ruby/site_ruby/1.8/x86_64-linux/json/ext/parser.so: undefined
symbol: RSTRING_PTR

My one thought is that maybe my version stdlib is old... I checked and
it's version 2.3.1 I'll give it an upgrade and see if that helps, it's just
weird that on the RHEL6 servers nothing seems off.

This looks like your version of Ruby is too old.

RSTRING_PTR was added to Ruby-1.8.6, but RHEL5 and its clones only
provide Ruby-1.8.5. I use Ruby-1.8.7 available from
http://yum.theforeman.org/development/el5/x86_64/.
That makes sense, somewhat. It would constitute a pretty weird packaging
issue, because rpmbuild normally does a very good job of identifying
library version dependencies, and yum and rpm are very reliable about
ensuring dependencies are installed (unless you start overriding them, in
which case all bets are off).

Do you have more than one version of Ruby installed on the affected
systems?


John



Only the one version that I can find! her's a list of the installed ruby
packages

libselinux-ruby-1.33.4-5.7.el5
ruby-1.8.7.370-1.el5
ruby-augeas-0.4.1-1.el5
ruby-devel-1.8.7.370-1.el5
ruby-devel-1.8.7.370-1.el5
rubygem-json-1.4.6-1.el5
rubygems-1.3.7-1.el5
rubygem-stomp-1.2.2-1.el5
rubygem-systemu-1.2.0-3.el5
ruby-irb-1.8.7.370-1.el5
ruby-libs-1.8.7.370-1.el5
ruby-libs-1.8.7.370-1.el5
ruby-mysql-2.7.3-2
ruby-rdoc-1.8.7.370-1.el5
ruby-shadow-1.4.1-7.el5



I did like the idea that gems might have been conflicting, and actually
did find some hiera gems installed, after removing those and reinstalling I
still get the same error, but I'm going through the package list with a
fine tooth comb and verifying installs now...

All I get with find now is this:, which I think is just a cache of the
json gem, would that actually have any effect?


find /usr/lib{,64}/ruby -type f -exec rpm -q -f {} \; | grep "not owned"
file /usr/lib/ruby/gems/1.8/cache/json-1.6.6.gem is not owned by any
package



Swing and a miss... even after verifying and manually removing any gems,
and any cached gems, reinstalling effected packages and verifying, I still
get the same error...

Things to try:

Run the affected shared object
(/usr/lib64/ruby/site_ruby/1.8/x86_64-linux/json/ext/parser.so) through
ldd. Look for any library dependencies that cannot be resolved, and look
carefully for the possibility that one or more lingering Ruby 1.8.5
libraries are being linked in place of the libraries from your v 1.8.7
installation.

Run ldconfig to ensure that the dynamic linker's cache is up to date
(though any package that installs libraries ought to do this in its
post-install script).

Check the output of "ruby --version".

Check the agent's startup script for a reference to a non-standard ruby
binary.

Consider a ground-up wipe-and-rebuild of one of your affected systems,
making sure to install only RPM-packaged software (no gems, especially).
Check whether the rebuilt system is still affected. (If it is, then there
is definitely a packaging problem somewhere.)


John
--
You received this message because you are subscribed to the Google Groups "Puppet Users" group.
To view this discussion on the web visit https://groups.google.com/d/msg/puppet-users/-/8trq3fLV-1QJ.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to puppet-users+unsubscribe@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.

Search Discussions

Discussion Posts

Previous

Follow ups

Related Discussions

Discussion Navigation
viewthread | post
posts ‹ prev | 13 of 24 | next ›
Discussion Overview
grouppuppet-users @
categoriespuppet
postedNov 23, '12 at 10:46p
activeDec 14, '12 at 2:51p
posts24
users8
websitepuppetlabs.com

People

Translate

site design / logo © 2022 Grokbase