[Y2038][time namespaces] Question regarding CLOCK_REALTIME support plans in Linux time namespaces

[Petr Špaček]

On 30. 10. 20 23:19, Carlos O'Donell via Libc-alpha wrote:
> On 10/30/20 4:06 PM, Thomas Gleixner wrote:
>> On Fri, Oct 30 2020 at 12:58, Carlos O'Donell wrote:
>>> I expect that more requests for further time isolation will happen
>>> given the utility of this in containers.
>> There was a lengthy discussion about this and the only "usecase" which
>> was brought up was having different NTP servers in name spaces, i.e. the
>> leap second ones and the smearing ones.
> In the non-"request for ponies" category:
> 
> * Running legacy 32-bit applications in containers with CLOCK_REALTIME set
>   to some value below y2038.
> 
> * Testing kernel and userspace clock handling code without needing to
>   run on bare-metal, VM, or other.

Let me add one real-life example:
Testing network protocol implementations based on packet/conversation replay.

In case of DNSSEC protocol conversations have real time values in them which cause "expiration", thus packet captures are useful only if real time clock reflects values during the original conversation. In our case packet captures come from real Internet, i.e. we do not have private keys used to sign the packets, so we cannot change time values.

This use-case also implies support for settime(): During the course of a test we shorten time windows where "nothing happens" and server and client are waiting for an event, e.g. for cache expiration on client. This window can be hours long so it really _does_ make a difference. Oh yes, and for these time jumps we need to move monotonic time as well.

At the moment we employ libfaketime but it is a horrible hack and makes debugging (when a test breaks) hard. Debugging with armed LD_PRELOAD is not fun either and combining libfaketime with RR debugger can be quite nasty.

As for VMs ... that does not seem really scalable. A single conversation replay takes 1-3 seconds (once periods of silence are shortened), so we run many tests in parallel and each test has its own notion of time (thanks to libfaketime). Spinning VMs and all the overhead around it would cost order of magnitude more than running tests itself, which is bad with hundreds of tests to go.

Hopefully this ilustrates that real time name space is not "request for ponny" :-)

-- 
Petr Špaček  @  CZ.NIC