Kodefejl stopper dansk aktiehandel brat

FinansNetbankens kunder har i tre dage ikke kunnet foretage aktiehandler efter et strømnedbrud førte til en mystisk kodefejl, der forhindrer adgang til Fondsbørsens systemer.

En strømafbrydelse førte til en mystisk kodefejl i et script. Sådan lyder forklaringen på, at FinansNetbankens kunder i flere dage ikke har kunnet udføre aktiehandler. Jyske Bank, der har overtaget FinansNetbankens kunder, arbejder på højtryk for at få tingene på plads, skriver Computerworld.

»En strømafbrydelse betyder, at der ikke er adgang til Fondsbørsen. Vi ved ikke hvornår problemet er løst,« står der blandt andet i en popup-meddelelse, som kunderne bliver mødt af, når de forsøger at logge på investeringsportalens handelsmuligheder, skriver Computerworld.

Efter strømafbrydelsen, var der problemer med synkroniseringen med Sparekassernes Datacentralers, SDC, systemer.

»Efter genstarten manglede der pludselig en linje i et script. Det kan vi ikke helt forklare endnu, men vi arbejder på at finde et svar. Hvordan en linje i et script kan forsvinde i denne sammenhæng er stadig en gåde, siger Gunnar Kappel, it-konsulent i Jyske Bank, til Computerworld.

Nogle af problemerne skulle efter sigende være blevet løst, og derfor skulle man nu kunne foretage strakshandler samt lægge en bestilling ind i systemet - handler er dog fortsat ikke mulige.

Tips og korrekturforslag til denne historie sendes til tip@version2.dk
Kommentarer (10)
sortSortér kommentarer
  • Ældste først
  • Nyeste først
  • Bedste først
#1 Rasmus Arndal

Kan nogen med teknisk indsigt forklare mig et par ting, som jeg ikke forstår, i denne artikel? Hvad mon kan hindre dem i at hente den rette linje fra deres versionskontrol-system? Hvordan kan en strømafbrydelse fjerne en linje i et script? Når et script eksekveres, er script-filen vel kun åbnet med læserettigheder?

  • 1
  • 0
#3 Finn Aarup Nielsen

Hvad mon kan hindre dem i at hente den rette linje fra deres versionskontrol-system?

Jeg forstår det heller ikke. Måske er opdagelsen sket ved at sammenligne med versionkontrolsystemets version. D kan måske nemt gendanne versionen, men ønsker at undersøge hvorfor linien mangler. En så besynderlig fejl stiller jo spørgsmål ved hele integriteten af systemet.

Man kan spørge om FinansNetbanken er en af de 42?

http://www.version2.dk/artikel/hackere-advarer-42-danske-netbanker-er-fy...

  • 0
  • 0
#4 Lars Tørnes Hansen

Kort fortalt er det lavere niveau: Hardware. Hardwares rettigheder er givet af fysikkens love.

Jeg gætter på at de skal kigge på deres strøm system - incl strømforsyninger - da digitalelektronik begynder at opføre sig analogt ved ukorrekt spændingsforsyning - f.eks. kan hukommelsesbits skifte fra logisk 1 til logisk 0 og omvendt. Hvis det sker kan man ikke længere stole på logikken i nogen som helst form for software (styresystemet, og embedded software i harddisk contollere inklusive).

Jeg har f.eks. i embedded software set både kode der blev hoppet over og kode der blev kørt i en loop lige efter hinanden, og det var selv om der hverken var skyggen af en if sætning, eller en for løkke - det var kun en sekvens af maskinkode instruktioner. I det nævnte tilfælde var problemet et elektrisk signal der var 1,3 volt for lavt (3,3 volt logik), hvilket skabte ged i noget logik, der stod for I²C bus I/O i en microcontroller.

  • 1
  • 0
#6 Lars Tørnes Hansen

Men sådan en fejl kan vel ikke ske for en fil, der ligger på en harddisk

Jo da

Læse skrivehoveder bevægelser, og skivehoved-impulser er styret af software der afvikles i en mikrocontroller (som sidder imellem harddisk I/O og aktuatoren der bevæger læse-skrivehoveds arm og læser fra læse-hovedet samt skriver og sletter med læse-hovedet)

  • 1
  • 0
#8 Sune Marcher

Læse skrivehoveder bevægelser, og skivehoved-impulser er styret af software der afvikles i en mikrocontroller (som sidder imellem harddisk I/O og aktuatoren der bevæger læse-skrivehoveds arm og læser fra læse-hovedet samt skriver og sletter med læse-hovedet)

Lyder usandsynligt at specifik og afgrænset fejl skulle være forårsaget af ekstrem low-level hardware issue.

Jeg ville nærmere gætte på et filsystem der cacher lidt for aggressivt, på et mount uden særligt meget aktivitet, kombineret med ux mentaliteten om ikke at denie andre processer adgang til in-use filer, men lave refcounting og først slette gammelt data når sidste åbne fil-handle bliver lukket.

Har set et par issues over årene der kunne minde om ovenstående, omend med config-filer og ikke scripts.

  • 0
  • 0
#9 Lars Tørnes Hansen
  • 1
  • 0
#10 Kai Birger Nielsen

@Lars Tørnes Hansen: Jeg vil nu gerne høre flere gætterier.

Jo flere mærkelige ting, man har set, jo bedre bliver man til at fejlfinde på den her slags fejl. Og navnlig til at lave overvågning, der kan fange "once in a blue moon" fejl. Vi havde på et tidspunkt en modempulje, hvor et af mine statistikscripts lagde mærke til at et af modemerne aldrig havde en login. Det viste sig at teleselskabet havde kodet et forkert nummer ind i puljen, så dels havde vi ingen gavn af modem4 og dels må der en gang imellem være nogen et sted, der blev ringet op af en af vores medarbejderes modemforbindelser hjemmefra :-)

Jeg har også set et modem, der tilsyneladende virkede fint, men som en dag ikke kunne ringes op. En måling på strømforsyningen viste at den var gået over til at levere 0.45 V i stedet for 4.5 V, så jeg er helt med på din pointe om også at kigge nedad, når man leder efter nisser.

  • 1
  • 0
Log ind eller Opret konto for at kommentere