We are currently running RT 4.4.4. Attempting to perform a search (Search > Tickets > New Search) yields:
An internal RT error has occurred. Your administrator can find more details in RT’s log files.
Looking at the logs yields:
Jan 21 11:01:40 charger RT: [31170] Odd number of elements in hash assignment at /opt/rt4/sbin/…/lib/RT/Interface/Web.pm line 1466.
Jan 21 11:01:40 charger RT: [31170] Use of uninitialized value in list assignment at /opt/rt4/sbin/…/lib/RT/Interface/Web.pm line 1466.
Jan 21 11:01:40 charger RT: [31170] Can’t use an undefined value as a HASH reference at /opt/rt4/share/html/Elements/SelectSLA line 52.#012#012Stack:#012 [/opt/rt4/share/html/Elements/SelectSLA:52]#012 [/opt/rt4/share/html/Search/Elements/ConditionRow:74]#012 [/opt/rt4/share/html/Search/Elements/PickBasics:49]#012 [/opt/rt4/share/html/Search/Elements/PickCriteria:54]#012 [/opt/rt4/share/html/Widgets/TitleBox:61]#012 [/opt/rt4/share/html/Search/Elements/PickCriteria:70]#012 [/opt/rt4/share/html/Search/Build.html:81]#012 [/opt/rt4/sbin/…/lib/RT/Interface/Web.pm:697]#012 [/opt/rt4/sbin/…/lib/RT/Interface/Web.pm:376]#012 [/opt/rt4/share/html/autohandler:53]
Any help or guidance on fixing this would be appreciated.
I think you might want to very carefully go through your RT_SiteConfig.pm a line at a time and see if there are any configuration lines that aren’t quite set up properly - it might not be the ones that you’ve looked at already because it might be that your config isn’t making a valid Perl data structure. Things like missing hash keys, screwed up quotes, etc.
As well as checking your local config in /opt/rt4/local/etc/RT_SiteConfig.pm, its probably also worth checking /opt/rt4/etc/RT_SiteConfig.pm in case anything odd has accidentally slipped in there (it shouldn’t as you should be editing the config in your local etc directory but mistakes can happen). Also remember if you have a RT_SiteConfig.d directory with more config files in it to check all of them as well.
If you flush the Mason cache and restart your web server, do you get any errors output at that point as RT is first starting up? It’ll be trying to parse the config files then.
On startup (after flushing the mason cache as per @GreenJimll’s suggestion), it is rather upset over RTAddressRegexp not being set:
[31681] [Wed Jan 22 21:54:29 2020] [debug]: The RTAddressRegexp option is not set in the config. Not setting this option results in additional SQL queries to check whether each address belongs to RT or not. It is especially important to set this option if RT receives emails on addresses that are not in the database or config. (/opt/rt4/sbin/…/lib/RT/Config.pm:600)
Does this option need to be configured for the application to operate?
A warning also occurred:
[31436] [Wed Jan 22 21:53:14 2020] [warning]: Use of uninitialized value $_ in split at /opt/rt4/sbin/…/lib/RT/Interface/REST.pm line 288. (/opt/rt4/sbin/…/lib/RT/Interface/REST.pm:288)
Whilst getting the RTAddressRegexp option filled in is a good idea, the fact that its not there isn’t necessarily the issue you’re having with search. I was wondering if there had been a structural issue with some part of the RT_SiteConfig.pm which was what was causing the Odd number of elements in hash assignment warning/error that you’d seen in the logs previously. You usually get that error from Perl when a hash array is using “list flattening” to assign keys and values in one go from a non-hash array. Hence the reason for checking all the RT config files carefully, especially any that set a % type hash variable with a bracketed (…) list of keys and values. There should always be an even number of values in the list in the assignment in this case.
Was able to execute that script fine, added the generated regex to my config. The RTAddressRegexp error is no longer showing up.
However, the original problem has not been resolved. As before, the same errors appear in the log when attempting to perform a search.
Jan 24 12:48:11 charger RT: [6965] Odd number of elements in hash assignment at /opt/rt4/sbin/…/lib/RT/Interface/Web.pm line 1466.
Jan 24 12:48:11 charger RT: [6965] Use of uninitialized value in list assignment at /opt/rt4/sbin/…/lib/RT/Interface/Web.pm line 1466.
Jan 24 12:48:12 charger RT: [6965] Can’t use an undefined value as a HASH reference at /opt/rt4/share/html/Elements/SelectSLA line 52.#012#012Stack:#012 [/opt/rt4/share/html/Elements/SelectSLA:52]#012 [/opt/rt4/share/html/Search/Elements/ConditionRow:74]#012 [/opt/rt4/share/html/Search/Elements/PickBasics:49]#012 [/opt/rt4/share/html/Search/Elements/PickCriteria:54]#012 [/opt/rt4/share/html/Widgets/TitleBox:61]#012 [/opt/rt4/share/html/Search/Elements/PickCriteria:70]#012 [/opt/rt4/share/html/Search/Build.html:81]#012 [/opt/rt4/sbin/…/lib/RT/Interface/Web.pm:697]#012 [/opt/rt4/sbin/…/lib/RT/Interface/Web.pm:376]#012 [/opt/rt4/share/html/autohandler:53]
Thus far, I have been unable to find any issues with any config files like @GreenJimll suggested. I will continue to look for such unless anyone has any other suggestions.
Undefined subroutine &main::Set called at RT_SiteConfig.pm line 22.
The lines at this point are:
my $zone = “UTC”;
$zone=/bin/cat /etc/timezone if -f “/etc/timezone”;
chomp $zone;
Set($Timezone, $zone);
This is so far the only other indication I have found of an issue with any config files. I have tested any various config files with perl -c with no syntax issues found.
Have you tried replacing those four lines with a static set of whatever timezone you use? For example we have:
Set( $Timezone, 'Europe/London' );
in our local RT_SiteConfig.pm. At least that way its one bit of complication removed - it might be some line above it that is having issues, or you’re using the wrong Perl that doesn’t have the right module paths set up, etc.
We pulled a fresh copy of the base config file (RT_Config.pm) from the installation folder and replaced it with the existing one. It appears that some edits were made to that file at some point that were causing issues. Doing this fixed the issue.