RE: [otrs] Unsuccessful upgrade to 1.2.x
These are just some random thoughts here. Sorry if confusing. Jim Wight wrote:
ago became the test system, so, yes, it has fewer tickets. The main thing we changed was the ticket number format. The Config.pm settings that are different are:
I would change all of these things back, to exactly match production as much as possible. (unless you can make suggested disk image below)
The last one is because the test system has additional queues that I subsequently experimented with.
Try making these extra queues 'invalid'.
I upgrade by: <list of changes I made>
If I were really at wit's end, I would take a copy of my system with all the data, and return everything back to default. Then start implementing the x number of site specific modifications to see which one is breaking the function in question. (suggestion: try returning the .dtl files back to normal first, then customer authentication)
It appeared as soon as I logged in after upgrading the production system to 1.2.3 (from 1.1.1).
Question: So you took your test system manually through each step: 1.1.1 --> 1.2.1 1.2.1 --> 1.2.2 1.2.2 --> 1.2.3 You then rounded up all the changes to your test system and laid them down into your production system thus taking it: 1.1.1 --> 1.2.3 directly, bypassing the in-between steps? (just trying to see if I got that right).
I upgraded the production system by copying the modified 1.2.3 tree from the test machine, modifying the settings in Config.pm listed above and running DBUpdate-to-1.2. NB I have moved TicketCounter.log out of the tree so that I have one fewer thing to change; its location - the same on both systems - is defined in Config.pm ($Self->{CounterLog}).
If it were me, I'd make a complete image of your production machine (symantec ghost works for me), copy it onto a new machine and follow the exact upgrade steps that you did on the production system, trying to reduce the number of new changes (other than those mandated obviously by the upgrade itself).
So far, by adding print diagnostics to Kernel/Modules/AgentQueueView.pm, I see the creation of HTML suddenly stopping mid-ticket in this loop at line 190.
# -- # show ticket's # -- foreach (@ViewableTickets) { print $Self->ShowTicket(TicketID => $_); }
but so far I haven't a clue what set of circumstances is giving rise to it.
Not quite sure what this is. Developers?
I'm not using mod_perl.
What version of mod_perl? ********************************* Jake Covert Infrastructure Analyst Electronic Data Systems PSIC Support Group (586) 986-9698 Work (586) 518-3859 Pager http://www.eds.com *********************************
On Thu, Apr 15, 2004 at 08:26:26AM -0400, Covert, Jake wrote:
So far, by adding print diagnostics to Kernel/Modules/AgentQueueView.pm, I see the creation of HTML suddenly stopping mid-ticket in this loop at line 190.
# -- # show ticket's # -- foreach (@ViewableTickets) { print $Self->ShowTicket(TicketID => $_); }
but so far I haven't a clue what set of circumstances is giving rise to it.
Not quite sure what this is. Developers?
This is the loop to show the ticket in the queue view. In @ViewableTickets are the ticket ids to show. Martin Edenhofer -- ((otrs.de)) :: OTRS GmbH :: Norsk-Data-Str. 1 :: 61352 Bad Homburg http://www.otrs.de/ :: Manage your communication!
Jim, yes, add some debug infos to find out where the programm is stopping. -Martin On Thu, Apr 15, 2004 at 06:29:12PM +0200, Martin Edenhofer wrote:
So far, by adding print diagnostics to Kernel/Modules/AgentQueueView.pm, I see the creation of HTML suddenly stopping mid-ticket in this loop at line 190.
# -- # show ticket's # -- foreach (@ViewableTickets) { print $Self->ShowTicket(TicketID => $_); }
but so far I haven't a clue what set of circumstances is giving rise to it.
Not quite sure what this is. Developers?
This is the loop to show the ticket in the queue view. In @ViewableTickets are the ticket ids to show.
Martin Edenhofer
-- ((otrs.de)) :: OTRS GmbH :: Norsk-Data-Str. 1 :: 61352 Bad Homburg http://www.otrs.de/ :: Manage your communication!
On Thu, 2004-04-15 at 13:26, Covert, Jake wrote:
These are just some random thoughts here. Sorry if confusing.
Thanks for those. I won't answer the rest of the message in detail. Suffice it to say that I have started from scratch with a copy of the production database, which I've updated using DBUpdate-to-1.2, and a fresh install of OTRS from otrs-1.2.3-01.tar.gz. The only things I've changed in Config.pm (copied from Config.pm.dist) are $Self->{DatabasePw} and $Self->{Home}. The problem - QueueView failing to get fully displayed in some cases and the browser remaining busy - is still present. So it is pretty clear it has nothing to do with any other configuration or modification that I do. I shall have to plug away with my debugging attempts. How do others debug Perl, and in particular, OTRS? Jim
Hi Jim, On Fri, Apr 16, 2004 at 02:02:56PM +0100, Jim Wight wrote:
These are just some random thoughts here. Sorry if confusing.
Thanks for those. I won't answer the rest of the message in detail. Suffice it to say that I have started from scratch with a copy of the production database, which I've updated using DBUpdate-to-1.2, and a fresh install of OTRS from otrs-1.2.3-01.tar.gz. The only things I've changed in Config.pm (copied from Config.pm.dist) are $Self->{DatabasePw} and $Self->{Home}.
The problem - QueueView failing to get fully displayed in some cases and the browser remaining busy - is still present. So it is pretty clear it has nothing to do with any other configuration or modification that I do.
I shall have to plug away with my debugging attempts. How do others debug Perl, and in particular, OTRS?
I would say, the easiest way to debug is to add print STDERR "Some Text\n"; to some points in e. g. Kernel/Modules/AgentQueueView.pm and try to find out where it stops (webserver error log). PS: You also can use Plain-CGI for your webserver so you don't need to restart your webserver any time.
Jim
Martin -- ((otrs.de)) :: OTRS GmbH :: Norsk-Data-Str. 1 :: 61352 Bad Homburg http://www.otrs.de/ :: Manage your communication!
On Fri, 2004-04-16 at 15:29, Martin Edenhofer wrote:
I would say, the easiest way to debug is to add
print STDERR "Some Text\n";
to some points in e. g. Kernel/Modules/AgentQueueView.pm and try to find out where it stops (webserver error log).
I can see no sign of the output anywhere in the server's log when using that method. Previously I was trying to write to the same file from different OTRS files, but I have a feeling I was having a problem with buffering. If I use strace to latch onto the process running bin/cgi-bin/index.pl at the point where the browser has stopped outputting, the output begins: write(2, "Charset encode \'us-ascii \' -=> \'iso-8859-15\' followed by text from the body of the next ticket to be displayed. After a long delay the browser stops being busy, and more output appears, including my debugging output for file descriptor 2. Some of this output is valid-looking HTMl for file descriptor 1, but none of it gets displayed by the browser. It doesn't appear to include everything for all later tickets (as displayed by 1.1.1 on the production system) though.
PS: You also can use Plain-CGI for your webserver so you don't need to restart your webserver any time.
Yes. I haven't been using mod_perl. Jim
On Fri, Apr 16, 2004 at 04:47:45PM +0100, Jim Wight wrote:
I would say, the easiest way to debug is to add
print STDERR "Some Text\n";
to some points in e. g. Kernel/Modules/AgentQueueView.pm and try to find out where it stops (webserver error log).
I can see no sign of the output anywhere in the server's log when using that method. Previously I was trying to write to the same file from different OTRS files, but I have a feeling I was having a problem with buffering.
If I use strace to latch onto the process running bin/cgi-bin/index.pl at the point where the browser has stopped outputting, the output begins:
write(2, "Charset encode \'us-ascii \' -=> \'iso-8859-15\'
followed by text from the body of the next ticket to be displayed. After a long delay the browser stops being busy, and more output appears, including my debugging output for file descriptor 2. Some of this output is valid-looking HTMl for file descriptor 1, but none of it gets displayed by the browser. It doesn't appear to include everything for all later tickets (as displayed by 1.1.1 on the production system) though.
Jim, I have no more ideas. What OS do you use?
Jim
Martin -- ((otrs.de)) :: OTRS GmbH :: Norsk-Data-Str. 1 :: 61352 Bad Homburg http://www.otrs.de/ :: Manage your communication!
participants (3)
-
Covert, Jake -
Jim Wight -
Martin Edenhofer