L'horloge Linux échouera-t-elle le 19 janvier 2038 3:14:08?

23

Cela m'inquiète un peu. C'est ce qu'on appelle le «problème de l'an 2038». Le noyau Linux ou Ubuntu est-il prêt à gérer les dates après cela, à partir du 12.04?

time

— ThePiercingPrince
source

8

Avez-vous essayé de régler votre horloge sur quelque chose comme le 19 janvier 2038 3:14:07 et attendez une seconde?

— gertvdijk

2

Supposons que ce problème existe et n'est pas encore résolu. 12.04 ne sera pas pris en charge pour toujours, donc vous et toutes les autres personnes serez sur une distribution mise à jour jusqu'à ce que cela se produise, car il y a de nombreuses années entre les deux. La mise à jour est simple. L'une de ces mises à jour contiendra sûrement un correctif. Il n'y a donc aucune raison de s'inquiéter, mais c'est effectivement une question intéressante.

— verpfeilt

3

Le bug a déjà été corrigé.

— ThePiercingPrince

L'horloge système ne le fera pas (pas sur un noyau raisonnablement récent de toute façon); certaines structures de données (et les programmes qui les utilisent) peuvent présenter un comportement anormal. À mon avis, ce sera un problème avec les appareils intégrés - ceux-ci sont beaucoup moins susceptibles d'exécuter le code actuel.

— Piskvor

1

@hmayag: Je ne pensais pas "grille-pain", plutôt "contrôleur de feux tricolores". Ces choses sont un peu plus robuste que l' électronique de qualité des consommateurs et pourrait facilement dépasser la durée de vie qui (avec partie de remplacement, mais peut - être sans mises à niveau) - IIRC, il y avait quelques problèmes avec ces appareils électroniques des années 1980 , juste après Y2K.

— Piskvor

13

Non, cela n'échouera pas. Dans le pire des cas, du point de vue d'un programmeur, cela fonctionnera comme prévu: il sera réinitialisé à ce jour 1901-12-13 20:45:52:

entrez la description de l'image ici

Ceci au cas où vous ne mettriez pas à jour vos distributions actuelles jusqu'à ce que cela se produise. "La mise à jour est facile. L'une de ces mises à jour contiendra sûrement un correctif ", comme le disait chocobai .

Je me souviens que c'était le même problème / question avec les machines 16 bits avant 2000 et finalement ce n'était pas un problème.

Une solution de Wikipedia:

La plupart des systèmes d'exploitation conçus pour fonctionner sur du matériel 64 bits utilisent déjà des time_tentiers signés 64 bits . L'utilisation d'une valeur signée 64 bits introduit une nouvelle date enveloppante qui est plus de vingt fois supérieure à l'âge estimé de l'univers: environ 292 milliards d'années à partir de maintenant, à 15h30:08 le dimanche 4 décembre 292.277.026.596. La possibilité de faire des calculs sur les dates est limitée par le fait quetm_yearutilise une valeur int 32 bits signée à partir de 1900 pour l'année. Cela limite l'année à un maximum de 2.147.485.547 (2.147.483.647 + 1900). Bien que cela résout le problème de l'exécution des programmes, cela ne résout pas le problème du stockage des valeurs de date dans des fichiers de données binaires, dont beaucoup utilisent des formats de stockage rigides. Il ne résout pas non plus le problème des programmes 32 bits exécutés sous des couches de compatibilité et peut ne pas résoudre le problème des programmes qui stockent de manière incorrecte les valeurs de temps dans des variables de types autres que time_t.

J'utilise Ubuntu 13.04 sur 64 bits et, par curiosité, j'ai changé manuellement l'heure en 2038-01-19 03:13:00. Après 03:14:08, rien ne s'était passé:

Date et heure avant le 2038-01-19 03:14:08 Date et heure après 2038-01-19 03:14:08

Il n'y a donc rien à craindre de ce problème.

Plus à propos:

— Radu Rădeanu
source

9

S'il se réinitialise, il échoue car par «échouer», je veux dire «ne fonctionne pas ou ne fonctionne pas correctement».

— ThePiercingPrince

1

@LinuxDistance Cela se produit de votre point de vue. Mais du point de vue d'un programmeur, cela fonctionnera comme prévu: il se réinitialisera . C'était la même chose avec la fin du calendrier maya: le monde n'a pas échoué à cause de cela.

— Radu Rădeanu

10

Je ne suis pas d'accord? du point de vue d'un programmeur une horloge n'est pas censé remis à zéro, il va échouer

— Nanne

3

Cette discussion dans les commentaires est inutile. La question est "Le noyau Linux ou Ubuntu est-il prêt à gérer les dates après cela?". Eh bien, il n'est pas capable de gérer de telles dates, donc il échoue dans le contexte de cette question.

— gertvdijk

2

@gertvdijk "Le noyau Linux " actuel / actuel "ou Ubuntu est-il prêt à gérer les dates après cela?"

— Radu Rădeanu

7

Vous pouvez vérifier si l'heure de votre ordinateur va planter en utilisant le script Perl suivant:

#!/usr/bin/perl
use POSIX;
$ENV{'TZ'} = "GMT";
for ($clock = 2147483641; $clock < 2147483651; $clock++) {
    print ctime($clock);
}

Si votre ordinateur va bien, vous obtiendrez ceci:

Tue Jan 19 03:14:01 2038
Tue Jan 19 03:14:02 2038
Tue Jan 19 03:14:03 2038
Tue Jan 19 03:14:04 2038
Tue Jan 19 03:14:05 2038
Tue Jan 19 03:14:06 2038
Tue Jan 19 03:14:07 2038       <-- Last second in 32-bit Unix systems
Tue Jan 19 03:14:08 2038
Tue Jan 19 03:14:09 2038
Tue Jan 19 03:14:10 2038

Si votre ordinateur est comme le mien, il se terminera comme suit:

Tue Jan 19 03:14:01 2038
Tue Jan 19 03:14:02 2038
Tue Jan 19 03:14:03 2038
Tue Jan 19 03:14:04 2038
Tue Jan 19 03:14:05 2038
Tue Jan 19 03:14:06 2038
Tue Jan 19 03:14:07 2038
Fri Dec 13 20:45:52 1901
Fri Dec 13 20:45:52 1901
Fri Dec 13 20:45:52 1901

Il pourrait également faire ceci:

Tue Jan 19 03:14:01 2038
Tue Jan 19 03:14:02 2038
Tue Jan 19 03:14:03 2038
Tue Jan 19 03:14:04 2038
Tue Jan 19 03:14:05 2038
Tue Jan 19 03:14:06 2038
Tue Jan 19 03:14:07 2038
Tue Jan 19 03:14:07 2038
Tue Jan 19 03:14:07 2038
Tue Jan 19 03:14:07 2038

— SkylarMT
source

Je pense que vous testez Perl ici et non le vrai système d'exploitation dans le noyau. Ou êtes-vous, avec l'utilisation de ctime?

— gertvdijk

@gertvdijk Eh bien, cela donne la première sortie sur les ordinateurs corrigés, et mon portable Ubuntu en donne la seconde, tandis que le troisième vient de mon serveur Debian. Je n'ai pas vraiment écrit le code, il est partout sur Internet sous la même forme exacte.

— SkylarMT

2

confirmé. si vous avez une machine 64 bits, ce sera parfait. D'ailleurs ... qui d'entre nous aura encore des machines 32 bits en fonctionnement en 2038?

— JRG

1

Je suis allé chercher cela pour illustrer le problème de 2038 à un collègue, et 2 ans après avoir fait le commentaire ci-dessus, je ne doute pas qu'en 2038, nous aurons des machines 32 bits qui échoueront. Ah, optimisme juvénile.

— jrg

@James, peut-être certains sans le vouloir. Il y aura probablement Linux embarqué 32 bits dans les appareils IoT à ce moment-là, non corrigé. Fin du monde? Non. Des ennuis à certains endroits? Absolument.

— professeur Falken soutient Monica

3

J'ai écrit et publié un court article à ce sujet en 1996. Cela comprenait un court programme C pour le démontrer. J'ai également eu des courriels avec David Mills au sujet de problèmes similaires avec NTP - le Network Time Protocol. Sur mon ordinateur portable Ubuntu 14.04 64 bits, le code Perl ne présentait pas de limitation, les bibliothèques 64 bits sous-jacentes doivent donc avoir été modifiées.

Cependant, l'exécution de mon code de test il y a longtemps montre que le temps revient à l'époque UNIX. Donc tout ne va pas bien avec le code 32 bits du passé.

Mon article de 1996, L'heure UNIX s'achèvera en 2038! a été sur mon site depuis environ 2000. Une variante de ce titre "UNIX Time" a été publiée en 1998 dans "Year 2000 Best Practices for Y2K Millennium Computing" ISBN 0136465064.

— oldunixguy
source

2

Linux 64 bits est prêt, du moins si vous parlez des interfaces OS principales (les applications individuelles peuvent bien sûr encore le bousiller). time_t est traditionnellement défini comme un alias pour "long" et "long" sur linux 64 bits est 64 bits.

La situation pour Linux 32 bits (et la couche de compatibilité pour les binaires 32 bits sur Linux 64 bits) est beaucoup moins rose. Il est cassé et le réparer sans casser tous les binaires existants n'est pas une tâche facile. Un tas d'API utilise time_t et dans de nombreux cas, il est intégré dans les structures de données, donc non seulement les API doivent être dupliquées, mais les structures de données avec lesquelles elles travaillent doivent l'être également.

Même s'il existe un certain niveau de compatibilité descendante, tous les fichiers binaires qui souhaitent obtenir l'heure correcte devront être reconstruits pour utiliser les nouvelles interfaces temporelles 64 bits.

Il y a eu du travail (voir par exemple https://lwn.net/Articles/643234/ et http://www.sourceware.org/ml/libc-alpha/2015-10/msg00893.html ) mais afaict nous sont encore loin d'une solution complète. Il n'est pas clair s'il y aura ou non des distributions 32 bits à usage général qui sont sécurisées par Y2K38.

— Peter Green
source