Re: per-chroot clock module ?

[Andre Tomt <andre@tomt.net>]

On 11/27/2010 08:22 PM, Jason Vas Dias wrote:
> RE: why ?
> This would allow one to very easily support websites for totally different timezones , where offsets need not be
> restricted to legal timezone offsets but could encompass years - also nice if you want to run applications whose
> license key has expired .  Also very easy to support multiple instances of cron(1) running in different timezones.
> In any case, the module would ensure that the time the kernel sees internally for all processes is the actual real-time
> clock value; only processes which have their root directory in one of the special chroot directories would get
> a different gettimeofday() or clock_gettime() value .
>
>>
>> It seems like what you want here is simple virtualization. Have you
>> considered KVM? The closest thing to your request currently upstream is
>> containers, although I'm unsure of whether a container can be created
>> with an independent clock. Might be something to look into.
>>
>
> To me, using virtualization to solve this problem is like using a sledgehammer to crack a nut,
> particularly if the optimal performance of the processes running in such chroot environments
> is of paramount importance.

You might want to take a look at Linux-Vserver; it has containers (that 
is, chroot on stereoids) with support for "virtualized time"/clock offset.

Virtualized time is not without downsides, it adds overhead. It will be 
tiny compared to using a sledgehammer of course. The vserver guys puts 
it this way;
"This enables per guest time offsets to allow for adjusting the system 
clock individually per guest. this adds some overhead to the time 
functions and therefore should not be enabled without good reason."

http://linux-vserver.org/

It could be useful to implement such a thing in a "time" namespace, 
making it available to lxc containers and cgroups also.