On 20/03/10 02:51, Nigel Kersten wrote:
> So this seemed worth another thread given the significant progress...
> just about all done by Brice as usual.... :)
>
> With jruby 1.4.0 and jetty-rackup from
> http://github.com/geekq/jetty-rackup and a simple config.ru file that
> looks like:
I'm using without issue:
jruby 1.5.0.dev (ruby 1.8.7 patchlevel 174) (2010-03-08 1cc36d4)
> -----------------
> $0 = "puppetmasterd"
> require 'puppet'
>
> ARGV << "--verbose"
> #ARGV << "--debug"
> #ARGV << "--trace"
> # I have a special config file for my servers
> ARGV << "--config" << "/etc/puppet/puppetmasterd.conf"
> ARGV << "--no-daemonize"
> ARGV << "--user" << "puppet"
> ARGV << "--no-ca"
>
> ARGV << "--rack"
> require 'puppet/application/puppetmasterd'
> # we're usually running inside a Rack::Builder.new {} block,
> # therefore we need to call run *here*.
> run Puppet::Application[:puppetmasterd].run
> -----------------
>
> then this little modification to jetty-rackup
> -----------------
> jetty = org.mortbay.jetty.Server.new options[:Port]
> # next 3 lines are new
> jetty.get_connectors.each do |c|
> c.set_header_buffer_size 8192
> end
> -----------------
I was about to send you this one :-) but you figured out it.
> and we have something that almost works.
>
> err: Could not retrieve catalog: Uncaught exception fork is unsafe and
> disabled by default on JRuby in method puppetmaster.getconfig
It's strange I don't get that.
Maybe we could rewrite Puppet::Util#execute for jruby to use the JVM
execute instead of forking.
> I've enabled forking.... -J-Djruby.fork.enabled=true and crossed my
> fingers... oh look at all this...
>
> WARNING: fork is highly unlikely to be safe or stable on the JVM. Have fun!
> WARNING: fork is highly unlikely to be safe or stable on the JVM. Have fun!
> WARNING: fork is highly unlikely to be safe or stable on the JVM. Have fun!
>
> and we blow up earlier than we did before... Tried the latest HEAD,
> it was completely broken, so reverted to a few commits earlier, and
> made some progress... but then the actual forking looks to fail.
>
> info: Autoloaded module base
> debug: Puppet::Type::Package::ProviderRpm: Executing '/usr/bin/rpm --version'
> Could not autoload rpm: No child processes - No child processes
OK, in fact looking harder, I have this call to execute, but it fails in
my JRuby version without impacting the compilation itself.
In fact the issue comes from this code from the rpm provider:
if command('rpm')
confine :true => begin
rpm('--version')
rescue Puppet::ExecutionFailure
false
else
true
end
end
This code is executed because each type when compiling is asked if it's
a builtin type, which in turn autoload each provider, which in turn
executes such "global" code (ie checking confine).
I don't think it is necessary to autoload the providers (type should be
enough for the master, isn't it?), but I'm afraid it isn't possible.
Anyway if you checkout jruby 1cc36d4 and use the default option you get
a nice stack trace but no failure of the compilation :-)
> It looks like we only fork in three places in Puppet for what it's worth.
Yes, it's:
- when daemonizing which you and I are not doing
- when executing (or generate)
- in puppetrun
I think execute should be rewritten to use the JVM Runtime.exe or
ProcessBuilder for JRuby, instead of forking. I'll see if I can come
with a patch later in the week-end.
--
Brice Figureau
My Blog: http://www.masterzen.fr/
--
You received this message because you are subscribed to the Google Groups
"Puppet Developers" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to
[email protected].
For more options, visit this group at
http://groups.google.com/group/puppet-dev?hl=en.
