uninitialized value %Queues TicketQueueOverview.pm

[hkais]

this is the new thread of viewtopic.php?f=62&t=39799

I am having many log entries with:

Code: Select all

-e: Use of uninitialized value within %Queues in hash element at /opt/otrs//Kernel/Output/HTML/Dashboard/TicketQueueOverview.pm line 163.

tracked down the issue by adding this code to the file /opt/otrs/Kernel/Output/HTML/Dashboard/TicketQueueOverview.pm

after this

Code: Select all

sub Run {
    my ( $Self, %Param ) = @_;

added this

Code: Select all

    # get log object
    my $LogObject = $Kernel::OM->Get('Kernel::System::Log');

before this

Code: Select all

    my $LimitGroup = $Self->{Config}->{QueuePermissionGroup} || 0;

and from line 162

Code: Select all

        # Gather ticket count for corresponding Queue <-> State.
        for my $QueueID (@QueueIDs) {

added this

Code: Select all

                $LogObject->Log(
                    Priority => 'error',
                    Message  => "searching for error in Queue with QueueID: '$QueueID'! ",
                );

Code: Select all

            push @{ $Results{ $Queues{$QueueID} } },
                $TicketCountByQueueID->{$QueueID} ? $TicketCountByQueueID->{$QueueID} : 0;
        }

but now I am fully confused.
The QueueID is 999999
And I cannot find this queue?

Here the log entry:

Code: Select all

Message: searching for error in Queue with QueueID: '999999'! 

can someone help me out of the dark?

[root]

Hi,

I would not invest a single minute of my time unless your on the latest patch level for version 5.
There were interesting changes from 5.0.26 to 5.0.42 in this file (https://github.com/znuny/znuny/compare/ ... 5c75597dab)

Maybe it's related to the bug which was fixed in 5.0.28

- Roy

[hkais]

let me go back one step.
Assuming have done something wrong on migrating.

Basically I did:

1)
backup SQL with backup.pl script from existing environment
restored SQL with mysql command line on new environment
no additional commands to rebuild something or to recreate
2)
created tar.gz from old environment of full otrs folder
restored the tar.gz on new environment
no additional commands to rebuild something or to recreate

Assuming two possible issues:
1. my current OS migration was totally wrong and I missed or did something wrong
2. my previous upgrades went somehow wrong (e.g. files have not been copied or sqls have not been executed)

to 1.)
I have done a compare of my manually created otrs.tar.gz and the Application.tar.gz created by backup.pl
the differences are cache files, which may have some old code-caches.

Screenshot_02668.png

So summing up, it could be that I missed something really essential here, since i have used the manually created otrs.tar.gz to restore on new server.

Since I want to avoid any further issues, maybe you can help me on getting clear picture on how to migrate from server to server?

Tried to find the changes in github, but so many changes that I have no idea which one it is.

[root]

Hi,

Since I want to avoid any further issues, maybe you can help me on getting clear picture on how to migrate from server to server?

I use a really simple way for this, assuming you do not have any unpackages files (which I never recommend).

- Unpack same version (or newer patchlevel) on new server
- check modules and install missing
- symlink /opt/otrs/scripts/apache2-httpd.include.conf to /etc/apache2/conf-available/znuny.conf and a2enconf znuny
- dump database on old server and import on new
- copy Kernel/Config.pm, Kernel/Config/Files/*.pm, /var/log/*Counter.log, .procmailrc, and var/cron/* (all without.dist) to the new server
- set permissions
- check database access with bin/otrs.Console.pl Maint::Database::Check
- reinstall all packages, repeat command if required: bin/otrs.Console.pl Admin::Package::ReinstallAll
- bin/Cron.sh start
- start webserver


If there are other files I recommend packaging them. Then they will be covered with the package reinstall.

Tried to find the changes in github, but so many changes that I have no idea which one it is.

You could search (in the browser) for Kernel/Output/HTML/Dashboard/TicketQueueOverview.pm and click to diff

- Roy

[hkais]

- Unpack same version (or newer patchlevel) on new server

Okay here I have used the created tar.gz instead to reinstall freshly
But I did a diff of the vanilla otrs-5.0.42 with my backup tar.gz and all perl files are identical, so no changes found. Except the modules which have been installed additionally appear. If required I can share diff

- check modules and install missing

Unclear if necessary, if using my backup path?

- symlink /opt/otrs/scripts/apache2-httpd.include.conf to /etc/apache2/conf-available/znuny.conf and a2enconf znuny
- dump database on old server and import on new
- copy Kernel/Config.pm, Kernel/Config/Files/*.pm, /var/log/*Counter.log, .procmailrc, and var/cron/* (all without.dist) to the new server
- set permissions
- check database access with bin/otrs.Console.pl Maint::Database::Check

symlinking was already done as per doc
did the rest too, if my backup path was okay

- reinstall all packages, repeat command if required: bin/otrs.Console.pl Admin::Package::ReinstallAll

this was missing, did that now, but issue persists

- bin/Cron.sh start
- start webserver

already did that also

Tried to find the changes in github, but so many changes that I have no idea which one it is.

I checked the changes in github, but could not understand fully if the change fixed this
My issue is, that I do not understand why what the queueID 99999 is ment and from there it comes

You could search (in the browser) for Kernel/Output/HTML/Dashboard/TicketQueueOverview.pm and click to diff

What I can say that my backup file and the vanilla otrs-5.0.42 did not show up any differences in any file, except additional files which look like coming from additionally installed modules

So still a bit lost here, from there the issue in the log comes from.

If I would know if this issue is a upgrade issue, I would wait to get this fixed, but would need what and where the QueueID 99999 comes from
Alternatively I can move forward to upgrade to 6.0 znuny to see if the issue is gone. But afraid if the issue will cause other odd issues after upgrade.

Can someone adivce?

[root]

Hi,

- check modules and install missing

Unclear if necessary, if using my backup path?

This checks Perl modules installed on the system not within application directory.

After diggin into the code I just saw that your using 5.0.42 and not the version from your signature. This really had helped.

My issue is, that I do not understand why what the queueID 99999 is ment and from there it comes

That's easy: https://github.com/znuny/Znuny/blob/rel ... ew.pm#L140

My guess: you did not configure this module properly.

- Roy

[hkais]

- check modules and install missing

Unclear if necessary, if using my backup path?

This checks Perl modules installed on the system not within application directory.

sorry had a brain shortcut, of course did the modules check of the OS!

After diggin into the code I just saw that your using 5.0.42 and not the version from your signature. This really had helped.

ups, fixed that, since naming version in posts...

My issue is, that I do not understand why what the queueID 99999 is ment and from there it comes

That's easy: https://github.com/znuny/Znuny/blob/rel ... ew.pm#L140

seems I was blind. Probably I did not search with _

My guess: you did not configure this module properly.

Hope I found the right module, but cannot see an issue here? IMHO haven't touched this config for years.

Screenshot_02669.png

[root]

Hi,

Well then there is an easy explanation:

https://github.com/znuny/Znuny/blob/rel ... iew.pm#L96

This is where (for every agent) the queue are collected. The user needs ro (or rw) permissions.

Because there are no queues found in https://github.com/znuny/Znuny/blob/rel ... ew.pm#L139 is the array set to one element with the value 999999 (999_999 in perl for easier reading).
And because there is not attribute `$TicketCountByQueueID->{$QueueID}` for this queue id you got the error.

Root cause looks like a user without any ro/rw permission to a queue. I'll try to check this on the latest version too and file a bug if confirmed. But there won't be a fix for version 5. Promised.

- Roy

[hkais]

now got it. Have seen the code, but now obviously clear that the queues are user dependent after you mentioned it.

I have extended the log output with a userID. Will get probably today the user, who is responsible for that issue.
Thx once more!