Could not load ticket

RT Developers
1

Hello,

We are currently using RT 4.4.0 with mysql (MariaDB). Sometimes, tickets are not created correctly. The message of the creation is sent, but the database does not have any content and the ticket cannot be opened.

Example Ticket: ID 14437 or 14436

Ticket 14435 or 14438 for example is working.

In the log the following message appears:
Create Ticket Debug LOG: (Is to big for posting directly)
https://1drv.ms/t/s!ArOeOqKFTlRNtx9TFvNDW6e5jnZX

Open Ticket Debug Log:
May 30 11:48:32 Server RT: [14318] RT::Ticket=HASH(0x7fd5b87b4ef8) tried to load a bogus ticket: 14437 (/opt/rt4/sbin/…/lib/RT/Ticket.pm:149)
May 30 11:48:32 Server RT: [14318] Could not load ticket 14437
May 30 11:48:32 Server RT: [14318] RT::Ticket=HASH(0x7fd5998dcd40) tried to load a bogus ticket: 14437 (/opt/rt4/sbin/…/lib/RT/Ticket.pm:149)

RT Error Log:
[22991] [Mon May 29 11:46:19 2017] [error]: Could not load ticket 14437 (/opt/rt4/share/html/Elements/Error:78)

SQL:
MariaDB [rt4]> select * from Tickets where id = 14437;
Empty set (0.00 sec)

MariaDB [rt4]> select id, Subject from Tickets where id = 14437;
Empty set (0.00 sec)

Mail by RT Scrip to Queue Watcher:
A new ticket has been created in the Human Resources queue. Details are as follows:

Ticket #: 14437
Created: Sat May 27 08:00:02 2017
Transaction: Ticket created by user_rt
Queue: Human Resources
Subject: user: Trial period expires
Owner: Nobody
Requestors: user@domain.edu
Status: new
Ticket: https://support.domain.edu/Ticket/Display.html?id=14437

Did you have that kind of problem before?

Thank you for your help
Pictop

2

I assume this happens only while trying to create ticket by mail, right? I am experiencing the same problem on version 4.2.12. There is a clue in /var/log/procmail/procmail.log:

HTTP request failed: 500 Server closed connection without sending any data back. Your webserver logs may have more information or there may be a network problem.
procmail: Program failure (75) of “/opt/rt4/bin/rt-mailgate”

This creates apache core dump. Last time we have investigated that this lead us to find a bug in Sys::Syslog perl module. We have reported that issue (and fix) to upstream. But I am afraid there are more buggy perl modules which RT depends on. Now this behavior occured in my RT again, notifications were sent but the ticket does not exist in database. Investigating the core dump again :slight_smile:
Petr

3

So the mistake was that the unpatched version of Sys::Syslog took it’s place again. There is one more thing to do with this than patching the module. It should be sufficient to add

Set(@LogToSyslogConf, lock => 1 );

to your RT_Siteconfig.pm. For explanation see https://metacpan.org/pod/Log::Dispatch::Syslog:

If this is set to a true value, then the calls to setlogsock(), openlog(), syslog(), and closelog() will all be guarded by a thread-locked variable. This is only relevant when running you are using Perl threads in your application. Setting this to a true value will cause the threads and threads::shared modules to be loaded.
This defaults to false.