<div>Hello Ruslan, thanks for response</div><div><br></div><div>this patch alone does not fix the issue.</div><div>The last post was too long and I've preferred to split my solution for the issue into several messages.</div>
<div>I need to change this line in Transaction_Overlay.pm</div><div><br></div><div>--- Transaction_Overlay.pm.orig 2010-07-09 14:45:52.000000000 +0200</div><div>+++ Transaction_Overlay.pm 2010-07-09 14:46:32.000000000 +0200</div>
<div>@@ -513,11 +513,11 @@</div><div> my $Attachment = RT::Attachment->new( $self->CurrentUser );</div><div> my ($id, $msg) = $Attachment->Create(</div><div> TransactionId => $self->Id,</div>
<div> Attachment => $MIMEObject</div><div> );</div><div>- return ( $Attachment, $msg || $self->loc("Attachment created") );</div><div>+ return ( $id, $msg || $self->loc("Attachment created") );</div>
<div> }</div><div><br></div><div> # }}}</div><div><br></div><div> # }}}</div><div><br></div><div><br></div><div>And finally this ugly patch to rt-mailgate, I hope someone with higher skills in perl/mason could make something better with the returned status.</div>
<div><br></div><div>--- rt-mailgate.orig 2010-07-09 14:57:49.000000000 +0200</div><div>+++ rt-mailgate 2010-07-09 15:18:27.000000000 +0200</div><div>@@ -61,6 +61,7 @@</div><div> $DYNAMIC_FILE_UPLOAD = 1;</div><div><br>
</div><div> use constant EX_TEMPFAIL => 75;</div><div>+use constant EX_UNKNOWERR => 76;</div><div> use constant BUFFER_SIZE => 8192;</div><div><br></div><div> my %opts;</div><div>@@ -131,7 +132,18 @@</div><div> my $content = $r->content;</div>
<div> print STDERR $content ."\n" if $opts{'debug'};</div><div><br></div><div>-if ( $content !~ /^(ok|not ok)/ ) {</div><div>+if ( $content !~ /^(ok)/ ) {</div><div>+</div><div>+ # Ticket could not be created for unknow reason.</div>
<div>+ # Return non zero to avoid that fetchmail clear email from mail server.</div><div>+ print STDERR <<EOF;</div><div>+RT server error.</div><div>+</div><div>+The RT server sends an unexpected error.</div><div>
+EOF</div><div>+</div><div>+ exit EX_UNKNOWERR;</div><div>+} elsif ( $content !~ /^(not ok)/ ) {</div><div><br></div><div> # It's not the server's fault if the mail is bogus. We just want to know that</div>
<div> # *something* came out of the server.</div><div>@@ -145,10 +157,10 @@</div><div> EOF</div><div><br></div><div> exit EX_TEMPFAIL;</div><div>+} else {</div><div>+ exit;</div><div> }</div><div><br></div><div>
-exit;</div><div>-</div><div> END {</div><div> unlink $message{'filename'} if $message{'filename'};</div><div> }</div><div><br></div><div>I hope those patches fix the issue and don't break anything else</div>
<div>Andrés.</div><div><br></div><br><div class="gmail_quote">2010/7/9 Ruslan Zakirov <span dir="ltr"><<a href="mailto:ruz@bestpractical.com">ruz@bestpractical.com</a>></span><br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
Hello Andres,<br>
<br>
As I understand the following change will fix the issue for you. If it<br>
does then drop me a note and I'll push it into core. If it doesn't<br>
then we should investigate more. Don't forget to restart the web<br>
server after patching.<br>
<br>
I think it's a bug. We can not guaranty that everything will work<br>
perfectly when you're out of space on disks, but this patch should<br>
bring more sanity.<br>
<br>
diff --git a/lib/RT/Attachment_Overlay.pm b/lib/RT/Attachment_Overlay.pm<br>
index e3c1b9c..8c60185 100644<br>
--- a/lib/RT/Attachment_Overlay.pm<br>
+++ b/lib/RT/Attachment_Overlay.pm<br>
@@ -154,6 +154,7 @@ sub Create {<br>
<div class="im"><br>
unless ($id) {<br>
$RT::Logger->crit("Attachment insert failed - ".<br>
$RT::Handle->dbh->errstr);<br>
+ return ($id);<br>
}<br>
<br>
</div><div class="im"> foreach my $part ( $Attachment->parts ) {<br>
</div>@@ -165,6 +166,7 @@ sub Create {<br>
<div class="im"> );<br>
unless ($id) {<br>
$RT::Logger->crit("Attachment insert failed: ".<br>
$RT::Handle->dbh->errstr);<br>
+ return ($id);<br>
}<br>
}<br>
</div> return ($id);<br>
<div><div></div><div class="h5"><br>
<br>
On Fri, Jul 9, 2010 at 1:55 PM, Andrés Schiavo <<a href="mailto:andresschiavo@gmail.com">andresschiavo@gmail.com</a>> wrote:<br>
> Hi, I'm currently working with a RT 3 instance and I've found that some<br>
> Tickets could be created with missing content under specific situations.<br>
> This is my scenario:<br>
> * RT 3.8.7 runnig on RHEL5 with perl 5.8.8<br>
> * Oracle 10g database<br>
> * External mail server and fetchmail to recover emails<br>
> This RT instance is quite special, we recive a lot of spam (we are working<br>
> to fix it) and the database grows quickly. During working days our<br>
> monitoring agents alert us about reaching database space limit, but if this<br>
> happen on weekend, nobody extends de DB until Monday.<br>
> Because of Spam we have configured fetchmail with "no keep" option, so if<br>
> Ticket creation fails and fetchmail does not recieve an error return code<br>
> the information of the email is lost.<br>
> I know that this are a lot of "special situations" but I think that<br>
> rt-mailgate should return non zero result when RT couldn't create the Ticket<br>
> correctly.<br>
> I haven't try to reproduce with other databases than Oracle, but I've<br>
> reproduce this behavior on two different Oracle instances<br>
> This are the steps to reproduce the issue:<br>
> When rt database tablesapce is full, fetchmail try to recover an email (with<br>
> an attachment or an html email).<br>
> Ticket is created but we end up with no attach or no text if email was html.<br>
> Fetchmail recive a 0 ret code and erase email from server.<br>
> I've attach the rt log when attachment insert fails.<br>
> I don't know if this is a bug or that's the way it's supposed to work, but<br>
> we can't loose the email information.<br>
> If this is a bug, I think that could be generated by the scope of the<br>
> variable $id in this code (Attachment_Overlay line 140)<br>
> # If a message has no bodyhandle, that means that it has subparts (or<br>
> appears to)<br>
> # and we should act accordingly.<br>
> unless ( defined $Attachment->bodyhandle ) {<br>
> my ($id) = $self->SUPER::Create(<br>
> TransactionId => $args{'TransactionId'},<br>
> Parent => $args{'Parent'},<br>
> ContentType => $Attachment->mime_type,<br>
> Headers => $head,<br>
> MessageId => $MessageId,<br>
> Subject => $Subject,<br>
> );<br>
> unless ($id) {<br>
> $RT::Logger->crit("Attachment insert failed - ".<br>
> $RT::Handle->dbh->errstr);<br>
> }<br>
> foreach my $part ( $Attachment->parts ) {<br>
> my $SubAttachment = new RT::Attachment( $self->CurrentUser );<br>
> my ($id) = $SubAttachment->Create(<br>
> TransactionId => $args{'TransactionId'},<br>
> Parent => $id,<br>
> Attachment => $part,<br>
> );<br>
> unless ($id) {<br>
> $RT::Logger->crit("Attachment insert failed: ".<br>
> $RT::Handle->dbh->errstr);<br>
> }<br>
> }<br>
> return ($id);<br>
> }<br>
> #If it's not multipart<br>
> else {<br>
> my ($ContentEncoding, $Body) = $self->_EncodeLOB(<br>
> $Attachment->bodyhandle->as_string,<br>
><br>
> If the first SUPER::Create is successfull, the $id value isn't undef, but<br>
> within the foreach loop, if an error ocurred adding Subattachments the crit<br>
> message is printed because the inner $id is undef, but the returned value is<br>
> the outer $id that is not undef, so the Ticket is created despite the error<br>
> adding a subattachment. Adding a return($id) inside the foreach loop solves<br>
> the problem an RT knows that Ticket can not be completly created.<br>
> This post is too long and don't want to add more info (specially with this<br>
> terrible bad english), but despite the error returned to rt-mailgate when<br>
> Ticket creation fails, it tells fetchmail that everything is ok and email is<br>
> deleted. I've made an ugly hack to make it work, but I think that<br>
> check_for_failure() in rt-mailgate could get te correct return code, I'm not<br>
> a perl expert and couldn't make it work, any help?<br>
> Anyway, do you think that this is a bug or a feature?<br>
> Best regards.<br>
> Andres.<br>
<br>
<br>
<br>
</div></div><font color="#888888">--<br>
Best regards, Ruslan.<br>
</font></blockquote></div><br>