test

Solaris PC NetLink Administrationshandbok

Felsökningsmetoder

Felsökning av SunLink Server innebär att man systematiskt isolerar problemet och sedan samlar in detaljerade data för att identifiera vilken modul som orsakade problemet. Följande avsnitt innehåller enkla metoder som du kan använda för att isolera ett serverproblem. Det finns även några förslag till hur du kan få fram ytterligare information om problemet.

Isolera problemet

SunLink Server körs på en Solaris-dator. Servern behöver ett fullt fungerande NetBIOS-nätverk för att dess fil- och skrivarfunktioner skall fungera.

I ett NetBIOS-nätverk ingår oftast följande komponenter: ett program som tillhandahåller ett NetBIOS-gränssnitt; ett program som tillhandahåller ett gränssnitt till ett transportprotokoll för nätverket, som t.ex. TCP/IP (även om vissa transportlösningar även innehåller NetBIOS), och ett program som tillhandahåller drivrutiner till nätverksgränssnittet (även detta program kan ingå i transportmodulen).

Alla komponenter i NetBIOS-nätverket måste ha konfigurerats och vara i funktion för att SunLink Server skall kunna fungera i en nätverksmiljö. Dessutom måste liknande moduler fungera på den dator som försöker använda SunLink Servers fil- och skrivartjänster, som t.ex. en dator med Windows NT Workstation eller Microsoft Windows.

När inget NetBIOS-nätverk är tillgängligt visar systemet oftast följande meddelande när servern startas:


kunde inte publicera servernamnet på något nätverk

Om du granskar alla moduler som är inblandade i en direktanslutning mellan en klient och SunLink Server ser du lätt att för att ett problem i en klient-server-nätverksmiljö skall kunna lösas måste det först isoleras.

Innan du förutsätter att det är fråga om ett serverproblem måste du kontrollera att all annan nätverksprogramvara fungerar korrekt. Detta gäller särskilt när det av någon anledning (t. ex. nyinstallation) är stor risk att felet ligger i nätverkets transportsystem eller de fysiska nätverksanslutningarna.

Det är ingen idé att göra en grundlig kontroll av alla programvarulager om problemet bara gäller en viss klient eller användare. Med tiden kommer du att lära dig när du måste gå mer förutsättningslöst till väga när du skall isolera problemorsaken, och när du bara behöver kontrollera servern. I följande avsnitt får du allmänna rekommendationer för båda. Använd det förslag som bäst verkar passa ditt specifika problem.

Kontrollera nätverket

Innan du förutsätter att servern är orsak till alla nätverksproblem är det en klar fördel om du har kontrollerat att hela nätverket verkar fungera. Detta är extra viktigt om samtliga serveranvändare (eller en mycket stor del av dem) får problem samtidigt.

Använd nedanstående steg för att kontrollera nätverket.

Steg 1: Ta reda på nätverkets fysiska status

Det du först bör kontrollera är nätverkets olika fysiska komponenter. De allra flesta maskinvarukomponenter för nätverk idag har statusindikatorer som du kan använda för att kontrollera status för de olika nätverkskopplingarna (t.ex. har 10-BASE-T-nav lysdioder). Kontrollera alltid kopplingarna med avseende på tecken på problem med det fysiska nätverket (onormalt många omöverföringar, problem med korrekt överföring av data över kopplingen och tillstånd där det som tas emot är ren smörja).

Även om bara en klient är påverkad kan det vara fråga om kabelfel. För en enstaka klient är det enkelt att kontrollera om den får samma problem oavsett vilken server som den försöker ansluta till.

Om klienten inte kan "se" någonting på ett nätverk som för övrigt fungerar korrekt, kan du på goda grunder förutsätta att problemet ligger i klientens nätverkskonfiguration. Skulle emellertid samma klient kunna se andra noder på nätverket, men inte ansluta till en viss server, är det antagligen nätverkssökvägen till servern, själva servern eller det konto klienten använder som orsakar problemet.

Det finns flera tredjepartsprodukter för att kontrollera de fysiska nätverksanslutningarna. Det är bra att regelbundet övervaka nätverkstrafiken med någon sådan enhet för att se om det är några problem med det fysiska nätverket.

Steg 2: Ta reda på transportprotokollets status

Om det fysiska nätverket verkar fungera korrekt är nästa steg att ta reda på om de olika datorerna på nätverket kan "se" varandra ur transportprotokollets perspektiv. De flesta transportprotokollsprogram innehåller ett verktyg för anslutningstest som kan användas för att kontrollera att det går att upprätta en anslutning på transportnivå mellan en klient och en server på nätverket.

Om du inte kan nå en viss server från en viss klient med kommandot ping kommer klientdatorn inte heller att kunna ansluta till servern. Om det inte går att nå en server med ping från flera klientdatorer kan orsaken vara att servern eller transportprotokollet inte är igång, eller att ett konfigurationsproblem gör det omöjligt att ansluta.

Titta på rekommendationerna i dokumentationen för transportprotokollet. I förekommande fall fortsätter du med de metoder som beskrivs senare i det här avsnittet för att ta reda på status för NetBIOS-protokollet och SunLink Server.

Steg 3: Ta reda på NetBIOS-protokollets status

Kontrollera NetBIOS-protokollagret. För de flesta NetBIOS-moduler finns testverktyg som kontrollerar att det går att upprätta anslutningar mellan NetBIOS-namn via nätverket.

Det kan vara möjligt att ansluta mellan TCP/IP-noder, men om det inte går att ansluta mellan NetBIOS-namn kommer inte SunLink Server att fungera. Alla förbindelser i SunLink Server är baserade på NetBIOS-namnsessioner. Använd testverktygen du fick med protokollprogrammet för att kontrollera om det går att ansluta på NetBIOS-nivå. Om du upptäcker något problem skall du isolera det i enlighet med den information du fick i dokumentationen för NetBIOS-protokollet.

Steg 4: Kontrollera funktionen hos Solaris

Om alla moduler som sköter anslutningarna inom nätverket fungerar normalt är nästa steg att kontrollera Solaris på värddatorn för SunLink Server. I operativsystemet finns ett stort antal loggfiler och systemkontroller som kan utföras för att bekräfta normal funktion. Dokumentationen för Solaris ger mer information om dessa kontroller.

SunLink Server-programmet är speciellt känsligt för följande systemproblem:

Problem med operativsystemet kommer i allmänhet att påverka samtliga eller flertalet klientdatorer som är anslutna till servern. Lägg inte ned för mycket tid på det här steget om du felsöker ett problem som rör en enskild klient.

Steg 5: Isolera problem på SunLink Server

Om du kan få fram att all underliggande programvara fungerar normalt måste du undersöka SunLink Server. Hur man isolerar problem på servern är ofta beroende av vilken typ av problem som rapporteras av användarna.

Om det bara är en enstaka användare som har problem kan du snabbt rikta in dig på vilka åtgärder den här användaren försöker utföra.

Om en grupp användare har problem, men många andra inte har det, skall du hålla utkik efter någon gemensam nämnare för användarna med problem. Exempel:

Om samtliga användare på en server har problem, skall du börja med att kontrollera serverns tillstånd på en mer grundläggande nivå. Detta beskrivs i följande avsnitt.

Är servern igång?

Det kan löna sig med en kontroll att servern verkligen är igång. Du kan lätt göra det genom att skriva in följande kommando på systemkommandoraden:

ps -ef | grep lmx

Skärmen bör visa (åtminstone) följande:

root 3554 3452 Feb28 19:39 lmx.srv -s 1

root 3452 1 0 Feb28 5:03 lmx.ctrl

root 3568 1 0 Feb28 2:16 lmx.dmn

Här visas att de tre erfoderliga serverprocesserna faktiskt är igång: bakgrundsprogrammet (lmx.dmn), styrprocessen (lmx.ctrl) och minst en arbetsprocess (lmx.srv). Eventuellt ser du även andra processer, som lmx.browser och lmx.alerter.

I vissa fall visas ytterligare arbetsprocesser, var och en med ett unikt nummer angivet vid slutet av raden. Servern sätter igång nya arbetsprocesser baserat på det antal klienter som stöds av servern. Allt eftersom fler klientsessioner startas kan fler lmx.srv-processer startas, var och en med en unik process-ID och ett unikt process-ID-nummer. Detta är normalt.

Om servern inte är igång använder du kommandot net start server vid kommandoraden.

Är samtliga servertjänster igång?

Om någon av de erforderliga serverprocesserna inte är igång skall du ta reda på om samtliga servertjänster är startade på rätt sätt. En situation kan uppstå när flera serverprocesser är igång men servern ändå inte kan användas p.g.a. att en viss tjänst inte startade. Detta gäller i synnerhet tjänsten Net Logon. Skriv in följande kommando på kommandoraden för att kontrollera vilka tjänster som är igång:

net start

Systemet visar en lista med de tjänster som för tillfället är aktiva på servern.

Det är ytterst viktigt att tjänsterna Net Logon och Server finns med. I annat fall har servern problem. Om Net Logon-tjänsten inte startar beror det ofta på ett problem med servernamn, domännamn eller domänkonfiguration.

Kontrollera om det finns något i felloggarna som kan förklara problemet (se nästa avsnitt).

Finns det meddelanden i felloggarna?

Gör alltid en kontroll av de felloggar servern använt. Med SunLink Server Manager i SunLink Server kan du visa system-, säkerhets- och programloggarna från en klientdator med hjälp av Loggboken. Vid systemkonsolen använder du kommandot elfread. Du kan även visa loggarna i PRINTLOG-delningsområdet om problemet rör utskrift. Skulle problemet ha att göra med starten av servern kan du kontrollera lmxstart.log som ligger i katalogen /var/opt/lanman/logs.

Om det finns poster i någon av loggarna sparar du dem så att du kan titta på dem igen. Ta aldrig bort eller skriv över felmeddelanden eftersom de kan ge en antydan om orsaken till problemet. Eventuellt kommer personalen på tekniskt kundstöd att behöva loggarna senare.

Följande meddelande har speciellt stor betydelse för att antyda orsaken till ett serverproblem:


A server process has unexpectedly terminated

Meddelandet visar att en serverprocess stötte på ett oväntat fel. Beroende på hur servern är konfigurerad kan det finnas en core-fil på systemet.

Om värdet för nyckelordet CoreOk är 1 (ja) i SunLink Servers Register, finns det en core-fil någonstans på systemet. Värdet på CoreOk finns i följande nyckel:

SYSTEM\CurrentControlSet\Services\ AdvancedServer\ProcessParameters

Gå till rotkatalogen och kör följande kommando för att söka igenom filsystemet efter core-filer:

find . -name "core*" -print

Spara de filer du eventuellt hittar. Om parametern coreok är nej, skapas det inte några core-filer. Eventuellt vill du sätta nyckelordet CoreOk till ja för att skapa core-filer, vilka är bra att ha vid felsökning.

Delas samtliga serverresurser på rätt sätt?

Vissa serverresurser delas automatiskt varje gång servern startas. De används i bakgrunden av klienterna samtidigt som andra aktiviteter utförs.

Delade resurser är:

ADMIN$

C$

D$

IPC$

LIB

NETLOGON

PRINTLOG

PRINT$

USERS

Att ett dollartecken ($) står efter en resurs anger att det är en speciell resurs som krävs för serveradministration och -kommunikation. (Det finns ytterligare en speciell resurs -- REPL$ -- när tjänsten Directory replicator är igång.)

Försök aldrig ta bort eller göra en ny delning av någon av dessa resurser. Om någon av dem saknas kommer inte servern att fungera på rätt sätt. Skulle du upptäcka att någon resurs inte finns skall du stanna och starta om servern för att ta reda på om resursen delas när servern startas. Om den inte visas kontaktar du en servicerepresentant.

Återstående resurser är standardresurser som i typfallet används av klienter under inloggning (NETLOGON), för att ansluta till hemkataloger (USERS) och för att komma åt verktyg eller felloggar (DOSUTIL, OS2UTIL, PRINTLOG). Det kan hända att dessa med avsikt saknas på servern. Men om det skulle vara så att det inte var du själv som gjorde att de slutade delas måste de ha tagits bort till följd av ett problem med servern.

Kan man komma i kontakt med servern från konsolen?

Man kan göra ett enkelt test för att ta reda på om servern kommunicerar via nätverket. Skriv följande kommando vid systemkonsolen.

net view

Systemet visar namnet på servern och andra servrar på samma domän. Om namnet på din server inte visas kör du samma kommando och lägger till servernamnet:

net view \\asutrial

Systemet visar en lista med delade resurser som ser ut ungefär så här:

Shared resources at \\asutrial

SunLink Server Systems

Sharename Type Used as Comment

----------------------------------------------------------------

DOSUTIL Disk DOS Utilities

LIB Disk Programming Aids

NETLOGON Disk Logon Scripts Directory

OS2UTIL Disk OS/2 Utilities

PRINTLOG Disk LP Printer Messages

USERS Disk User Directory

Andra poster kan visas om du själv delat ytterligare resurser på servern.

Om något av dessa kommandon misslyckas genomgående föreligger det ett problem med utsändningskommunikationen över nätverket. Om kommandona lyckas kan du använda testerna i nästa avsnitt.

Stöder servern maximalt antal användare?

När det uppstår ett problem som rör anslutningarna skall du kontrollera att servern inte överskridit det maximala antal klienter den är konfigurerad att stödja. Detta antal finns angivet i parametern maxclients i filen lanman.ini på servern. Det kan visas med hjälp av kommandot srvconfig - g maxclients.

Är Registret i SunLink Server skadat?

Kör kommandot regcheck -C för att ta reda på om det interna formatet hos registerfilen är skadat. Om kommandot skulle upptäcka att så är fallet kör du kommandot regcheck -R för att reparera registerfilen.

Om ogiltiga värden har matats in i SunLink Server-Registret, kan du använda kommandot regload för att återställa samtliga registervärden till sina standardvärden.

Kan man komma i kontakt med servern från en klient?

Försök att logga in på servern från en klientdator. Om inloggningen lyckas skall du en enhet till en delad resurs. Därefter kan du visa innehållet i den kopplade enheten.

Om det blir några problem med de här stegen kan du isolera vart och ett av problemen på följande sätt.

Felsökning av en delad resurs

Om det går att kommunicera med servern men inte komma åt en delad resurs kontrollerar du följande:

  1. Kontrollera att den delade resursen finns genom att använda kommandot net view \\servernamn. Om namnet på den delade resursen inte visas, finns den inte. I detta fall måste den delas på nytt.

  2. Gör en koppling till den delade resursen när du är inloggad som administratör. Om detta inte går och resursen existerar kan den ha delats på ett felaktigt sätt. Ta bort resursen och gör en ny delning av den. Om detta lyckas går du vidare med nästa steg.

  3. Om resursen är en skivresurs kontrollerar du de båda tillståndsnivåer som gäller för den delade resursen. Kontrollera först delningstillstånden med Serverhanteraren. Därefter gör du en kontroll av tillstånden på den delade katalogen med hjälp av Utforskaren i Windows från en klient som är inloggad för administration.

    Kontrollera att resursen kan användas med hjälp av antingen gruppmedlemskap eller egna användarrättigheter. Kontrollera även att åtkomsttillstånden för resursen tillåter att den önskade åtgärden utförs (det kan t. ex. hända att en användare som endast har tillstånd att läsa en fil försöker redigera den). Kontrollera också att antalet användare inte överskrids för en viss delad resurs.

  4. Kontrollera filattribut och åtkomsttillstånd i Solaris för den delade resursen.