古いバージョン(1.2.6)ではこの問題は起こらなかったのですが、
ubuntu-11.04の1.4.5では、しばらく使っていると/tmp/tmp.XXXXX
というディレクトリが大量に残るという問題があるようです。
調べてみたのですが、あまり似たような報告がなかったので、
特定の条件が揃った場合だけ発生する問題なのかもしれません。

とりあえず、以下のような力技で対処。

cleanup_munin_tmp

ruby>>
#!/usr/bin/env ruby
require "etc"

Dir['/tmp/tmp.*'].each do |path|
uid = Etc.getpwuid(File.stat(path).uid).name
gid = Etc.getgrgid(File.stat(path).gid).name
next if uid != 'nobody'
next if gid != 'munin'
system "rmdir --ignore-fail-on-non-empty #{path}"
end
<<--

これをcronで@hourlyに実行してます。

追記

シェルスクリプト版も用意してみました。

sh>>
#!/bin/sh

for d in /tmp/tmp.*
do
if [ stat -c %U $d = "nobody" ]
then
if [ stat -c %G $d = "munin" ]
then
rmdir --ignore-fail-on-non-empty $d
fi
fi
done
<<--

CUDA 3.0がリリースされましたが、今回からOpenCL SDKも同梱されて /Developer/GPU Computing/OpenCL にインストールされるようになりました。

CUDA ("C"ディレクトリの中身)はmakeでsampleが普通にビルドできたのですが、OpenCLの方は以下のようなエラーが出ます。

pre>>
src/oclUtils.cpp: In function ‘void oclPrintDevInfo(int, _cl_device_id*)’:
src/oclUtils.cpp:282: error: ‘CL_DEVICE_COMPUTE_CAPABILITY_MAJOR_NV’ was not declared in this scope
src/oclUtils.cpp:283: error: ‘CL_DEVICE_COMPUTE_CAPABILITY_MINOR_NV’ was not declared in this scope
src/oclUtils.cpp:290: error: ‘CL_DEVICE_REGISTERS_PER_BLOCK_NV’ was not declared in this scope
src/oclUtils.cpp:294: error: ‘CL_DEVICE_WARP_SIZE_NV’ was not declared in this scope
src/oclUtils.cpp:298: error: ‘CL_DEVICE_GPU_OVERLAP_NV’ was not declared in this scope
src/oclUtils.cpp:302: error: ‘CL_DEVICE_KERNEL_EXEC_TIMEOUT_NV’ was not declared in this scope
src/oclUtils.cpp:306: error: ‘CL_DEVICE_INTEGRATED_MEMORY_NV’ was not declared in this scope
make: *** [obj/release/oclUtils.cpp.o] Error 1
<<--

これらの定数はSDK同梱のcommon/inc/cl_ext.h の中で定義されているのですが、どうやら
/System/Library/Frameworks/OpenCL.framework/Headers の方を参照してしまっているようで、こちらには定数が定義されていないようです。

まだリリースされて間もないせいか、
NVIDIAのOpenCL SDKを使っていると不可解なエラーに遭遇します。
掲題のようなエラーメッセージを出すのもその一例ですが、
以下のようなコード（一部抜粋）でエラーがでます。

c>>
float4 x = sphere->c;
dg->t = x.x;
<<--

しかし以下のように記述すると大丈夫です。

c>>
float x = sphere->c.x;
dg->t = x;
<<--

OpenCLコンパイラが生成したptxコードの中に'selp'というのが入るような場合に問題が発生するようです。

NVIDIAのOpenCL SDKの場合、*.clファイルをCLコンパイラがコンパイルして、ptxという中間言語に変換します。さらに、ptxをptxparse（PLANGというパッケージの一部らしい）が解析してllvmのbcに変換します。
このケースでは、CLコンパイラが吐き出すコードと、ptxparse側の認識が一致していない感じです。
とりあえず、バグが直るまでコンパイラの気持ちになって回避するしかありません。

昨日からmasuidriveさんと調査してた
eventmachineのバグ
ですが、straceで追いかけてみた結果、
以下の部分が原因である事が分かりました。

em.cpp EventMachine_t::_RunEpollOnce() の最後付近

c>>
timeval tv = {0,0};
EmSelect (0, NULL, NULL, NULL, &tv); // <- これ

return true;
<<--

見るからにWorkaroundっぽいですね。

straceの結果では、正常に実行されてる場合には
ADDからEPOLLINまでのシステムコール呼び出しが以下のような感じなのに対して、

pre>>
write(1, "************** epoll-add: 0.0377"..., 39************** epoll-add: 0.03
7784 - 8
) = 39epoll_ctl(6, EPOLL_CTL_ADD, 8, {EPOLLIN, {u32=138272384, u64=1323936545317780646
4}}) = 0
epoll_wait(6, {{EPOLLIN, {u32=138272384, u64=13239365453177806464}}}, 65536, 50)
= 1
gettimeofday({1230425221, 603705}, NULL) = 0
write(1, "************** epoll-read: 0.020"..., 40************** epoll-read: 0.0
20716 - 8
<<--

異常時には以下のように謎のselectが発生していました。

pre>>
write(1, "************** epoll-add: 0.0295"..., 39************** epoll-add: 0.029586 - 8
) = 39
epoll_ctl(6, EPOLL_CTL_ADD, 8, {EPOLLIN, {u32=138272384, u64=1323936545317780646
4}}) = 0
epoll_wait(6, {}, 65536, 50) = 0
select(0, NULL, NULL, NULL, {0, 0}) = 0 (Timeout)
time(NULL) = 1230425221
gettimeofday({1230425221, 787115}, NULL) = 0
epoll_wait(6, {}, 65536, 50) = 0
select(0, NULL, NULL, NULL, {0, 0}) = 0 (Timeout)time(NULL) = 1230425221
gettimeofday({1230425221, 839105}, NULL) = 0
epoll_wait(6, {{EPOLLIN, {u32=138272384, u64=13239365453177806464}}}, 65536, 50) = 1
gettimeofday({1230425221, 843713}, NULL) = 0
write(1, "************** epoll-read: 0.110"..., 40************** epoll-read: 0.1
10337 - 8
<<--

どうやらこの謎のEmSelect呼び出しはビジーループ対策のために
挿入されているらしいのですが、以下のような形に直すと問題が
発生しなくなるようです。

c>>
//timeval tv = {0,0};
//EmSelect (0, NULL, NULL, NULL, &tv);
#ifdef BUILD_FOR_RUBY
if (!rb_thread_alone()) {
rb_thread_schedule();
}
#endif
<<--

eventmachineのticketにpatchが上がっている
ので、近いうちに修正されるかもしれません。

ということで、ひとまずお疲れさまでしたー＞masuidriveさん

原因については調査し切れていないのですが、何らかの理由で
RubyGemsをインストールしたときに、Gemのバージョン番号の末尾に
本来あるはずの無い「-」がついた状態でインストールされてしまう
事があるようです。

この問題が発生すると、「-」が付加されたバージョンのGemの存在が
正しく認識されず、ひとつ古いバージョンが中途半端にactivateされて
しまい、全体としてアプリケーションが正常に動作しなくなる
事があるようです。

一旦問題の発生しているGemを削除してから、再度インストールを
行うことで問題は解決しますが、gem uninstallコマンドでは
正常にアンインストールが行われない場合もあるようです。
その場合は、RubyGemsがインストールされているディレクトリ
（/usr/local/lib/ruby/gems/1.8/gems/など）から手作業で
該当するファイル群を削除する必要があるかもしれません。

こちら
で、ExceptionNotifierプラグインのテンプレートに関するバグの報告が出ていました。

Plugins - Exception Notifier

Brett Neumeier 12 Oct 2007

In ruby 1.8.6p111, rendering the _environment.rhtml plugin fails with "TemplateError: flag after width". This is fixed if you change the string "%-s" to "%-s" on line three of the template.

Chris 18 Oct 2007

This is the correct string: "%-*s:"

具体的には、views/exception_notifier/_environment.rhtml の3行目を次のように修正すればOKのようです。

views/exception_notifier/_environment.rhtml

<% max = @request.env.keys.max { |a,b| a.length <=> b.length } -%>
<% @request.env.keys.sort.each do |key| -%>
* <%= "%-*s: %s" % [max.length, key, filter_sensitive_post_data_from_env(key, @request.env[key].to_s.strip)] %>
<% end -%>

手元の環境（ruby-1.8.6 p36/Rails-1.99.0）では、これで問題なく動作するようになりました。

Rails 2.0 RC1を使うようになったせいかどうかはわからないのですが、何故か僕の環境では acts_as_taggable_on_steroids のplugin testでFailureが一つ出るようになっていたので、修正してみました。

こんなエラーが出る

  1) Failure:
test_tag_destroyed_when_unused(ActsAsTaggableOnSteroidsTest)
    [./test/abstract_unit.rb:81:in \`assert_difference'
     /home/takiuchi/blog/vendor/rails/activerecord/lib/active_record/\
callbacks.rb:309:in \`each_with_index'
     ./test/abstract_unit.rb:80:in \`each'
     ./test/abstract_unit.rb:80:in \`each_with_index'
     ./test/abstract_unit.rb:80:in \`assert_difference'
     ./test/acts_as_taggable_test.rb:328:in \`test_tag_destroyed_when_unused']:
<5> expected but was
<6>.

修正箇所は以下のとおり。

vendor/plugins/acts_as_taggable_on_steroids/lib/acts_as_taggable.rb (L167-184)

ruby>>
def save_tags
return unless @tag_list

  new_tag_names = @tag_list - tags.map(&:name)
  old_tags = tags.reject { |tag| @tag_list.include?(tag.name) }

  self.class.transaction do
    tags.delete(*old_tags) if old_tags.any?
    # added by takiuchi to make all tests green.
    old_tags.each{|tag| tag.destroy} if Tag.destroy_unused
      new_tag_names.each do |new_tag_name|
      tags << Tag.find_or_create_with_like_by_name(new_tag_name)
    end
  end

  true
end

<<--

Tag.destroy_unused が指定されている場合、old_tags を destroy
するようにしました。これで上記の Failure は出なくなりました。

acts_as_taggable_on_steroids
はacts_as_taggableを強化したRailsプラグインで、非常に便利なので愛用しています。

しかし、find_tagged_withメソッドで OR を含む :conditions を指定すると、SQLの演算順序の問題で挙動がおかしくなります。
この問題を修正するには、以下のようにpluginコードを書き換えればOKです。

acts_as_taggable_on_steroids/lib/acts_as_taggable.rb

    def find_options_for_find_tagged_with(tags, options = {})
      tags = tags.is_a?(Array) ? TagList.new(tags.map(&:to_s)) : TagList.from(tags)
      options = options.dup

      return {} if tags.empty?

      conditions = []
      #conditions << sanitize_sql(options.delete(:conditions)) if options[:conditions]
      if options[:conditions]
        conditions << "(#{sanitize_sql(options.delete(:conditions))})"
      end

要は、オリジナルの :conditions を括弧で括って演算順序の問題が起きないようにしているわけですね。