Ruby segmentation fault on Solaris Sparc
(No Ratings Yet)
Loading ...Recently I’ve been running puppet a *lot* on Solaris 10 (Sparc). I would say consistently around 50% of the time the following happens:
bash-3.00# /usr/local/bin/puppetd -t notice: Ignoring cache /opt/ruby/lib/ruby/1.8/timeout.rb:52: [BUG] Segmentation fault ruby 1.8.6 (2007-09-24) [sparc-solaris2.10] Abort (core dumped)
Though this has been causing me to get very frustrated with puppet, and indeed it has made the adoption of puppet within the organisation more problematic than it should have been, I realise this is unfair on puppet as the problem seems to be with the ruby jvm. We have not seen this type of behaviour with puppet on Linux or indeed with the Solaris x86 port. Maybe ruby can’t handle the 32 cores of our T2000.
I’m hoping with the release of a later version, either 1.8.7 or the developer release of 1.8.9 that these problems disappear. So a question:
Has anyone else experienced this type of segmentation fault with ruby?
June 6th, 2008 at 8:26 pm
Does puppet work with jruby?
June 7th, 2008 at 6:10 pm
Jason,
I seem to remember coming across the exact same problem last summer when we were originally testing puppet on the sparcs. Seem to recollect I found a solution, although it escapes me atm.
Is ruby compiled the same way as before?
Try
June 9th, 2008 at 7:44 am
Why not just use JRuby? It is 100% compatible with MRI, and also faster (and more stable). MRI is no longer implemented after Ruby 1.8.x, so you’ll have to move to an alternative VM anyway. MRI is widely recognised as being pretty flakey.
June 9th, 2008 at 5:48 pm
JRuby does not fully support all of the Ruby standard libraries.
If you cross reference the list of prerequisites for puppet http://www.reductivelabs.com/trac/puppet/wiki/InstallationGuide with what is supported for JRuby http://wiki.jruby.org/wiki/Ruby_Standard_Libraries only 1 of the 13 libraries (fileutils) is listed as complete. OpenSSL is absent and Webrick is listed as partial; the rest are unknown.
Testing puppet using JRuby may be worth a go, but I’d be cautious about using an unsupported Ruby implementation as a runtime for a tool which automates the configuration of multiple servers.
June 10th, 2008 at 3:14 am
I saw some discussion of this issue on #puppet on freenode IRC the other day — I think the conclusion of the discussion was “use a more recent ruby”… so I guess give the developer release a go.