OTRS4 e alteração de horário de verão

557 views
Skip to first unread message

Alisson R. de Oliveira

unread,
Feb 23, 2015, 8:10:09 AM2/23/15
to otrsb...@googlegroups.com
Bom dia, alguém teve problema com o OTRS e alteração de horário de verão?

Estamos tendo um comportamento estranho do apache, que fica ocupando 100% de CPU. Pelo strace dá pra ver que o processo do apache fica executando stat no arquivo /etc/localtime o tempo inteiro e não passa dessa parte.

Até o momento não identifiquei o motivo de isso estar acontecendo. A única soluçao é remover o arquivo /etc/localtime, assim o processo fica normal.

Essa situação acontece em qualquer página que lista tickets, como Dashboard, AgentTicketQueue, etc.

__________________
--
Alisson Oliveira
www.unirede.net
Twitter|Facebook|Blog|Youtube
Porto Alegre - RS – Brasil

Ronaldo Richieri - Complemento Web, TI e Comunicação

unread,
Feb 23, 2015, 8:37:41 AM2/23/15
to otrsb...@googlegroups.com

Alisson,


Já tive alguns problemas com alteração de horário de verão. Na verdade, nas instalações padrão do CentOS e Ubuntu se não me engano, o fuso (/etc/localtime) aqui em Sampa fica apontado para alguma coisa como /usr/share/zoneinfo/America/Sao_Paulo

Quando isto ocorre, temos vários problemas de contagem de SLA que fica errada, as vezes o problema do pending time também.

Como solução de contorno, criamos um link simbólico do /etc/localtime apontando para:

/usr/share/zoneinfo/Etc/GMT+2 no horário de verão

/usr/share/zoneinfo/Etc/GMT+3 no restante do ano.

Sim, é "+" mesmo, não é GMT-3. Por alguma razão maluca, Linus Torvalds resolveu inverter a relação do fuso no sistema. Alguma coisa do tipo "Greenwich não é o centro do mundo porra nenhuma", então ele quis colocar no sistema que Greenwich está +3 do horário local e não que nós estamos -3 em relação a greenwich hehehehehe. Acho que foi isso.

Se vc coloca GMT-3, o Daemon do NTPDate vai colocar o horário com 6 horas de diferença.

Bom, não sei se esse workaround vai resolver seu problema, mas você poderia tentar.

E a gente poderia abrir um grupo de trabalho e analisar esse código que faz a contagem de tempo, por que ali tem um BUG sim senhor :)

Abraços!


--
Você recebeu essa mensagem porque está inscrito no grupo "OTRS Brasil" dos Grupos do Google.
Para cancelar inscrição nesse grupo e parar de receber e-mails dele, envie um e-mail para otrsbrasil+...@googlegroups.com.
Acesse esse grupo em http://groups.google.com/group/otrsbrasil.
Para mais opções, acesse https://groups.google.com/d/optout.

Ronaldo Richieri - Complemento Web, TI e Comunicação

unread,
Feb 23, 2015, 8:43:02 AM2/23/15
to otrsb...@googlegroups.com
Só pra completar,sobre o problema que temos, quando um chamado é criado por exemplo 2 dias antes da mudança de horário de verão, seja para entrar ou sair dele, e se o SLA tem por exemplo 5 dias de solução, com a configuração apontada para "America/Sao_Paulo", o sistema se perde na contagem. Por alguma razão,o Perl se perde com esse arquivo que contempla a mudança automática do fuso.

O mesmo ocorre com o campo Pending Time. Quando está preste a ocorrer a mudança do horário de verão, se colocamos uma data no campo "Data de Pendencia" próxima ao dia da mudança de fuso, dá um pau dizendo que a data é invalida, por que é menor do que a data atual.

Quando fixamos em GMT+3 ou GMT+2, isso não ocorre, porém.... temos o trabalho de alterar nos dias de mudança do fuso horário, seja manualmente ou com scripts....

Talvez, valha a pena experimentarmos definir UTC e ver como melhorar.

Enfim, como disse, não sei se vai resolver seu problema, mas experimenta colocar GMT+3 e ver se o problema para. (Só não faça em produção, pode afetar os calculos de SLA do seu cliente em uma hora)

Alisson R. de Oliveira

unread,
Feb 23, 2015, 9:09:17 AM2/23/15
to otrsb...@googlegroups.com
Ronaldo, realmente, alterei manualmente para o GMT+3 e funcionou. Vou investigar melhor e propor alguma solução para a OTRS Inc.

__________________
--
Alisson Oliveira
www.unirede.net
Twitter|Facebook|Blog|Youtube
Porto Alegre - RS – Brasil


Thiago Pacheco

unread,
Feb 23, 2015, 9:17:42 AM2/23/15
to otrsb...@googlegroups.com
Bom dia !

Podemos abrir um grupo de trabalho para analisar este código. Como primeiro ponto vamos registrar este BUG no OTRS e que sabe posteriormente, contribuirmos com a solução.

Lembrando que este problema que o Alisson falou, aconteceu na versão 4.x. Mais alguém passou por isso ? 
Thiago Pacheco




Ronaldo Richieri

unread,
Feb 23, 2015, 10:06:23 AM2/23/15
to otrsb...@googlegroups.com

Esse cliente de vocês tem slas configurados? Se sim, vocês poderão ter algum problema.

A contagem do sla se dá basicamente pela data de criação do chamado que é armazenado em unixtime e a data de encerramento que é no formato YYYY-MM-DD HH:MM:SS

O unixtime é armazenado de acordo com o horário GMT. Então o chamado pode ter sido criado as 10h, quando o GMT era -2 no banco de dados (+2 pro unix)

Com esta alteração, quando o BD for ler esta data agora, utilizando a função fromunixtime provavelmente, ele lerá como se o chamado tivesse disso criado as 9h da manhã, ou seja, você perde 1h de sla :(

Quando registrarem o bug, compartilhem o link aqui por favor.

Michell Antunes

unread,
Feb 23, 2015, 11:27:47 AM2/23/15
to otrsb...@googlegroups.com
Obrigado pessoal,

OTRS parado aqui também por este motivo. Solução sugerida pelo Ronaldo corrigiu o problema.


att



Michell Antunes Supervisor de TI, Certto Telecom

Rua Paraná 3015, Sala 02, Cascavel/PR

Tel: (45) 3333-2100 | 0800-645-3335 | INOC 28130*100  
michell...@certto.com.br|www.certto.com.br

TwitterLinkedInFacebook

Reply all
Reply to author
Forward
0 new messages