Prozeßkonzept
- Prozesse - Nutzersicht
-
- Konzeptionelles
-
- Neben den Files sind die Prozesse zweites wesentliches Systemkonzept
- Prozeß
-
- jede Rechenaktivität in UNIX vollzieht sich als Prozeß
- Ausführung eines Programms, Programm im Zustand seiner Ausführung
- muß Systemressourcen (Speicher, CPU) zugeteilt erhalten
- Beziehung: UNIX-Kommando - File - Prozeß
-
- Ausführbare Programme werden in Files gespeichert, soll ein solches File ausgeführt werden, so wird es geladen
--> Kopie des ausführbaren Programms im Hauptspeicher, die als Prozeß 'lebt'- wird ein und dasselbe ausführbare File gleichzeitig mehrfach gestartet, entstehen mehrere Prozesse.
- UNIX-Kommandos sind ausführbare Programme (die Files stehen im Verzeichnis /bin, /usr/bin , ...) --> Ausführung vollzieht sich als Prozeß
- auch die Shell ist ein Programm (Prozeß) - ohne besondere Privilegien
- nur wenige UNIX-Kommandos werden direkt von der Shell ausgeführt (z.B. cd) --> kein eigener Prozeß
- der den Prozeß startende Nutzer wird als Prozeßeigentümer geführt (siehe File-Zugriffsrechte)
- Prozesse durch eine Prozeß-ID (Dezimalzahl) identifiziert
- Ein Prozeß besteht aus drei Adreßräumen:
-
- Textsegment
enthält den Programmcode
(mehrfache Ausführungen desselben Files können sich diesen Adreßraum teilen --> shared)- Datensegment
enthält die Daten eines Programms- Stacksegment
enthält den Programm-Stack (Funktionsrufsequenzen, automatische Variable, Funktionsparameter)
- Prozesse sind eine Verwaltungseinheit des UNIX-Systems
(UNIX unterstützt Multi-Prozeßverarbeitung, d.h. mehrere Nutzer und Programme können "gleichzeitig" vom System bedient werden --> Systemressourcen müssen zwischen allen sich bewerbenden Prozessen verteilt werden (Zeitscheiben im Millisekundenbereich))- Verwaltungsinformationen sind u.a.:
-
- Prozeßnummer (pid)
- Benutzernummer (uid)
- akkumulierte Rechenzeit, augenblickliche Priorität
- Speicherbelegung
- Instruktion Pointer
- Priorität und nice-Wert
- zwischen Prozessen bestehen Eltern/Kindbeziehungen
- Prozesse werden erzeugt, indem ein Prozeß (Eltern-) einen bestimmten Systemdienst (fork) anfordert, in dessen Ergebnis ein neuer Prozeß (Kind-) entsteht (der Nutzer bemerkt diesen Vorgang nicht!, alle Kommandos, die man ausführt, sind Kindprozesse des Kommandointerpreters - der Kommandointerpreter ist selbst ein Prozeß)
- Normalerweise arbeitet der Kommandointerpreter so, daß er bei Aufruf eines Kommandos wartet, bis das Kommando abgearbeitet ist, danach zeigt er mit der Ausgabe des Prompts seine Bereitschaft neue Kommandos entgegenzunehmen. Man sagt dann, daß das Kommando (genauer der Prozeß, der das entsprechende Programm ausführt) im Vordergrund läuft. Gibt man als letztes Zeichen in der Kommandozeile das Zeichen & an, so wird das Kommando in den Hintergrund geschickt. D.h. der Kommandointerpreter wartet nicht auf das Ende der Abarbeitung des Prozesses, sondern gibt die Prozeß-ID des gestarteten Prozesses aus und zeigt danach mit der Ausgabe des Prompts seine Bereitschaft zur Entgegennahme weiterer Kommandos an. Diese Arbeitsweise ist vor allem bei Prozessen mit langer Laufzeit sinnvoll.
- jeder Prozeß gehört zu einer Prozeßgruppe, der Prozeß innerhalb einer Prozeßgruppe, der von allen anderen Prozessen dieser Gruppe der Elternprozeß ist, heißt Prozeßgruppenführer
- Prozeß-Scheduling: Zuordnung von CPU-Ressource entsprechend eines Scheduling-Algorithmus' (eingehende Parameter: verbrauchte CPU-Zeit, nice-Wert, ...)
- threads möglich; thread ist ein "Leichtgewichtsprozeß" (mehrere parallel ablaufende Aktivitäten innerhalb des Adreßraums eines einzelnen Prozesses)
- extra CPU-Scheduling innerhalb eines solchen Prozesses --> hauptsächlich angewendet für Server-Prozesse (wegen meherer unabhängiger Klienten-requests)
- Kommando ps
-
- ps [optionen]
- Anzeigen des Status aktiver Prozesse
- Anzeigen aller Prozesse oder eines "Teilbaumes" der Prozeßhierarchie
- nur für Signale von Interesse
- ohne Optionen zeigt ps Informationen über Prozesse an, die mit dem aktuellen Terminal verbunden sind (jeder Prozeß ist mit einem Terminal verbunden, Kommandos haben das Terminal von dem sie aufgerufen wurden als aktuelles Terminal, erzeugen diese Kommandos selbst wiederum Prozesse, dann erben diese Prozesse das aktuelle Terminal)
- die Ausgabe erfolgt in Tabellenform
-
PID TTY TIME COMMAND 4868 ttyia 0:02 csh 4912 ttyia 0:00 ps>PID Prozeß-ID TTY Terminalidentifikation TIME kumulative CPU-Zeit COMMAND Kommandoname
- weitere Informationen können über Optionen angefordert werden
- es existieren verschiedene Varianten von ps, die u.a. bzgl. der Optionen voneinander abweichen (System V <--> BSD <--> Linux)
- Optionen von ps gem. System V:
-
- -f
- vollständige Tabelle erzeugen, zusätzlich zu den oben genannten Informationen werden angezeigt:
-
UID Nutzer-ID des Prozeßeigentümers PPID Prozeß-ID des Elternprozesses C Prozessorauslastung für Scheduling STIME Startzeit des Prozesses
- anstelle des Kommandonamens versucht ps -f die Kommandozeile in der Form anzuzeigen, wie sie eingegeben wurde
- -l
- lange Tabelle erzeugen, zusätzlich zu den Standard-Informationen werden angezeigt:
-
F Flags (z.B. augelagert; Systemprozeß;Trace,...) S Status (z.B. schlafend; wartend; in Bearbeitung...) UID, PPID, C wie Option -f PRI Priorität; hohe Zahl entspricht geringer Priorität NI NICE-Wert (für Priorität) ADDR Speicheradresse / Segmentnummer SZ Size in Blöcken WCHA Ereignis, auf das der Prozeß wartet oder schläft
- Zu beachten ist, daß diese beiden Optionen lediglich bestimmen, welche Informationen zu einem Prozeß angezeigt werden, aber nicht festlegen, für welche Prozesse das erfolgen soll!
- -e
- Informationen zu allen Prozessen
- -d
- Informationen zu allen Prozessen, außer Prozeßgruppenführer
- -a
- Informationen zu allen Prozessen, außer Prozeßgruppenführer und Prozessen, die mit keinem Terminal verbunden sind
- -ttermlist
- Informationen über Prozesse anzeigen, die mit den in termlist angegebenen Terminals verbunden sind
- -uuidlist
- Informationen über Prozesse anzeigen, deren Prozeßeigentümer in uidlist eingetragen ist
- Optionen von ps gem. BSD:
-
Ohne Optionen werden alle Prozesse angezeigt, die mit der effektive UID des Nutzer laufen und die mit einem Terminal verbunden sind. Es werden folgende Informationen ausgegeben: PID, TTY, STATUS, TIME und COMMAND (mit Argumenten)
-u nutzerbezogenes Listenformat (USER, PID, CPU...) -l Langes Listenformat (PPID, PRI, NI, SZ ...) (analog System V) -s zusätzlich zum Kommando wird die Umgebung angezeigt, mit der der Prozeß gestartet wurde -x Prozesse, die mit keinem Terminal verbunden sind, werden ebenfalls angezeigt -a Prozesse, die anderen Nutzern gehören, werden ebenfalls angezeigt -tx nur Prozesse anzeigen, die mit Terminal x verbunden sind (t3 für /dev/tty3; tco für /dev/console...)
- Optionen von ps gem. Linux:
Grund: Zur Unterscheidung von anderen Implementationen, da ps sehr hardware-nah!
- Optionen von ps gem. Linux:
- Signale
-
- informieren Prozesse über asynchron eintretende Ereignisse
- Möglichkeit der Interprozeßkommunikation
- Signale sollten beachtet werden
-
Möglichkeiten der Signalbehandlung:- Ignorieren eines Signals
- Blockieren eines Signals (suspend)
- Behandlung des Signals --> signal(2)
-
- voreingestellte Standardbehandlung (meist Abbruch)
- ignorieren
- "eigene" Signalbehandlungsroutine aktivieren
- werden u.a. ausgelöst durch:
-
- den Benutzer am Terminal (<CTRL C> --> Abbruch, <CTRL D> --> EOF, Abschalten des Terminals, Verlassen eines Bildschirmfensters in Mehrfensterumgebung, ...)
- durch einen Programmfehler (Überlauf, ungültige Instruktion, Speicherschutzverletzung, ...)
- durch den Systemruf bzw. das Kommando kill
- einige Signale
-
Signalnummer symb. Name Beschreibung Standardreaktion 1 SIGHUP Sitzungsende Abbruch 2 SIGINT Interrupt-Signal <CTRL C> Abbruch 3 SIGQUIT QUIT Abbruch 4 SIGILL illegale Instruktion Abbruch 8 SIGFPE floating point exception Abbruch 10 SIGBUS Bus error Abbruch 18 SIGCLD death of a child (Prozeßende) - Wo sind die Signale aufgelistet?
gehören unter Linux zum kernel-Umfeld, also in /usr/src/linux/include/...
siehe Kommando: man 7 signal
in kommerziellen UNIX-Systemen meist in /usr/include/signal.h (bzw. dort ein #include ...)
- Kommando kill
-
- kill [-signal] pid ...
- sendet ein Signal signal an den Prozeß pid
- Signale teilen einem Prozeß mit, daß ein bestimmtes Ereignis eingetreten ist. Es gibt ca. 20 verschiedene Signale, auf die ein Prozeß reagieren kann. Der Programmierer kann für jedes Signal eine bestimmte Reaktion festlegen. Eine häufige Anwendung von Signalen ist, sie zum Abbrechen von laufenden Prozessen einzusetzen.
- Gibt man keine Signalnummer signal an, so wird das Signal 15 (SIGTERM) gesendet. Dieses Signal führt standardmäßig zum Abbruch des Prozesses. Allerdings kann ein Programmierer auch dafür sorgen, daß dieses Signal abgefangen oder ignoriert wird.
Das Signal 9 (SIGKILL) führt unweigerlich zum Abbruch eines Prozesses, da es keine Möglichkeit gibt, dieses Signal abzufangen oder zu ignorieren.- Die Prozeßnummern pid erfährt man durch ps oder durch die Antwort des Kommandointerpreters auf &.
- Gibt man für pid den Wert 0 an, so wird das Signal an alle Prozesse der Prozeßgruppe gesendet.
- Jeder Nutzer darf nur an die Prozesse Signale senden, deren Eigentümer er ist.
- Aufgabe:
-
C-Programm mit Endloszyklus
main();for(;;);
%1cc -o zyklus zyklus.c
%2zyklus &
... pid
%3ps
...
...
%4kill pid%5kill pid
pid eines anderen Nutzers
Prozesse empfangen nur Signale, die der Prozeß-Eigentümer oder ein privilegierter Nutzer sendet - beim Abmelden bzw. Auschalten des Terminals sendet die Shell an alle Prozesse der Prozesßgruppe das Signal SIGHUP, was zum Abbrechen der entsprechende Prozesse führen würde (standardmäßig wird von den meisten Shells nohup angenommen --> Hintergrundprozesse ignorieren dieses Signal).
- STOP-Signal (siehe Pkt. Shell --> job-control)
- Prozesse - Interna
-
- Prozeßtypen
-
Interaktive Prozesse- initiiert und gesteuert durch eine Terminalsitzung
- laufen im Vordergrund (fg) oder Hintergrund (bg)
- fg-Prozesse sind an das Terminal gebunden (attached); das Terminal kommuniziert mit einem fg-Prozeß direkt
- z. B.: $ ls
- job-Control (tcsh, bash, ...)
- JC wird später erläutert
- nicht mit einem Terminal verbunden
- Serverprozesse, die untätig im bg warten, bis irgendein Ereignis diesen Serverprozeß aktiviert
- gewöhnlich beim Booten gestartet oder über einen sog. Super-Dämon (inetd) (siehe Grundlagen Netzdienste)
- Prozeßeigenschaften
-
ProzeßeigenschaftenPID die Prozeß ID ist eine eindeutige Nummer, um sich auf den Prozeß zu beziehen PPID PID des Parent Prozesses Nice Nummer zeigt die Prozeßpriorität relativ zu den anderen Prozessen an; das ist nicht die aktuelle Execution-Priorität des Prozesses, die sich dynamisch ändert abhängig von der Nice Nummer und dem Ressourcenverbrauch TTY Terminal-Gerät (Pseudoterminal), das mit dem Prozeß verknüpft ist RUID, EUID Die reale UID ist die UID des Nutzers, der den Prozeß gestartet hat. Die effektive UID wird benutzt, um die Zugriffsrechte des Prozesses auf Files zu bestimmen. Gewöhnlich sind RUID und EUID gleich. Wenn jedoch SUID für ein ausführbares File gesetzt ist, so wird EUID des ausführenden Prozesses entsprechend der UID des Fileeigentümers gesetzt und dementsprechend sind die Zugriffsrechte. RGID, EGID Die reale GID ist die primäre oder aktuelle Gruppe des betreffenden Nutzers. Die effektive GID wird benutzt, um die Zugriffsrechte des Prozesses auf Files zu bestimmen. Gewöhnlich sind RGID und EGID gleich. Wenn jedoch SGID für ein ausführbares File gesetzt ist, so wird EGID des ausführenden Prozesses entsprechend der GID des Fileeigentümers gesetzt und dementsprechend sind die Zugriffsrechte.
- Lebenszyklus eines Prozesses
-
Die Erzeugung eines neuen Prozesses geschieht folgendermaßen:
- ein existierender Prozeß erzeugt eine exakte Kopie von sich selbst (fork)
- der neue (Kind-Prozeß besitzt die gleiche Umgebung (environment) wie der Eltern-Prozeß
- das Speicherabbild des Kindprozesses kann mittels exec durch das gewünschte Speicherabbild überschrieben werden
- die Umgebung des Elternprozesses bleibt erhalten (Wert der environment-Variablen, Zuordnungen stdin, stdout, stderr, die execution-Priorität usw.)
- Ursprungsprozeß für jeden Prozeß ist init (PID 1), der (auf besondere Weise) beim Hochfahren erzeugt wird
- zu den von init erzeugten Prozessen gehören auch solche, die das Programm getty ausführen
( init(8) --> /etc/inittab )- getty führt exec von login durch, was u. a. das Anmelden der Nutzer überprüft (Nutzername, Password)
- geht die Anmeldung schief, so aktiviert login exit, welches ein Signal an seinen Elternprozeß sendet, damit für das betreffende Terminal erneut getty erzeugt werden kann
- login führt exec für die Login-Shell durch, (es handelt sich dabei noch immer um den gleichen Prozeß wie getty)
- nach diesem Muster (fork-exec) werden neue Prozesse erzeugt, um die vom Nutzer eingegebenen Kommandos auszuführen
- wenn ein Nutzer die Sitzung beendet (Abmelden), so sendet die Login-Shell ein Signal an ihren Elternprozeß (init und führt exit durch; init führt exec für getty durch usw.
- SetUserID, SetGroupID und Prozeßausführung
-
- die Filezugriffsrechte SUID und SGID ermöglichen gewöhnlichen Nutzern die Ausführung eines Prozesses mit den Rechten eines anderen Nutzers bzw. einer anderen Gruppe
- z.B. Kommando passwd (Passwort ändern)
Bei Ausführen von passwd wird EUID auf RUID des Eigentümers (root) gesetzt.
Somit ist es möglich, daß das in /etc/passwd stehende Paßwort geändert werden kann.- andere Beispiele sind uucp, Mailer, write-Kommando, chsh
- ,,SUID to root`` ist ein Sicherheitsrisiko !!!
- Interprozeßkommunikation
-
Prozesse müssen miteinander kommunizieren können, dies geschieht in UNIX mit IPC-Mechanismen (inter process communication)(verschiedene) IPC-Mechanismen:
- Files
Datenaustausch bzw. Synchronisation über Files
fehlende Synchronisation- Pipes
(siehe nachfolgenden Pkt. UNIX-Tools)
klassischer IPC-Mechanismus
zwei mittels Pipe kommunizierende Prozesse benötigen gemeinsamen Elternprozeß, der diese Pipe ("Röhre") einrichtet (i.allg. Shell)
existiert nur solange, wie die beiden kommunizierenden Prozesse existieren- Signale
(siehe Pkt.1 Unterpunkt: Signale in diesem Kapitel)
asynchrones Ereignis
vorwiegend zur Kommunikation zwischen System- und Nutzerprozessen- Named Pipes
"Gerätedatei"
explizit angelegt --> mknod(2), mknod(8)
zeitliche Existenz nicht begrenzt- Sockets
-
universeller IPC-Mechanismus
standardmäßig zwei Kommunikationsdomänen- UNIX-Domäne (lokaler UNIX-rechner)
srw------- 1 root root .... /dev/printer
srw-rw-rw- 1 root root ... /dev/log- Internet-Domäne
(siehe Pkt. Grundlagen Netzdienste)
zur Realisierung aller Internet-Dienste
- SystemV IPC
-
Semaphore, Message Queues, Shared Memory, Streams
- Semaphore: "Zustandsvariablen" zur Prozeß-Kommunikation
- Message Queues: Austausch von NAchrichten zwischen Prozessen
- Shared Memory: gemeinsame Nutzung von Hauptspeichersegmenten durch mehrere Prozesse
- Streams: Kommunikation von Prozessen innerhalb eines Rechnernetzes
- Prozesse - Praxis
-
- Multi-User-Betrieb
-
Die meisten Aktionen, die zur Initialisierung des Systems für den Multi-User-Betrieb notwendig sind, werden über sogenannte rc-Files realisiert, Shell-Prozeduren in /etc, die von init aufgerufen werden.
Im System V werden diese Scripte aus der Tabelle /etc/inittab aufgerufen, im BSD direct von init.inittab in Linux im Verzeichnis /etc/rc.d
System V Run-Level:
Im System V werden verschiedene Systemzustände unterschiede (Run-Level), die mit dem Kommando init einstellbar sind:
Run-Level Bezeichnung und Verwendung</ TD> 0 Powerdown state; nach shutdown zum Ausschalten des Rechners 1 Administrative state; Single user Mo dus s oder S Single-user mode; 2 Multi-user mode; normaler Systemstatus für Betrie b ohne spezielle Netzdienste (RFS) 3 Remote File Sharing (RFS) state; normaler Systemstatus im Netzbetrieb (auch für NFS) 4 User-definable system state; spä ;ter für spezielle Nutzeraufgaben 5 Firmware state; für spezielle W artungsaufgaben bzw. Booten von alternativen Platten 6 Shutdown and reboot state; zum sofor tigen Neu-Booten /etc/inittab:
- Beim automatischen Systemstart wird dabei der ``initdefault``-Level eingestellt; entweder Level 2 oder 3;
- nicht alle Run-Level sind in der Praxis vorhanden
- Run-Level 1 und s oder S sind häufig nicht zu unterscheiden
- Die folgenden Nachrichten erscheinen im Ergebnis der Abarbeitung der rc-Scripts auf der Konsole
- nach Abarbeitung aller rc-Files ist das UNIX-System
fertig initialisiert; jetzt können die Terminals zur Anmeldung bereit gemacht
werden.
Reihenfolge der beim Booten (shutdown) abzuarbeitenden Prozesse wird in Verzeichnissen rcN.d festgelegt, Files beginnen mit S (K), wobei N dem run-level entspricht (in Linux /etc/rc.d/rcN/...) - im System V werden jetzt diejenigen Zeilen der inittab abgearbeitet, die das Kommando /etc/getty aufrufen
- in BSD-Systemen schaut init in einem File /etc/ttys nach, für welche Terminals das Kommando getty zu starten ist
- von init wird für jede dieser Zeilen ein neuer Prozeß gestartet mit dem Kommando getty. Dieses schreibt auf jedem aktiviertem Terminal eine Login-Nachricht aus und wartet dann, bis sich ein Nutzer mit seinem Login-Namen meldet
- der genaue Ablauf des Aktivierens der Nutzersitzungen wird im Abschnitt Geräte unter Terminals behandelt
- Starten (Bootstrap)
-
- Der Boot-Prozeß ist in den meisten UNIX-Systemen sehr ähnlich; er besteht im wesentlichen aus 3 Schritten:
-
- nach Einschalten erfolgt Abarbeitung eines HW Boot-Programms (BOOT-ROM) sowie eines SW Boot-Programms
- Laden und ggf. Konfigurieren des UNIX-Systems (Kerninitialisierung)
- Starten des Systems sowie Initialisierung der Login-Prozesse für alle angeschlossenen Terminals (init-Programm)
- BOOT-ROM
-
- nach dem Einschalten des Rechners erfolgt zunächst eine Kontrolle wichtiger HW-Teile: Speicher, Controller usw.
- es besteht die Möglichkeit bei einigen Rechnern (PC), durch definierte Tastenkombinationen diesen Vorgang zu unterbrechen und ggf. sogar in ein Konfigurationsmenue zu verzweigen; ist wichtig nach Änderungen der HW-Konfiguration --> setup-Menü
- Auffinden des Bootdevices (Teil des Boot-ROM):
-
- i.a. ist eine Platte als Bootgerät definiert (durch System oder Konfigurierung festgelegt)
- häufig kann diese Standardannahme durch ein externes Gerät überschrieben werden: z.B. Diskettenlaufwerk A, wenn eine Diskette zur Zeit im Laufwerk ist (Problem: keine Boot-Diskette)
- von gefundenem Bootgerät wird ein Bootblock geladen (normalerweise von Sektor 0)
- Block 0 gehört nicht zum Filesystem, sein Einlesen ist ein technischer Vorgang (gilt auch für DOS); Blockgröße 1K bei BSD und System V, sonst 512B.
Ist Boot-Block zu erstellen, so gibt es folgende Möglichkeiten:
a) lilo
b) fdisk- dieser Bootblock lädt ein Boot-Programm aus dem UNIX-Filesystem (root)
- BOOT-Programm
-
- das Boot-Programm ist ein gewöhnliches UNIX-File (lilo)
- es arbeitet häufig interaktiv und dient allgemein zum Laden sogenannter Stand-Alone-Programme (z.B. auch zum Formatieren von Harddisks)
- wird nicht automatisch gebootet, so meldet sich das Boot-Programm mit einem boot-Prompt, häufig
- das Boot-Programm überprüft die Eingaben
- es liest den UNIX-Kern ein, der als gewöhnliches File im Wurzelfilesystem gespeichert ist.
(häufig als /unix oder /vmunix bzw. im Verzeichnis /boot)- nach erfolgreichem Laden erhält der Kern die Steuerung und erledigt alles weitere selbst.
- Kerninitialisierung
-
- Größe des Hauptspeichers ermitteln (löschen)
Methode: Adreßausnahme bei Zugriff- Überprüfung des Zugriffs auf generierte Geräte (evtl. Konfigurierung)
- Startausschriften auf Konsole:
- Eröffnen des Zugriffs auf Wurzelfilesystem (keine Konsistenzprüfung)
- Starten des 1. eigentlichen UNIX-Prozesses /etc/init bzw. /sbin/init (PID 1)
- init-Programm
-
- init steuert weitere Arbeit des Systems; arbeitet mit Super-User-Rechten !
- abhängig vom System werden von init folgende Aufgaben realisiert:
-
- Überprüfen der Integrität von Filesystemen
- Installieren weiterer Filesysteme (mount)
- Aktivieren von Page- oder Swap-Bereichen
- Bereinigung und Überprüfung bestimmter Verzeichnisse und Files:
-
- Löschen temporärer Files (/tmp)
- Löschen von lock-Files (z.B. für Spooler lpd)
- Retten von Editorfiles
- Prüfen von Disc Quotas
- Starten von Server Prozessen (daemons: printing, mail, accounting, cron)
- Starten von login-Prozessen, um Nutzern Anmeldung an Terminals zu erlauben
In der Praxis werden bei modernen Systemen mehrere rc-Files verwendet, um alle Aktionen zu starten; die meisten rc-Files sind an dem Kürzel rc zu erkennen (z.B. rc.local, netbsdrc, /etc/rc.d).
Sind alle diese Aufgaben erledigt, hat das System seinen ``normalen`` Zustand erreicht, man nennt ihn Multi-User-Modus
- Stoppen(shutdown)
-
Motivation:- man darf UNIX-Rechner NICHT einfach ausschalten
(im Gegensatz bspw. zum DOS)- Gründe sind Mehrnutzerbetrieb, Prozeßkonzept und Art des Zugriffes auf Filesysteme (asynchron)
- UNIX-Systeme laufen in der Regel durchgehend
- bei Stromabschaltung - hier evtl. unvorhergesehen (Kontrolle)
- bei Arbeiten an der Hardware (Durchsichten, neue Geräte)
- für bestimmte Administrationsaufgaben (Systemsicherung, Systemänderungen)
- bei undefinierten Systemverklemmungen
- bei kleinen, privaten Systemen regelmäßig
Wie erfolgt das Stoppen des Systems ?
- jedes UNIX-System verfügt mindestens über ein Kommando zum ``normalen`` Stoppen des Systems; in den meisten UNIX-Systemen heißt es shutdown
- shutdown ist häufig eine Prozedur, die folgende Aufgaben realisiert:
-
- Information aller Nutzer über das Stoppen des Systems (Zeit !)
- ggf. einen Moment warten, bis Nutzer sich abgemeldet haben
- Signal (SIGTERM) an alle Prozesse, ihre Arbeit zu beenden
- Abbruch aller Prozesse (SIGKILL), die Arbeit nicht selbst beenden
- Übergang in den Single User Modus
- Sichern der Filesystemintegrität (sync); alle Datenpuffer im HS leeren
- Anhalten des Prozessors oder Steuerung an Boot-ROM
- shutdown ist die sicherste Methode, ein UNIX-System zu stoppen, da es sichert, daß alle notwendigen Aktionen zum Beenden der Arbeit des Systems eingeleitet werden
- erst wenn das Ende des shutdown-Vorgangs gemeldet wird, kann der Rechner wirklich ausgeschaltet werden - die Meldungen sind bei jedem System verschieden (häufig: halted o.ä.)
- shutdown verwendet dabei eine Reihe anderer UNIX-Kommandos wie z.B. wall, kill, sleep um Nutzer und Prozesse zu informieren und halt, reboot u.ä. um System anzuhalt
- es gibt alternative Kommandos, die man separat anstelle shutdown aufrufen kann, die aber sehr sorgfältig vor ihrer Anwendung studieren werden sollten (Manual) und nur zielgerichtet (z.B. in Problemsituationen) einsetzen sollte)
-
- halt
- sofortiges Anhalten des Rechners; Prozesse werden häufig ignoriert, nur FS werden synchronisiert (alternativ: init 0)
- reboot
- wie halt mit anschließendem Neustart; wird i.allg. bei bestimmten Systemverklemmungen angewendet, wenn ein vollständiges shutdown nicht erfolgreich ist (alternativ: init 6)
- kill
- es ist prinzipiell möglich, durch Senden bestimmter Signale an den init-Prozeß, einige Formen des shutdown zu realisieren, z.B.:
kill 1 im BSD wie shutdown now(SIGTERM)
kill 1 1 im Sytsem V erneutes Lesen der inittab(SIGINT)
sollte in der Regel nicht gemacht werden, da recht undurchsichtig
- in einigen Systemen gibt es spezielle Formen obiger Kommandos, die in bestimmten Situationen notwendig sind:
<strg><alt><del>- das File /etc/nologin führt in einigen BSD-Systemen dazu, daß sich keine Nutzer anmelden können, wenn es existiert - das entspräche dem Run-Level 1 unter System V
 |
Zur Homepage des URZ Th.Müller, Christoph Ziegler, letzte Überarbeitung 21.Februar 2001 |
