Testing application timing

Question

We've developed an in-house application, with several related crons that execute at some time during the day. These crons are designed in such a way that they make sure that they ignore, for example, being executed before 7:00 am, or only execute once a day or week.

This particular approach is chosen to ensure that the task at hand is not executed when nobody is at the office (for example), but also allows to run every X minutes to 'retry' if the cron somehow failed to execute (and ensures execution when the server has some downtime as an added bonus).

Furthermore, some parts of the software rely on the current system's date, to inform one of the API's used of some action, like deleting a remote object that has expired in the program. These parts are either invoked by the crons, by some user (where a check is done on the current time) or a remote API.

We are now in the stage to test this application with several end-users and we want to create a fully operational environment. However, as most cycles in the application take a year or so to complete, we are looking for ways to make the server time 'run faster', i.e. one day per real-world minute or so. However, we also need to visit every hour of the day to make sure everything runs smoothly. Effectively, the server time would be increased 1440 times during the test.

Is there some 'nice' way to accomplish this on a Linux (CentOS) server, or is the only way to let another cronjob increase the time? Are there disadvantages of such an approach?

score 2 · Answer 1 · answered Feb 08 '11 at 08:34

2

Rather than fiddling with the system clock, I'd suggest using 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).

Then you can write test driver that calls each of the system components with the appropriate fake time.

answered Feb 08 '11 at 08:34

MikeyB

39,291
10
105
189

I don't relly see how I could use FTPL to speedup the timing for both the cron and the application. FTPL seems only to modify the time to a fixed time (and count from there at normal speed). – ralphje Feb 09 '11 at 21:16
Right, it doesn't speed up the time, but you can use it to pretend that the time is different for the component of the system under test. If this doesn't suit you, you could use another system with an unaltered clock to drive clock changes on the test system (say, via remotely-issued commands). Or, have your test driver script adjust the time to the next stage when the previous one is complete. – MikeyB Feb 10 '11 at 16:33

score 0 · Answer 2 · edited May 23 '17 at 12:41

Two similar questions have already be answered here and here.

The nicest way to speedup the system clock is to use the system calls adjtime or adjtimex, but they adjust the clock very slowly to not disturb the processes relying on accurate time intervals.

The cronjob solution will cause regular time jump which will certainly disturb some program running on your server (for example, cron could fail to launch a job if the clock jumped over the time when the job should have be launched)

Testing application timing

2 Answers2