Bug #469
Rails support reopens the log file and database on every connection
| Status: | Closed | Start date: | ||
|---|---|---|---|---|
| Priority: | Normal | Due date: | ||
| Assignee: | % Done: | 0% |
||
| Category: | Rails | |||
| Target version: | 0.25.0 | |||
| Affected Puppet version: | 0.24.4 | Branch: | ||
| Keywords: | ||||
| Votes: | 0 |
Description
I got ‘too many open files’ because of this, and when I checked the open file list with lsof, there were tens or hundreds of copies of the log and sqlite filehandles.
I’m going to hold this until grover since it’s just a server-side error and the Rails support is still explicitly experimental, but it should clearly be solved.
History
Updated by Blake Barnett almost 5 years ago
Possible fix in svn rev 2217
Updated by Blake Barnett almost 5 years ago
After further testing, this apparently doesn’t fix it completely. It just slows the accumulation of open sockets/file handles.
I guess we’ll need to find the spot (or spots) where all the storeconfigs and export/collection operations finish, and close each connection explicitly. Alternately, we may also be able to wrap all the rails code in something that ensures that all threads using rails use the same connection handle, this is probably the best approach, but it’s also the one that requires the most intimate knowledge of puppet internals.
Updated by Adrian Bridgett almost 4 years ago
This seems better, but still leaking on the sqlite (debian package 0.24.1-2, rails 1.1.6-3)
1
3 /dev/null
1 /dev/urandom
1 /etc/group
1 /etc/passwd
2 pipe:r29756375
1 socket:r29756390
1 socket:r29756393
1008 /var/lib/puppet/state/clientconfigs.sqlite3
3 /var/log/puppet/masterhttp.log
1 /var/log/puppet/rails.log
This looks related: http://blog.moertel.com/articles/2006/08/24/database-connection-leak-in-typo-4-0-3-problem-solved
It leaks by 1 FD each node run, with the patch below it stops leaking. I’ll leave this running for a little while. I don’t know what unexpected side effects this may have.
—– /usr/lib/ruby/1.8/puppet/rails.rb.orig 2008-03-27 10:08:54.000000000 +0000 +++ /usr/lib/ruby/1.8/puppet/rails.rb 2008-03-27 10:07:26.000000000 +0000 @@ -21,7 +21,7 @@
[[ActiveRecord]]::Base.logger.level = Logger::DEBUG
end
[[ActiveRecord]]::Base.allow_concurrency = true[[ActiveRecord]]::Base.allow_concurrency = false [[ActiveRecord]]::Base.verify_active_connections! begin
Updated by Adrian Bridgett almost 4 years ago
let’s try that again, remembering the formatting this time (can’t see an edit unfortunately)
This seems better, but still leaking on the sqlite (debian package 0.24.1-2, rails 1.1.6-3)
3 /dev/null 1 /dev/urandom 1 /etc/group 1 /etc/passwd 2 pipe:r29756375 1 socket:r29756390 1 socket:r29756393 1008 /var/lib/puppet/state/clientconfigs.sqlite3 3 /var/log/puppet/masterhttp.log 1 /var/log/puppet/rails.log
This looks related: http://blog.moertel.com/articles/2006/08/24/database-connection-leak-in-typo-4-0-3-problem-solved
It leaks by 1 FD each node run, with the patch below it stops leaking. I’ll leave this running for a little while. I don’t know what unexpected side effects this may have.
--- /usr/lib/ruby/1.8/puppet/rails.rb.orig 2008-03-27 10:08:54.000000000 +0000
+++ /usr/lib/ruby/1.8/puppet/rails.rb 2008-03-27 10:07:26.000000000 +0000
@@ -21,7 +21,7 @@
[[ActiveRecord]]::Base.logger.level = Logger::DEBUG
end
- [[ActiveRecord]]::Base.allow_concurrency = true
+ [[ActiveRecord]]::Base.allow_concurrency = false
[[ActiveRecord]]::Base.verify_active_connections!
begin
Updated by Redmine Admin over 3 years ago
- Status changed from 1 to Accepted
Updated by Adrian Bridgett over 3 years ago
- Affected Puppet version set to 0.24.4
Still being bitten by this, checked for an update and indeed, it’s a bug in activerecord: http://github.com/rails/rails/commit/7359dc0028b87f948d188f5fa6bb366a49181a81 (sqlite adapter wasn’t performing disconnect)
I’ve turned allow_concurrency back on and no leaks :–)
So not a puppet bug, but a requirement for a fixed version of activerecord (v2.0.0)
Updated by Luke Kanies over 3 years ago
- Status changed from Accepted to Closed
Awesome, then I’ll close it as a fixed upstream bug. Thanks!