too-large rpm hangs when processed #52
Comments
|
@jordansissel Do you have any insight into whether prm is calling arr-pm incorrectly, or this is an internal arr-pm bug? |
|
Hi @trel sorry for my reply being so late! I think this is a bug in arr-pm, but it might be due to this payload assignment here: https://github.com/jordansissel/ruby-arr-pm/blob/master/lib/arr-pm/file.rb#L208 How large is the list in the rpm? Any chance you could provide me with a sample rpm (something at the least similar to your RPM)? |
|
The list is 97k lines long: first of the file list last of the file list I've been generating an EPM list file with this script... Then generating an RPM via EPM The RPM will then be local A sample file can be found here for 30 days... This will hang when processed by prm (with the new -d option, but should be irrelevant here) I've instrumented arr-pm with the following $ git diff -w
diff --git a/arr-pm.gemspec b/arr-pm.gemspec
index 4645b97..d515237 100644
--- a/lib/arr-pm/file.rb
+++ b/lib/arr-pm/file.rb
@@ -204,17 +204,26 @@ class RPM::File
end
payload_fd = payload.clone
output = ""
+ count = 0
loop do
+ count += 1
data = payload_fd.read(16384, buffer)
break if data.nil? # listerextractor.write(data)
+ puts "#{count} write begin #{data.length}"
lister.write(data)
+ puts " write complete"
# Read output from the pipe.
+ puts " read begin"
begin
+ puts " reading..."
output << lister.read_nonblock(16384)
rescue Errno::EAGAIN
# Nothing to read, move on!
+ puts " ---- SKIPPING"
end
+ puts " read complete"
end
lister.close_write |
|
Hey @trel I couldn't get an EPM build to work. I'll have an strace of the EPM error, but it essentially said it couldn't build the package. I'll try with an FPM build later! |
|
thanks, a large enough fpm-produced package should hit this as well. in the meantime, we've got a local temporary workaround with rpm2cpio. |
|
@trel definitely replicated with an fpm produced package. Hoping to dig in more tonight |
|
excellent news. |
|
I've looked a bit more and it is definitely an issue on that arr-pm side, or at least that's where it's hitting. I tested a few different things, but it looks like lowering the string length size, I was able to build out a repo with a RPM that had 95000+ files in it. My guess is that the pipe for the IO object is not being flushed, or is too small, for the type of content we're throwing at it - but again that's a guess. I tried various sizes for the string lengths, 8000, 1000, 500, 100, and 10 I can't imagine @jordansissel will want to reduce the read string length from 16k to 1, it takes quite a bit of time to generate the repository for a single package due to that. I was able to build the repository after changing the string length to 1 and adding in some stdout content (puts "test") into my arr-pm library. |
|
I was also able to get the original code to work with extra Lowering the buffer size did not seem to help for me, even when set to 1. |
|
@trel so while it does look like the pipe size is the issue on the read, there's not much more for me to go on unfortunately. I've kinda tapped my expertise, but yea it's definitely an arr-pm issue |
|
I'll file an issue and point back here. Thanks @dnbert |
|
Hm, I was interested in possibly using this for Zimbra, but this would be a total blocker. :( |
…read buffer being too full to allow writes therefore blocking write
I have been working through automating our build process, and our existing development package is the only one that does not succeed when processed by prm. Investigating further, and generating test rpms to exclude something specific to our package, I have found where some size threshold is being surpassed.
I am using EPM to generate RPM files.
beginning and end of test.list
instrumented prm and arr-pm output for hanging case
htop output for hanging case
strace output for hanging case
prm hangs here:
https://github.com/dnbert/prm/blob/master/lib/prm/rpm.rb#L242
The strace
write()call is from the ruby-arr-pm library here:https://github.com/jordansissel/ruby-arr-pm/blob/master/lib/arr-pm/file.rb#L210
It feels like a logic error once the filelist gets too long - but I've hit the edge of what I can diagnose by inspection. And of course, if this is a bug in arr-pm proper, apologies here.
The text was updated successfully, but these errors were encountered: