Fejlfinding af 'Operating System Call Failed' i SAP

Mange SAP-administratorer støder på kryptiske fejlmeddelelser i systemloggen (transaktion SM21), som kan være svære at afkode. En af de mest almindelige er 'Operating system call ... failed'. Denne meddelelse er ikke en applikationsfejl i SAP, men derimod en rapport om, at SAP-kernen har forsøgt at udføre en handling på operativsystemniveau – typisk relateret til netværkskommunikation – som er mislykkedes. At forstå disse fejl er afgørende for at opretholde et sundt og velfungerende SAP-landskab. Denne artikel vil guide dig igennem de mest almindelige varianter af denne fejl, hvordan du diagnosticerer dem, og hvad de underliggende årsager typisk er.

Hvad Betyder 'Operating System Call Failed' Præcist?

Når SAP skal kommunikere med andre systemer, databaser, eller endda interne processer over et netværk, benytter det sig af operativsystemets funktioner (systemkald) til at oprette, sende data over, og lukke netværksforbindelser. Fejlmeddelelsen 'Operating system call failed' betyder simpelthen, at operativsystemet har returneret en fejlkode til SAP, da SAP bad det om at udføre en sådan opgave. Fejlen kan opstå ved forsøg på at oprette forbindelse (connect), skrive data (write/writev), eller læse data (read). Det er SAP's måde at sige: 'Jeg bad operativsystemet om at gøre noget, men det sagde nej og gav mig denne fejlkode.' Det er derfor essentielt at kigge på den specifikke fejl og den medfølgende fejlkode for at finde rodårsagen.

Almindelige Varianter og Deres Årsager

Fejlen kommer i flere varianter, men to af de mest sete er 'connect failed' og 'writev failed'. Lad os se nærmere på, hvad de betyder.

Operating System Call Connect Failed

Dette er nok den mest hyppige version. Den opstår, når en SAP-proces (f.eks. en dialogproces, en ICM-tråd eller RFC-gatewayen) forsøger at etablere en TCP/IP-forbindelse til en anden vært (host) på et specifikt portnummer, men forsøget mislykkes.

Et typisk eksempel i SM21 kunne se sådan ud:

Q0I Operating system call connect failed (error no. <nnn>)

For at forstå, hvad der gik galt, skal man kigge i de mere detaljerede logfiler på samme tidspunkt. For RFC-kald vil det være Gateway-loggen (dev_rd):

*LOG Q0I=> NiPConnect2: <IP-adresse>:<port>: connect (<nnn>: Connection refused)

For HTTP-kald vil det være ICM-loggen (dev_icm):

* WARNING => Connect to [<målværtsnavn>]:[<portnummer>] failed: NIECONN_REFUSED(-10)

Årsagerne til 'connect failed' kan være mange:

• Connection refused: Dette er den mest almindelige årsag. Det betyder, at anmodningen nåede frem til målserveren, men der var enten ingen proces, der lyttede på den angivne port, eller en firewall på målserveren aktivt afviste forbindelsen. Det sker ofte, hvis en service er nede, eller hvis man forsøger at kalde en server, der er blevet nedlagt, men konfigurationen i SAP (f.eks. i SM59) stadig eksisterer.
• Connection timed out: Anmodningen blev sendt, men der kom aldrig noget svar tilbage inden for en given tidsgrænse. Dette peger typisk på netværksproblemer, såsom en firewall, der blokerer (dropper pakken i stedet for at afvise den), routing-problemer, eller at målserveren er helt nede eller utilgængelig på netværket.
• Resource temporarily unavailable (WSAEWOULDBLOCK): Dette er en mere teknisk fejl, der ofte ses på Windows. Det indikerer, at operativsystemet ikke kunne fuldføre forbindelsen med det samme og ville vente, men SAP's netværkslag (NI) opgav efter en intern timeout (f.eks. 5000 ms).

Operating System Call Writev Failed

Denne fejl opstår, når SAP forsøger at skrive data til en netværksforbindelse, der allerede er etableret, men handlingen mislykkes. 'writev' er et specifikt systemkald, der kan skrive data fra flere hukommelsesbuffere i et enkelt kald.

Et eksempel fra systemloggen kunne være:

Q0 I writev 32 NiIWritwritev nixxi.cp3803

Her er det vigtigste tallet '32'. Dette er fejlkoden fra operativsystemet. På UNIX-baserede systemer som AIX og Linux svarer fejlkode 32 til 'EPIPE', som betyder 'Broken pipe'.

En 'Broken pipe'-fejl opstår, når man forsøger at skrive til en forbindelse, hvor den anden ende allerede har lukket sin side af forbindelsen. Forestil dig, at du taler i telefon, og den anden person lægger på. Hvis du fortsætter med at tale, taler du ind i et 'dødt rør'. Det er præcis, hvad der sker her. Processen på den anden side (modtageren) har af en eller anden grund afsluttet, men afsenderprocessen i SAP har ikke opdaget det endnu og forsøger at sende mere data.

Mulige årsager til EPIPE / 'writev failed':

• Timeout på modtagersiden: En bruger har en GUI-session åben, men netværksforbindelsen bliver afbrudt. Når SAP-serveren senere forsøger at sende en skærmopdatering, fejler det, fordi forbindelsen er væk.
• Crash i den eksterne proces: Den service, som SAP kommunikerer med, er crashet.
• Netværksudstyr: En firewall eller en load balancer mellem SAP-serveren og modtageren kan have en inaktivitetstimeout og lukker forbindelsen, hvis der ikke har været trafik i et stykke tid.

Diagnostiske Værktøjer og Fejlfindingsmetoder

At løse disse fejl kræver en systematisk tilgang. Her er de værktøjer og trin, du bør følge.

1. Start i SM21: Systemloggen er dit første stop. Noter tidspunktet, applikationsserveren, proces-typen (DIA, BTC, etc.) og den fulde fejlmeddelelse, inklusive fejlnummer.
2. Gå til Developer Traces: Baseret på informationen fra SM21, skal du finde den relevante logfil.
   • For RFC-fejl: Gå til Gateway-monitoren (SMGW) og find logfilen dev_rd.
   • For HTTP(S)-fejl: Gå til ICM-monitoren (SMICM) og find logfilen dev_icm.
   • For andre fejl: Find den tilsvarende work process trace (dev_w*) i arbejdskataloget på den pågældende applikationsserver (findes via ST11).

   Disse logfiler vil afsløre den afgørende information: IP-adressen/værtsnavnet og portnummeret på det system, SAP forsøgte at kontakte.

3. Udfør grundlæggende netværkstest: Log ind på operativsystemet på den SAP-applikationsserver, hvor fejlen opstod. Brug standardværktøjer til at teste forbindelsen til målet, du fandt i logfilerne.
   • ping <målværtsnavn>: Bekræfter, at der er en grundlæggende netværksrute til værten.
   • telnet <målværtsnavn> <port> (eller lignende værktøjer som nc eller Test-NetConnection i PowerShell): Dette er den vigtigste test. Den viser, om du kan etablere en TCP-forbindelse på den specifikke port. Hvis den fejler med 'Connection refused' eller 'timeout', har du bekræftet problemet uden for SAP.
4. Undersøg Konfigurationen: Nu hvor du ved, hvilket system der ikke kan nås, skal du finde ud af, hvorfor SAP forsøger at kontakte det. Gennemgå konfigurationen i SAP:
   • RFC Destinationer (SM59): Den mest almindelige kilde. Søg efter destinationer, der peger på den problematiske vært.
   • ICM / Web Dispatcher Profilparametre: Tjek for parametre, der definerer forbindelser til back-end systemer eller message servere.
   • Tilpasning (SPRO): Nogle applikationsspecifikke konfigurationer kan indeholde eksterne serveradresser.

   Ofte stammer problemet fra en gammel konfiguration, der peger på en server, som er blevet nedlagt, men aldrig fjernet fra SAP's opsætning.

Sammenligning af Fejltyper

Ofte Stillede Spørgsmål (FAQ)

Er 'Operating system call failed' en kritisk fejl?

Det afhænger af konteksten. Hvis det sker tusindvis af gange i timen, indikerer det et alvorligt, vedvarende problem, som kan påvirke systemets ydeevne eller forårsage fejl i forretningsprocesser. Et enkeltstående tilfælde kan være et midlertidigt netværksudsving ('hiccup'), som ikke kræver handling. Hyppigheden og mønsteret er nøglen.

Hvorfor ser jeg fejlen for forskellige brugere og processer?

Fordi problemet ligger på et lavere niveau end den specifikke applikationslogik. Det er en system- eller netværksfejl. Enhver bruger eller proces, der tilfældigvis udløser den kode, som forsøger at bruge den fejlbehæftede forbindelse, vil generere en fejl i systemloggen. Fejlen er knyttet til ressourcen (den eksterne forbindelse), ikke brugeren.

Fejlnummeret er forskelligt på Windows og AIX/Linux. Hvorfor?

Fordi fejlkoden kommer direkte fra operativsystemets netværksimplementering. Windows bruger Windows Sockets (WSA) API, som har sit eget sæt af fejlkoder (f.eks. WSAECONNREFUSED), mens UNIX-lignende systemer følger POSIX-standarden med koder som ECONNREFUSED. Selvom tallene er forskellige, repræsenterer de ofte den samme underliggende netværksfejl.

Ved at følge en struktureret tilgang og bruge de rigtige værktøjer kan 'Operating system call failed'-fejl afmystificeres og løses effektivt. Nøglen er at huske, at SAP blot rapporterer et problem – det reelle detektivarbejde ligger i at bruge logfilerne til at identificere målet og derefter bruge standard netværksværktøjer til at isolere og rette rodårsagen, hvad enten det er en firewall, en nedlagt service eller en forældet konfiguration.