I'll try and find the bug in a second, but apparently the lack of any
return codes from /etc/init.d/foo status when a service has been
upstarted is a bug.
Ultimately I feel puppet needs an initctl based service provider.
--
puppet in lucid does not support upstart status
To clarify, assuming the status situation with upstarted init.d scripts
is resolved, I don't see any major reason why the existing provider
wouldn't continue to at least function well enough for users?
The update-rc situation isn't ideal, which is why I suggested an initctl
based provider, which
I'll try and find the bug in a second, but apparently the lack of any
return codes from /etc/init.d/foo status when a service has been
upstarted is a bug.
Ultimately I feel puppet needs an initctl based service provider.
--
puppet in lucid does not support upstart status
To clarify, assuming the status situation with upstarted init.d scripts
is resolved, I don't see any major reason why the existing provider
wouldn't continue to at least function well enough for users?
The update-rc situation isn't ideal, which is why I suggested an initctl
based provider, which
Are we even sure pthreads is central to the issue?
I've been a bit flat out which is why I disappeared in this bug history,
but I'll see if I can get some more concrete info this week.
--
building ruby1.8 with pthread support causes puppet hangs
https://bugs.launchpad.net/bugs/520715
You
Sorry, I wasn't clear again :)
I understand how the code works, I was pointing out that if something
this trivial isn't working there is something fundamental broken with
Thread.status, Thread.alive? etc.
--
building ruby1.8 with pthread support causes puppet hangs
Sorry, I should have made this clearer.
I work with Joel and Andrew, and am responsible for the Puppet
infrastructure here.
I spent a while debugging what was causing Facter and/or Puppet to hang,
and it all came down to the calls being wrapped in Timeout.
I did reproduce this on Debian Testing
PS. I'm open to the possibility libc is at fault. The patch Joel linked
to earlier:
http://svn.ruby-lang.org/cgi-
bin/viewvc.cgi/branches/ruby_1_8_7/eval.c?r1=23997r2=24104diff_format=l
worries me a little with line # 12319
--
building ruby1.8 with pthread support causes puppet hangs
I did verify the issue exists on the latest stock Lucid, but didn't dig
this deeply at the time I did that. It will be interesting to see
whether I get the same behavior pattern as Lucid + Google stuff or
Debian testing.
We'll get some more data in soon.
--
building ruby1.8 with pthread
I had a quick look at Timeout. The problem is there in:
x = Thread.current
y = Thread.start {
sleep sec
x.raise exception, execution expired if x.alive?
}
and Thread x.status returns a sleep state even after the test execs
complete, which seems pretty
So this isn't a Puppet bug at all.
It looks to be a bug in the Ruby Timeout module that seems to be
triggered when most of your cores are busy.
I can reliably reproduce it by firing up openssl speed (n-1) times where
n is the number of cores and then using the Timeout module.
#!/usr/bin/ruby1.8
Lucas, I'm going to work on a reproducible case that doesn't involve
Puppet at all.
I do believe Puppet is triggering a more fundamental problem, but agree
we need to clearly demonstrate this.
--
building ruby1.8 with pthread support causes puppet hangs
https://bugs.launchpad.net/bugs/520715
According to Matz, this is no longer an issue in Ruby 1.8.7
http://blade.nagaokaut.ac.jp/cgi-bin/scat.rb/ruby/ruby-core/23583
yet I'm still seeing performance improvements in general with the ruby
benchmark suite when applying the configure.in patch from
timetobleed.com against 1.8.7 from
13 matches
Mail list logo
