[3.1.3]: PostMasterMailbox error

It's happening really something with the mail subsystem there :D since 3.1.3 I get many error of this type: ERROR: OTRS-otrs.PostMasterMailbox.pl-10 Perl: 5.10.1 OS: linux Time: Wed Apr 11 10:40:02 2012 Message: Found no Queue for DWH-SIT::Install! Traceback (2751): Module: Kernel::System::Queue::QueueLookup (v1.136) Line: 515 Module: Kernel::System::PostMaster::DestQueue::GetTrustedQueueID (v1.27) Line: 118 Module: Kernel::System::PostMaster::Run (v1.87) Line: 354 Module: Kernel::System::MailAccount::POP3::Fetch (v1.9) Line: 201 Module: Kernel::System::MailAccount::MailAccountFetch (v1.17) Line: 424 Module: main::Fetch (v1.4) Line: 180 Module: /opt/otrs/bin/otrs.PostMasterMailbox.pl (v1.4) Line: 93 But, beleve me, the queue is live. it's become keysensitive something ? I admit that the filter and the real name doesn't match for this reason... but it was as is since 3 year up to now ;)

Additionally, for the Type I've discovered that was defined with a space at the end ("DCO ") and the postmaster filter without it. so now it's not stripped ?!

Sorry again. For the message below I was refering to this message:
[root@HMCVR0004 bin]# cat
../var/spool/problem-email-ecc9cd296cb599902561a3ba3d05ffb8 | ./
otrs.PostMaster.pl
ERROR: OTRS-otrs.PostMaster.pl-10 Perl: 5.10.1 OS: linux Time: Wed Apr 11
10:50:43 2012
Message: No Type for DCO found!
Traceback (3427):
Module: Kernel::System::Type::TypeLookup (v1.26) Line: 388
Module: Kernel::System::Ticket::TicketCreate (v1.545) Line: 380
Module: Kernel::System::PostMaster::NewTicket::Run (v1.85) Line: 170
Module: Kernel::System::PostMaster::Run (v1.87) Line: 358
Module: (eval) (v1.5) Line: 114
Module: ./otrs.PostMaster.pl (v1.5) Line: 84
ERROR: OTRS-otrs.PostMaster.pl-10 Perl: 5.10.1 OS: linux Time: Wed Apr 11
10:50:43 2012
Message: No TypeID for 'DCO'!
Traceback (3427):
Module: Kernel::System::Ticket::TicketCreate (v1.545) Line: 387
Module: Kernel::System::PostMaster::NewTicket::Run (v1.85) Line: 170
Module: Kernel::System::PostMaster::Run (v1.87) Line: 358
Module: (eval) (v1.5) Line: 114
Module: ./otrs.PostMaster.pl (v1.5) Line: 84
ERROR: OTRS-otrs.PostMaster.pl-10 Perl: 5.10.1 OS: linux Time: Wed Apr 11
10:50:43 2012
Message: Can't process mail, see log sub system! at
./otrs.PostMaster.plline 116.
Traceback (3427):
Module: ./otrs.PostMaster.pl (v1.5) Line: 136
excuse me for the spam. Shall I open a bug or is "working as aspected" for
you ?
On Wed, Apr 11, 2012 at 10:54 AM, Marco Vannini
Additionally, for the Type I've discovered that was defined with a space at the end ("DCO ") and the postmaster filter without it. so now it's not stripped ?!

Hi Mike,
you are right, sorry for the big caos (that I usually do :D). The problem
was that before 3.1.3 postmaster filter was able to land mail in queue
correctly either if there were some "mistake" (upper vs lower case) and the
same kind of problem I've found on ticket type assignment where in this
case I had a space in the type definition (and not in the filter
assignment).
undoubtedly now it's cleaner but I've been caught by panic :D
Due to this I don't know if those behavior has to be considered as bug or
it will be a good point to put a note on the upgrade as issue.
Thank you as usual...
MV
On Mon, Apr 16, 2012 at 6:34 PM, Michiel Beijen
Hi Marco,
On Wed, Apr 11, 2012 at 10:57, Marco Vannini
wrote: excuse me for the spam. Shall I open a bug or is "working as aspected" for you ?
I guess I am a little confused, I see a lot of logs, but what is the actual issue you were having here? -- Mike --------------------------------------------------------------------- OTRS mailing list: otrs - Webpage: http://otrs.org/ Archive: http://lists.otrs.org/pipermail/otrs To unsubscribe: http://lists.otrs.org/cgi-bin/listinfo/otrs

Hi Marco,
On Mon, Apr 16, 2012 at 18:46, Marco Vannini
you are right, sorry for the big caos (that I usually do :D). The problem Marco was that before 3.1.3 postmaster filter was able to land mail in queue correctly either if there were some "mistake" (upper vs lower case) and the same kind of problem I've found on ticket type assignment where in this case I had a space in the type definition (and not in the filter assignment).
undoubtedly now it's cleaner but I've been caught by panic :D
Due to this I don't know if those behavior has to be considered as bug or it will be a good point to put a note on the upgrade as issue.
this is actually very nasty. In OTRS 3.1.3 we created lots of caching; this means fewer database requests which is generally a 'Good Thing (TM)'. If you run OTRS on MySQL or a database with a case insensitive collation (i.e. NOT Oracle) you could always create a ticket in a queue or ticket type regardless of case. Because if you do 'SELECT id FROM queue WHERE name = 'pOSTMASTER' it will give the exact same result as when you do 'SELECT id FROM queue WHERE name = 'Postmaster' In this case, since 3.1.3 we no longer check the database, we check the cache, and also we do not fall back to checking the database if we can't find it. And the cache is always case sensitive. I'm not quite sure if I consider this a bug but it certainly is a change in behavior! -- Mike.
participants (2)
-
Marco Vannini
-
Michiel Beijen