RT issues

RT Users
1

Hi,

I am running RT 2.0.15 with apache 1.3.27 and fastcgi on solaris.

Recently i have had a couple of users report that their replies to rt via
email have not been recorded. I am at a loss as to why since it is only on
2 specific tickets and both users have been and continue to use rt
regularly via email.

Here is what I got from the log files but I do not know what is going on.

rt.log:
[Wed Dec 3 00:24:34 2003] [crit]: RT::Attachment->Create couldn’t, as you
didn’
t specify a transaction

[Wed Dec 3 00:24:35 2003] [err]: RT::Ticket=HASH(0x587060) couldn’t init a
tran
saction (Transaction Created)

[Wed Dec 3 00:24:35 2003] [crit]: correspondence (probably) not sent
[Wed Dec 3 14:14:55 2003] [crit]: RT::Attachment->Create couldn’t, as you
didn’
t specify a transaction

[Wed Dec 3 14:14:56 2003] [err]: RT::Ticket=HASH(0x587204) couldn’t init a
tran
saction (Transaction Created)

[Wed Dec 3 14:14:56 2003] [crit]: correspondence (probably) not sent
[Wed Dec 3 19:11:57 2003] [crit]: RT::Attachment->Create couldn’t, as you
didn’
t specify a transaction

[Wed Dec 3 19:11:59 2003] [crit]: The comment has been recorded

and procmail log
From hhuang@qualcomm.com Tue Dec 2 16:24:30 2003
symbol an
Folder: /opt/rt/rt2/bin/rt-mailgate --queue dm --action
correspond 6343
RT::Attachment->Create couldn’t, as you didn’t specify a transaction
RT::Ticket=HASH(0x587060) couldn’t init a transaction (Transaction Created)
correspondence (probably) not sentFrom ywu@qualcomm.com Tue Dec 2 17:44:59
2003

From mriceerw@qualcomm.com Wed Dec 3 06:14:51 2003
Folder: /opt/rt/rt2/bin/rt-mailgate --queue dm --action
correspond 3639
RT::Attachment->Create couldn’t, as you didn’t specify a transaction
RT::Ticket=HASH(0x587204) couldn’t init a transaction (Transaction Created)
correspondence (probably) not sent

Obviously RT isnt creating the ticket since the transaction creation failed
but I do not know how to find out why this is happening.
Could this be related to Mail client? Both users can add comments/replys to
the tickets via the web but not email.

Any help is welcomed
TIA
John

2

Hi,

I am running RT 2.0.15 with apache 1.3.27 and fastcgi on solaris.
Recently i have had a couple of users report that their replies to rt via
email have not been recorded. I am at a loss as to why since it is only on
2 specific tickets and both users have been and continue to use rt
regularly via email.

What do the database’s error logs say?

Request Tracker... So much more than a help desk — Best Practical Solutions – Trouble Ticketing. Free.

3

At 01:05 PM 12/3/2003, Jesse Vincent wrote:

Hi,

I am running RT 2.0.15 with apache 1.3.27 and fastcgi on solaris.
Recently i have had a couple of users report that their replies to rt via
email have not been recorded. I am at a loss as to why since it is only on
2 specific tickets and both users have been and continue to use rt
regularly via email.

What do the database’s error logs say?

Our dba’s said that they did not see any errors in the database logs files.
Any other ideas?

4

-----Original Message-----
From: John Gedeon [mailto:jgedeon@qualcomm.com]
Sent: Wednesday, December 03, 2003 4:33 PM
To: Jesse Vincent
Cc: rt-users@fsck.com
Subject: Re: [rt-users] RT issues

At 01:05 PM 12/3/2003, Jesse Vincent wrote:

Hi,

I am running RT 2.0.15 with apache 1.3.27 and fastcgi
on solaris.
Recently i have had a couple of users report that their
replies to
rt via email have not been recorded. I am at a loss as to
why since
it is only on 2 specific tickets and both users have been and
continue to use rt regularly via email.

What do the database’s error logs say?

Our dba’s said that they did not see any errors in the
database logs files.
Any other ideas?

–
Request Tracker... So much more than a help desk — Best Practical Solutions – Trouble Ticketing. Free.

Hello John,

Do the users still have a copy of the emails they've sent in their

sent items folders that you can compare against the SMTP logs?
Additionally, check the sent times on the mail against your webserver logs
and see if anything shows there.

Cheers,

Tremaine

5

Hi Guys,

These issues have been observed in perl 5.8.0 → 5.8.3 with RT 3.0.8 →
3.0.10 and latest version of CPAN modules.

We are currently seeing two issues, which concern us as part of our plan
to roll out RT. Its not a hardware problem as it has been observed on
two different sets of Hardware with two different versions of Solaris.

Firstly, as detailed in my previous email to the alias, we are seeing
total data loss from the InnoDB files, resulting in a restore being
required.

This happens even if the database is shutdown cleanly and properly. We
currently do a database mysqldump every hour to try to minimise the data
loss. Any Mysql experts out there want to give me some suggestions to
track the problem down?

Secondly, rt-crontool seems extremely arbitrary in its escalation.

For example, our queues are set to start at 1 and escalate to 99 over a
2 day period. A tester submitted a ticket and 7 minutes later
rt-crontool did its scheduled run and escalated the ticket to 50. I then
manually ran rt-crontool again 5 minutes later ( so the ticket is only
12 minutes old) and it escalated again to 99.

This clearly cannot be right. After 7 minutes it shouldn’t have
escalated at all. After 12 hours, I would expect it to be at priority
25.

Is there a way to make rt-crontool or RT::Action::Escalate a little more
discerning?

Thanks

Rick Ellis Richard.Ellis@Sun.COM

6

Firstly, as detailed in my previous email to the alias, we are seeing
total data loss from the InnoDB files, resulting in a restore being
required.

I’ve never seen this, granted my various RT installs aren’t very
big. I don’t think many other people have seen it either, otherwise,
there’d have been a lot of screaming on the mailing lists. So I think
it’s something specific to you, and I suspect it’s in your database.

seph

7

Rick Ellis wrote:

Firstly, as detailed in my previous email to the alias, we are seeing
total data loss from the InnoDB files, resulting in a restore being
required.

This happens even if the database is shutdown cleanly and properly. We
currently do a database mysqldump every hour to try to minimise the data
loss. Any Mysql experts out there want to give me some suggestions to
track the problem down?

The MySQL mailing lists are over at lists.mysql.com; it sounds like
you might have found a bug the MySQL folks ought to know about…
�|� Request Tracker... So much more than a help desk — Best Practical Solutions – Trouble Ticketing. Free.

8

WRT to priority escalation, RT::Action::EscalatePriority is only intended
to be run once a day. I believe it only calculates the days left before the
due date and does something like:

$CURPRI + ( ($FINALPRI - $CURPRI) / $DAYSLEFT )

If no due date is set, it just does $CURPRI++.

You could probably customize the code to deal with smaller timeslices.On Wed, 31 Mar 2004, Rick Ellis wrote:

Hi Guys,

These issues have been observed in perl 5.8.0 → 5.8.3 with RT 3.0.8 →
3.0.10 and latest version of CPAN modules.

We are currently seeing two issues, which concern us as part of our plan
to roll out RT. Its not a hardware problem as it has been observed on
two different sets of Hardware with two different versions of Solaris.

Firstly, as detailed in my previous email to the alias, we are seeing
total data loss from the InnoDB files, resulting in a restore being
required.

This happens even if the database is shutdown cleanly and properly. We
currently do a database mysqldump every hour to try to minimise the data
loss. Any Mysql experts out there want to give me some suggestions to
track the problem down?

Secondly, rt-crontool seems extremely arbitrary in its escalation.

For example, our queues are set to start at 1 and escalate to 99 over a
2 day period. A tester submitted a ticket and 7 minutes later
rt-crontool did its scheduled run and escalated the ticket to 50. I then
manually ran rt-crontool again 5 minutes later ( so the ticket is only
12 minutes old) and it escalated again to 99.

This clearly cannot be right. After 7 minutes it shouldn’t have
escalated at all. After 12 hours, I would expect it to be at priority
25.

Is there a way to make rt-crontool or RT::Action::Escalate a little more
discerning?

Thanks

–
Rick Ellis Richard.Ellis@Sun.COM

rt-users mailing list
rt-users@lists.bestpractical.com
The rt-users Archives

Have you read the FAQ? The RT FAQ Manager lives at http://fsck.com/rtfm

9

I am currently testing a slightly more discerning version of
EscalatePriority.pm which calculates in hours, instead of days as we
escalate every 6 hours because of the short timescale the Business have
defined.

Once its stable, I’ll pass it to Jesse for disposal how BestPractical
see fit.

RikOn Thu, 2004-04-01 at 00:46, asterr wrote:

WRT to priority escalation, RT::Action::EscalatePriority is only intended
to be run once a day. I believe it only calculates the days left before the
due date and does something like:

$CURPRI + ( ($FINALPRI - $CURPRI) / $DAYSLEFT )

If no due date is set, it just does $CURPRI++.

You could probably customize the code to deal with smaller timeslices.

On Wed, 31 Mar 2004, Rick Ellis wrote:

Hi Guys,

These issues have been observed in perl 5.8.0 → 5.8.3 with RT 3.0.8 →
3.0.10 and latest version of CPAN modules.

We are currently seeing two issues, which concern us as part of our plan
to roll out RT. Its not a hardware problem as it has been observed on
two different sets of Hardware with two different versions of Solaris.

Firstly, as detailed in my previous email to the alias, we are seeing
total data loss from the InnoDB files, resulting in a restore being
required.

This happens even if the database is shutdown cleanly and properly. We
currently do a database mysqldump every hour to try to minimise the data
loss. Any Mysql experts out there want to give me some suggestions to
track the problem down?

Secondly, rt-crontool seems extremely arbitrary in its escalation.

For example, our queues are set to start at 1 and escalate to 99 over a
2 day period. A tester submitted a ticket and 7 minutes later
rt-crontool did its scheduled run and escalated the ticket to 50. I then
manually ran rt-crontool again 5 minutes later ( so the ticket is only
12 minutes old) and it escalated again to 99.

This clearly cannot be right. After 7 minutes it shouldn’t have
escalated at all. After 12 hours, I would expect it to be at priority
25.

Is there a way to make rt-crontool or RT::Action::Escalate a little more
discerning?

Thanks

–
Rick Ellis Richard.Ellis@Sun.COM

rt-users mailing list
rt-users@lists.bestpractical.com
The rt-users Archives

Have you read the FAQ? The RT FAQ Manager lives at http://fsck.com/rtfm

Rick Ellis Richard.Ellis@Sun.COM

10

-wanting to have tickets created from emails so put down the NoCreateUserOnEmailTicketCreate and since then have received the following error messages;
opt/rt4/bin/rt-mailgate --queue BigBrother --action correspond --url http://rdbart001.rdba.remotedbaexperts.com --debug < /tmp/TEST-THIS

Stack:
[/opt/rt4/sbin/…/lib/RT/Interface/Email/Auth/MailFrom.pm:19]
[/opt/rt4/sbin/…/lib/RT/Interface/Email.pm:1631]
[/opt/rt4/sbin/…/lib/RT/Interface/Email.pm:1448]
[/opt/rt4/share/html/REST/1.0/NoAuth/mail-gateway:61]

RT server error.

The RT server which handled your email did not behave as expected. It
said:

Undefined subroutine &RT::Interface::email::Auth::MailFrom::ParseSenderAddressFromHead called at /opt/rt4/sbin/…/lib/RT/Interface/Email/Auth/MailFrom.pm line 19.

Stack:
[/opt/rt4/sbin/…/lib/RT/Interface/Email/Auth/MailFrom.pm:19]
[/opt/rt4/sbin/…/lib/RT/Interface/Email.pm:1631]
[/opt/rt4/sbin/…/lib/RT/Interface/Email.pm:1448]
[/opt/rt4/share/html/REST/1.0/NoAuth/mail-gateway:61]

Please give me some hints if you’ve ever had these errors before, thanks for your help,
Evan

11

-wanting to have tickets created from emails so put down the
NoCreateUserOnEmailTicketCreate and since then have received the
following error messages;

This is a core feature of RT. I don’t know what led you to that
misguided wiki page, but please remove anything it told you to add and
follow RT’s standard instructions for setting up incoming email.

The custom code you added is causing these failures, and you seem to
have replaced the wrong file (it told you to add MailFrom_Local.pm, not
overwrite MailFrom.pm).

Thomas

12

Thank you Thomas for your assistance, I’m almost there. Everything appears to work except for the actual mail into rt; There is an “rt” user in rt who will receive the emails. There is also “rt” in the aliases file for postfix. Thank you for your input, Evan

/opt/rt4/bin/rt-mailgate --queue BigBrother --action correspond --url http://rdbart001.rdba.remotedbaexperts.com --debug < /tmp/TEST-THIS

/opt/rt4/bin/rt-mailgate: temp file is ‘/tmp/jDjeCKsFU6/zBd0zwFzzD’
/opt/rt4/bin/rt-mailgate: connecting to http://rdbart001.rdba.remotedbaexperts.com/REST/1.0/NoAuth/mail-gateway
not ok - Could not load a valid user-----Original Message-----
From: rt-users-bounces@lists.bestpractical.com [mailto:rt-users-bounces@lists.bestpractical.com] On Behalf Of Thomas Sibley
Sent: Monday, May 21, 2012 2:57 PM
To: RT Users
Subject: Re: [rt-users] RT issues

On 05/21/2012 02:48 PM, Evan Soward wrote:

-wanting to have tickets created from emails so put down the
NoCreateUserOnEmailTicketCreate and since then have received the
following error messages;

This is a core feature of RT. I don’t know what led you to that misguided wiki page, but please remove anything it told you to add and follow RT’s standard instructions for setting up incoming email.

The custom code you added is causing these failures, and you seem to have replaced the wrong file (it told you to add MailFrom_Local.pm, not overwrite MailFrom.pm).

Thomas

13

Thank you Thomas for your assistance, I’m almost there. Everything
appears to work except for the actual mail into rt; There is an “rt”
user in rt who will receive the emails. There is also “rt” in the
aliases file for postfix. Thank you for your input, Evan

You do not need to create a special user inside RT to receive mail…
there is no need for a user named “rt”.

/opt/rt4/bin/rt-mailgate --queue BigBrother --action correspond --url http://rdbart001.rdba.remotedbaexperts.com --debug < /tmp/TEST-THIS

/opt/rt4/bin/rt-mailgate: temp file is ‘/tmp/jDjeCKsFU6/zBd0zwFzzD’
/opt/rt4/bin/rt-mailgate: connecting to http://rdbart001.rdba.remotedbaexperts.com/REST/1.0/NoAuth/mail-gateway
not ok - Could not load a valid user

Look at your webserver logs for RT. They’ll probably tell you about
granting rights.