We have a problem that occurs frequently: some agents lose permissions on the groups assigned to them and they can't see any tickets. For the rest of agents, the application works correctly and this issue seems transparent, but sometimes there is a kind of chain reaction that ends up affecting performance in general.
The error can be detected by looking at the system log, with a message like: [Error][Kernel::System::Group::_DBGroupUserGet][Line:2486]: no hay suficiente memoria para el resultado de la consulta, SQL: SELECT user_id, group_id, permission_key FROM group_user WHERE permission_value = 1. [spanish traslation: not enough memory for the query result]. A spike in CPU load graph is also detected every time permissions are lost.
In general the system recovers after executing the following commands
Code: Select all
/www/scripts/apache24.sh stop
su -c "/opt/otrs/bin/otrs.Console.pl Maint::Config::Rebuild" -s /bin/bash otrs
su -c "/opt/otrs/bin/otrs.Console.pl Maint::Cache::Delete" -s /bin/bash otrs
su -c "/opt/otrs/bin/otrs.Console.pl Maint::Loader::CacheCleanup" -s /bin/bash otrs
su -c "/opt/otrs/bin/otrs.Console.pl Maint::Loader::CacheGenerate" -s /bin/bash otrs
/www/scripts/apache24.sh start
We have the opinion that they are two separate errors, maybe related, but not the same:
New Agents
New agents always create problems. As soon as they connect they produce this error and it is more persistent over time. Also, the table that lists agent's permissions on the different groups is not completely filled in on a first attempt, and requires multiple executions of the recovery commands mentioned above. Could it be a cache size related issue?
General Error
The frequency of the error (with no new agents in the system) seems to be related to the number of users utilizing the application: more agents and more articles, greater the probability.
We think this kind of error could be due to differente causes:
- the logic/configuration that has been used in our product (this will be explained later)
- the computational limit available to us
- agent's searches without any filter, or care
- saturation of the database, since some scripts are launched against it through the generic agent
- we use REST services quite intensively, and they could be interfering
- others
We are using an OTRS 5.0.20 running on a SUSE Linux Enterprise Server 12 SP3. The database is a PostgreSQL 9.6.1.
We are also using LDAP authentication, although with certain particular characteristics:
- We are employing a 1 to 1 relationship between groups and queues
- There is over 75 groups/queues and 300 agents. Many agents could be in many groups
- There is an LDAP group, let's call it ALL_AGENTS, which gives read-only, move_into, create and notes permissions to all groups/queues (these permissions are given to all agents)
- There is also a LDAP group, let's call it ADMIN, which gives all permissions to all queues (these permissions are only given to a few agents)
- All specific groups also have associated total permissions on that same group. With this it is achieved that an agent with permissions on ALL_AGENTS and on the groups to which it belongs, can perform minimal actions on all the groups, and total actions on the groups to which it belongs
- For the management of this kind of logic we use $Self->{'AuthSyncModule::LDAP::UserSyncGroupsDefinition1'} = { ... }
I have done several tests with $Self->{'AuthSyncModule::LDAP::UserSyncRolesDefinition'} = { } to create roles, because there is redundact logic in some LDAP groups, but it doesn't seem to work with UserSyncGroupsDefinition1 at the same time (maybe I'm wrong)
- This logic is set in Default.pm. I know that the correct way would be in Config.pm, but as it has been said before, changes in permissions can produce errors, and in this case we have thought that it could influence everyone, leaving the service unavailable for an undefined period of time. Also, as far as I understand, it would only affect in case of migrating to a higher version. Again, I could be wrong.
Greetings to everyone and thanks for your time