Auf der Kernel-Mailingliste reichte Entwickler Dmitri Safonow gestern Patches für Time Namespaces ein. Die sollen vor allem in Containern die Uhren neu stellen.
Der Entwickler arbeitet bei Arista Networks und hat nun zahlreiche Patches geschickt, um die Zeit-Namespaces zu implementieren. Wie er auf der Mailingliste schreibt, starteten die Bemühungen um Time Namespaces bereits 2006. Sie haben vor allem zwei Gründe: Einerseits wollen Admins in der Lage sein, Datum und Zeit innerhalb von Containern zu ändern. Andererseits möchten sie die Zeit nach dem Wiederherstellen eines Containers aus einem Checkpoint anpassen.
Als Begründung für die Notwendigkeit des Features zieht Safonow auch das Zitat eines Entwicklers auf Github heran, der die fehlenden Time Namespaces als Haupthindernis für eine Migration auf Container ausmacht.
Zeit für Per-Namespace-Offsets
Generell erlaube der Kernel dabei den Zugriff auf verschiedene Uhren: “CLOCK_REALTIME”, “CLOCK_MONOTONIC” und “CLOCK_BOOTTIME”. Für viele Nutzer seien die Time Namespaces identisch mit der Fähigkeit, Datum und Zeit in Containern zu ändern, über “CLOCK_REALTIME”. Aber beim Wiederherstellen von Containern aus Checkpoints werden laut Safonow auch “CLOCK_MONOTONIC” und “CLOCK_BOOTTIME” interessant.
Diese gleichbleibenden Uhren kommen zum Einsatz, um Zeitsegmente zu messen und Timer zu setzen. Damit wiederhergestellte Prozesse nicht aus der Zeit fallen, sollten sich diese gleichbleibenden Uhren so verhalten, wie sie es bei einem Suspend des Gesamtsystems tun. Über Per-Namespaces-Offsets will Safonow diese Uhren mit seinen Patches anpassen.
Der System Call “unshare(CLONE_NEWTIME)” erzeugt dabei einen neuen Time Namespace, setzt diesen aber nicht für den laufenden Prozess. Stattdessen erzeugt er für alle Kindprozesse des aktuellen Prozesses einen neuen Time Namespace. Vorhandene Prozesse dürfen sich diesem über “setns()” anschließen. Auf diese Weise lassen sich Clock Offsets für einen Namespace also setzen, bevor die Prozesse selbst erscheinen.
