Testando o tempo de aplicação

Question

Desenvolvemos uma aplicação interna, com vários crons relacionados que são executados em algum momento durante o dia. Esses crons são projetados de tal maneira que eles se certificam de que eles ignoram, por exemplo, serem executados antes das 7:00 da manhã, ou somente executar uma vez por dia ou semana.

Essa abordagem em particular é escolhida para garantir que a tarefa não seja executada quando ninguém está no escritório (por exemplo), mas também permite executar a cada X minutos para "tentar novamente" se o cron falhar na execução (e garante a execução quando o servidor tem algum tempo de inatividade como um bônus adicional).

Além disso, algumas partes do software contam com a data do sistema atual, para informar uma das APIs usadas de alguma ação, como excluir um objeto remoto que expirou no programa. Essas partes são invocadas pelos crons, por algum usuário (onde uma verificação é feita no horário atual) ou por uma API remota.

Estamos agora no estágio para testar esse aplicativo com vários usuários finais e queremos criar um ambiente totalmente operacional. No entanto, como a maioria dos ciclos no aplicativo leva cerca de um ano para ser concluído, estamos procurando maneiras de tornar o tempo do servidor 'mais rápido', ou seja, um dia por minuto real ou mais. No entanto, também precisamos visitar todas as horas do dia para garantir que tudo corra bem. Efetivamente, o tempo do servidor seria aumentado 1440 vezes durante o teste.

Existe alguma maneira 'boa' de conseguir isso em um servidor Linux (CentOS), ou é a única maneira de permitir que outro cronjob aumente o tempo? Existem desvantagens de tal abordagem?

    

Answer 1

Em vez de mexer no relógio do sistema, sugiro usar faketime

The Fake Time Preload Library (FTPL, a.k.a. libfaketime) intercepts various system calls which programs use to retrieve the current date and time. It can then report faked dates and times (as specified by you, the user) to these programs. This means you can modify the system time a program sees without having to change the time system-wide. FTPL allows you to specify both absolute dates (e.g., 2004-01-01) and relative dates (e.g., 10 days ago).

Então você pode escrever o driver de teste que chama cada um dos componentes do sistema com o tempo falso apropriado.

    

Answer 2

Duas perguntas semelhantes já foram respondidas aqui e aqui .

A melhor maneira de acelerar o relógio do sistema é usar o adjtime das chamadas do sistema ou o adjtimex, mas eles ajustam o relógio muito devagar para não perturbar os processos, dependendo de intervalos de tempo precisos.

A solução do cronjob causará um salto de tempo regular que certamente atrapalhará algum programa em execução no seu servidor (por exemplo, o cron poderá falhar ao iniciar um trabalho se o relógio saltar durante o tempo em que o trabalho deveria ser iniciado)