Lecsap az Y2K22: Nem volt mindenhol zökkenőmentes az átállás 2022-re

Ha tetszett, oszd meg ismerőseiddel!

Már néhány napja az új évet tapossuk, és biztos, hogy vagyunk páran, akik még mindig 2021-et írunk a dátum mezőkbe. Ezt már megszoktuk, kell pár nap míg átáll az agyunk, főleg ilyen időkben, mikor a kelleténél kicsi jobban összefolynak a napok, hetek, hónapok.

A számítógépes rendszereknek azonban – általában – nem szokott problémát okozni az átállás az új évre. Azonban időről-időre felüti a fejét az Y2K-jelenségnek nevezett hiba. Ilyenkor valamilyen rendszerhiba miatt a rendszerek éveket, évtizedeket repülnek vissza az időben.

Azt hinnénk, hogy így 2021-ben 2022-ben a legritkább esetben, és csak elvétve fordulhat elő ilyen hiba, ám ahogy a Bleeping Computer cikkeiből kiderül, a jelenség még a legnagyobb szoftvergyártókat is megviccelheti. Most három, vélhetően hasonló hibából eredő probléma is napvilágot látott, és valószínűleg nem ezek lesznek az utolsók.

Microsoft Exchange

Microsoft Exchange

Az első a Microsoft Exchange 2016 és 2019 között telepített szervereinél jelentkezhetnek problémák. A hibajelenség akkor jelentkezik, amikor a kiküldött vagy fogadott emaileket az Exchange szerver átvizsgálja FIP-FS antivírus szoftverrel, majd dátummal együtt megpróbálja naplózni az eredményt. Ez azonban nem sikerül, és az alábbi hibaüzenetekkel elszáll a folyamat.

og Name: Application 
Source: FIPFS 
Logged: 1/1/2022 1:03:42 AM 
Event ID: 5300 
Level: Error 
Computer: server1.contoso.com
Description: The FIP-FS "Microsoft" Scan Engine failed to load. PID: 23092, Error Code: 0x80004005. Error Description: Can't convert "2201010001" to long.
Log Name: Application 
Source: FIPFS 
Logged: 1/1/2022 11:47:16 AM 
Event ID: 1106 
Level: Error 
Computer: server1.contoso.com 
Description: The FIP-FS Scan Process failed initialization. Error: 0x80004005. Error Details: Unspecified error.

A problémát az okozza, hogy ezekben a verziókban – számomra érhetetlen okokból – 32-bites integerben tárolják el a dátumot így a maximálisan felvehető érték 2,147,483,647. Mivel a dátumot yymmddHHmm formátumra alakították át, ezért 2022. január 1-én 32-bites ingerre átírva a dátumot már egy jóval nagyobb értéket kaptunk: 2,201,010,001. Ezt azonban már nem lehetséges tárolni, így hibaüzenettel elszáll a folyamat.

A Microsoft egyelőre csak egy hotfixet adott ki, és ígéretük szerint folyamatban van rendes frissítés is. Az Exchange szerverek üzemeltetőink biztosan lesz még pár álmatlan éjszakája addig.

SonicWall

SonicWall Y2K22

Nem a Microsoft az egyetlen szoftvercég, amely hasonló módon gondolkodott az emailek dátumának naplózásáról. Pár napja derült ki, hogy a SonicWall kiberbiztonsági és tűzfal szoftvereket gyártó céget is elérte az Y2K22 probléma. Ott ugyanis a levélszemeteket nem lehetett elérni semmilyen felhasználói jogosultsággal. Továbbá a bejövő és kimenő emailek naplótevékenység követésére sem volt lehetőség január első napjaiban. Ők azóta kiadták a javításukat, innentől kezdve csak az üzemeltetőkön múlik minden.

Honda és Acura

Acura Honda Y2K22

Hasonló probléma léphetett fel a Honda és Acura autók navigációs szoftverében, ott ugyanis 2022 helyett 2002-t ír a kijelző, és a jármű tulajdonosok semmilyen módon nem tudják visszaállítani a helyes értékre. A Honda tud a hibáról, és idén (!!) még megpróbálják orvosolni a problémát. Hiába, az autóiparban lassabban őrölnek az IT malomkerei.

Frissítés: itt inkább a GPS-től kapott idővel lehet probléma, amihez időnként szinkronizál. A GPS műholdaktól csak a hét sorszámát és a héten belüli időt adja vissza, ebből tudja kiszámítani az időt. Ezt azonban egy integerben tárolják le, ami kb 20 évig működik jól, aztán átfordul.

Honda Y2K22 bug
Ez nem egy 2002-es kép, hanem 2022-ben készült egy Honda navigációs kijelzőjéről. Forrás: Twitter

Programozási katasztrófák

Ezek a hibák ugyan elég nagy problémát tudnak okozni egyes rendszerekben, de néha az ilyen és hasonló jelenségek katasztrófákhoz is vezethetnek. Ha érdekel, hogyan vezethetnek program hibák millió dolláros károkhoz vagy akár ember életek kioltásához, akkor ajánlom figyelmedbe a Programozási katasztrófák első és második részét.


Ha tetszett, oszd meg ismerőseiddel!