Linux/Prozesse: Unterschied zwischen den Versionen

Aus Foxwiki
Subpages:
Versionsgeschichte interaktiv durchsuchen
← Zum vorherigen Versionsunterschied
VisuellWikitext
Keine Bearbeitungszusammenfassung
K Textersetzung - „bzw.  “ durch „bzw. “
 
(35 dazwischenliegende Versionen von 2 Benutzern werden nicht angezeigt)
Zeile 1: Zeile 1:
=  Linux- Prozessverwaltung =
Prozesse bilden das tragende Konzept eines jeden Betriebssystems. Prozesse werden gestartet, angehalten, reaktiviert, beendet, ihre Ausgaben unterbunden usw.
Alle Maßnahmen, die die Arbeit der Prozesse beeinflussen, fasst man daher unter dem Begriff der Prozesssteuerung zusammen.
Die Shells tragen der Bedeutung solcher Mechanismen Rechnung, indem sie unterschiedlichste Möglichkeiten bieten, Prozessen die Richtung zu weisen.
Wenn die Festplatte kreischt, oder der Bildschirm flimmert, wenn die Soundkarte tönt oder der Prozessor sich erhitzt,... - immer dann zeichnet ein Prozess dafür verantwortlich.
Programme sind die Ablaufpläne, nach denen etwas zu verrichten ist und Prozesse die Instanzen, die letztlich die Arbeit verrichten.
Wann immer im System sich etwas dreht, dann ist ein Prozess am werkeln und selbst wenn der Prozessor scheinbar ruht, ist ein Prozess - der Idle-Prozess - aktiv und tut nichts anderes, als zu warten, dass sich wieder etwas tut.
So ein Prozess im System steht nicht nur für sich allein, sondern ist in die Gesellschaft von seinesgleichen integriert, mit denen er auch Informationen [http://shallg.htm/#prco austauschen] kann.
Die dabei grundlegende Beziehung ist die Eltern-Kind-Verwandtschaft zwischen einem Prozess und den von ihm erzeugten Prozessen.
Der Ursprung aller Prozesse und »Prozessfamilien« liegt im '''init-Prozess''', der als erster Prozess beim Start des Systems mit der Prozessnummer (PID) 1 ins Leben gerufen wird, und dann die elementaren Programme des Systems startet.
Wenn man alle im System laufenden Prozesse auf Basis dieser Beziehung betrachtet, erhält man einen Prozessbaum. Die Hierarchie lässt sich z.B. mit dem Kommando '''pstree''' darstellen:
pstree
  init-+-actived
      |-atd
      |-cron
      |-in.identd---in.identd---5*[in.identd]
      |-inetd
      |-innd-+-archive
      |      |-controlchan
      |      |-nnrpd
      |      `-overchan
      |-kdm-+-X
      |    `-kdm---fvwm2-+-FvwmButtons
      |                  |-FvwmPager
      |                  |-netscape---netscape
      |                  |-xosview.bin
      |                  |-xterm---tail
      |                  |-xterm---bash-+-bash1
      |                  |              `-objectman
      |                  |-2*[xterm---bash]
      |                  |-xterm---bash-+-su---bash
      |                                  `-xterm---bash
      |-kflushd
      |-klogd
      |-kpiod
      |-kswapd
      |-kupdate
      |-lockd---rpciod
      |-login---sh
===  Was ist ein Prozess?  ===
Ein Stück Programm-Code, das zur Ausführung in den Hauptspeicher geladen wurde, und im System durch Parameter wie Prozessnummer (PID), Elternprozessnummer (PPID), Besitzer, Priorität, Nice-Level, Status usw. gekennzeichnet ist. Einige Parameter bringt das Kommando ps zum Vorschein:
ps -ef | head
  UID      PID  PPID  C STIME TTY        TIME CMD
  root      1    0  0 May24 ?      00:00:03 init [3]
  root      2    1  0 May24 ?      00:00:02 [kflushd]
  root      3    1  0 May24 ?      00:00:00 [kupdate]
  root      4    1  0 May24 ?      00:00:00 [kpiod]
  root      5    1  0 May24 ?      00:00:11 [kswapd]
  root      6    1  0 May24 ?      00:00:00 [md_thread]
  bin      90    1  0 May24 ?      00:00:00 [portmap]
  root      98    1  0 May24 ?      00:00:06 /usr/sbin/scanlogd
  root    104    1  0 May24 ?      00:00:01 /usr/sbin/syslogd
Die '''PID''' (Prozessnummer) ist die eindeutige Kennzeichnung eines Prozesses während der Laufzeit des Systems, '''PPID''' ist die Prozessnummer seines Elternprozesses und '''UID''' (Nutzerkennung) der den Prozess startende Benutzer.
Wichtig zu wissen ist, dass ein Prozess, dessen Elternprozess nicht mehr existiert, automatisch dem init-Prozess (PID=1) zugeordnet wird. Die Priorität ('''C''') ist ein während der Laufzeit der Prozesses dynamisch bestimmter Wert, der für die Zuteilung von CPU-Zeit verwendet wird.
Des Weiteren sehen wir bei der Ausgabe von '''ps''' die Startzeit '''STIME''', das mit dem Prozess verbundene Terminal '''TTY''' (in obigem Beispiel sind allerdings nur Prozesse dargestellt, die keine Ausgaben auf ein Terminal tätigen; diesen Sachverhalt kennzeichnet das Fragezeichen) und den Namen der Programme, die von den Prozessen ausgeführt werden.
===  Wie wird eine Prozess generiert  ===
==== und wie sieht sein weiterer Weg aus? ====
Die beiden wesentlichen Aktionen bei der Prozessentstehung sind die Systemaufrufe '''fork()''' und '''exec()'''. Mittels '''fork()''' wird ein neuer Prozess erzeugt, der zunächst dasselbe Programm wie sein Elternprozess ausführt.
Erst mit dem Aufruf von '''exec()''' wird ein Prozess das alte Programm durch ein neues ersetzen und dessen Ausführung beginnen.
Der '''exec()''' Aufruf hat seinen Weg auch in den Funktionsumfang der in die Shell eingebauten Kommandos gefunden:
exec ls
login:
===== Erklärung =====
Im Beispiel wurde das Programm des laufenden Prozesses durch das Kommando '''ls''' ersetzt.
Da der aktive Prozess die Shell selbst ist, wird diese beendet und nachdem nun auch '''ls''' seine Tätigkeit abgeschlossen hat, finden wir uns auf der Login-Konsole wieder (sofern es sich um die Login-Shell selbst handelte).
'''fork()''' existiert nicht als eigenständiges Kommando. Eine Shell wird diesen Systemruf immer tätigen, um ein Programm innerhalb eines neuen Prozesses auszuführen.
Eine Shell vermag (fast) beliebig viele Prozesse zu starten, jedoch wartet sie in den häufigsten Fällen auf die Terminierung des zuletzt gestarteten Prozesses:
sleep 100
<nowiki># 100 Sekunden verstreichen, die Shell wartet...</nowiki>
Uns als Anwender steht es nun zu, einem Prozess zu signalisieren, dass er sich z.B. regulär beenden [Ctrl]-[D] , ist i.A. programmabhängig) oder seine Verarbeitung abbrechen ([Ctrl]-[C]) soll:
cat
  Die Eingabe muss mittels [Ctrl]-[D] beendet[Enter]
  Die Eingabe muss mittels [Ctrl]-[D] beendet
  oder mit [Ctrl]-[C] abgebrochen werden[Enter]
  oder mit [Ctrl]-[C] abgebrochen werden
  [Ctrl]-[C]
'''Anmerkung'''
'Das reguläre Beenden eines Prozesses kann auf verschiedenen Wegen erfolgen.  '
In obigem Beispiel ist das Programm '''cat''' eigentlich dazu gedacht, aus einer Datei zu lesen, und beendet sich, sobald das Dateiende erreicht ist.
Wird jedoch von der Standardeingabe eingelesen, und ist diese wie in diesem Fall mit der Tastatur verbunden, so muss der Nutzer dem Programm signalisieren, dass das »Dateiende« erreicht wurde.
Dies erfolgt mit dem End-of-File-Zeichen (kurz '''EOF'''), das auf der Tastatur mit der Tastenkombination [Ctrl]-[D] generiert wird.
In solchen Fällen bestünde keine Möglichkeit, beliebig viele Prozesse quasi-parallel zu starten, da der soeben initiierte Prozess die Shell für weitere Eingaben blockiert.
Die Lösung des Problems liegt im Verschieben des Prozesses in den Hintergrund.
Dabei wird er von der Ein- und Ausgabe der Shell abgekoppelt und läuft im Hintergrund weiter, bis er sich selbst beendet, oder aber auf Grund einer notwendigen Interaktion mit dem Benutzer zum Anhalten gezwungen ist.
<nowiki># Start eines Hintergrundprozesses, der keine Eingaben erwartet</nowiki>
ls -lR > /dev/null &
[1] 706
"beliebiges Arbeiten auf der Kommandozeile" [Enter]
[1]+  Done          ls $LS_OPTIONS -lR >/dev/null
user@sonne>
<nowiki># Start eines Hintergrundprozesses, der Eingaben erwartet</nowiki>
(ls -Rl >/dev/null; cat)&
[1] 720
[Enter]
[1]+  Stopped      (ls $LS_OPTIONS -Rl >/dev/null; cat)
fg
(ls $LS_OPTIONS -Rl >/dev/null; cat)
hallo[Enter]
hallo
[Ctrl]-[D]
Jedes im Hintergrund laufende Programm wird als Job bezeichnet.
Nach Beendigung der Eingabe des Kommandos mit [Enter] gibt die Bash auf der Standardfehlerausgabe eine Zeile mit Jobinformationen aus, wie am Beispiel zu erkennen ist.
Diese beinhaltet in eckigen Klammern eine fortlaufende, von der Shell vergebene Jobnummer und die vom System dem Prozess zugeordnete Prozessnummer ('''PID''').
Mit dem Kommando '''jobs''' kann man Informationen über die derzeit auf einer Shell laufenden Hintergrundprozesse erlangen:
cat &
  [1] 1343
 
  [1]+  Stopped            cat
 
  time dd count=1000000 if=/dev/zero of=/dev/null &
  [2] 1346
  jobs
  [1]+  Stopped            cat
  [2]-  Running            time dd count=1000000 if=/dev/zero of=/dev/null &
  1000000+0 Records ein
  1000000+0 Records aus
 
  real    0m13.817s
  user    0m9.430s
  sys    0m4.040s
  [2]-  Done              time dd count=1000000 if=/dev/zero of=/dev/null
  exit
  exit
  There are stopped jobs.
  jobs
  [1]+  Stopped            cat
  exit
<nowiki># Shell wurde beendet </nowiki>
===  Ohne direkten Kontakt  ===
Die bisher vorgestellten Fälle betrachteten nur die Möglichkeit, Programme während einer Sitzung parallel von einer Shell aus zu starten, und im Hintergrund ablaufen zu lassen.
Interessant ist aber auch der Weg, Programme auf der Shell zu starten, und diese nach dem [http://logout.htm/ Abmelden], sprich dem Beenden der benutzten Shell, weiter laufen zu lassen.
Bisher waren in allen Beispielen die gestarteten Programme an die aufrufende Shell gebunden. So dass bei Beendigung selbiger auch die an sie gebundenen Prozesse den Aufruf zum Beenden erhalten.
Um Programme von der Shell abzukoppeln, wird das Kommando '''nohup''' verwendet.
Dieses schirmt das Programm vom '''HUP'''-Signal der Shell ab, so dass es nach dem Beenden der Shell unabhängig weiter laufen kann:
nohup ls -lR / >/dev/null &
  [1] 2511
  ps -ef | grep 2511
  user    2511  2502 20 00:28 tty5    00:00:02 ls -lR /
  user    2514  2502  0 00:28 tty5    00:00:00 grep 2511
  exit
 
  ...auf einer anderen oder neuen Shell:
  Have a lot of fun...
  ps -ef | grep 2511
  user    2511    1 14 00:28 ?      00:00:05 ls -lR /
  user    2524  2516  0 00:29 tty5    00:00:00 grep 2511
'''nohup''' startet das Programm nicht selbstständig im Hintergrund.
So ist es möglich, ein Programm analog zum »normalen« Vorgehen (ohne »'''nohup'''«) zu starten, eventuell notwendige Eingaben vorzunehmen und erst im Anschluss das Programm durch Eingaben von [Ctrl]-[Z] und nachfolgendem '''bg''' in den Hintergrund zu schicken.
Erst jetzt existiert der das Programm ausführende Prozess tatsächlich abgenabelt von seinem Vorfahren.
Ein Prozess, der keine Eingaben benötigt, lässt sich bequem durch ein der Kommandozeile nachgestelltes '''&''' unverzüglich vom Elternprozess entkoppeln.
Und welche Möglichkeiten bleiben mir nun, um solch einen Prozess nachträglich zu beeinflussen?
Eine direkte Verbindung zum Terminal wie bei '''fg''' ist nicht mehr möglich. Hier hilft nur noch eine indirekte Kommunikation über Signale, die u.a. mit dem Kommando '''kill''' übermittelt werden können:
dd if=/dev/zero of=/dev/null &
  [1] 20098
 
  ps -axuw | grep 20098
  user    20098 30.5  0.3  1204  448 pts/4    R    11:49  0:36 dd if=/dev/zero of=/dev/null
  kill -19 20098
  ps -axuw | grep 20098
  user    20098 75.9  0.3  1204  448 pts/4    T    11:49  1:01 dd if=/dev/zero of=/dev/null
  kill -18 20098
  ps -axuw | grep 20098
  user    20098 55.5  0.3  1204  448 pts/4    R    11:49  1:54 dd if=/dev/zero of=/dev/null
  kill -15 20098
'''Erläuterung'''
Das Kommando »'''dd'''« (zum »Low-Level«-Kopieren) wird im Hintergrund gestartet. Dass es aktiv ist, bestätigt das »'''R'''« (running) in der Ausgabe des Kommandos '''ps'''. In einer weiteren Eingabe wird dem Prozess die Aufforderung zum Stoppen signalisiert (Signal Nr. 19).
Dass es tatsächlich funktioniert hat, beweist nun das »'''T'''« (traced oder gestoppt) in der »'''ps'''«-Ausgabe.
Mit dem Signal 18 schließlich wird der Prozess reaktiviert; das »'''R'''« ist wieder in der Ausgabe zu sehen.
Damit unser Beispielkommando nicht für alle Zeit die Nullen in den Mülleimer befördert, brechen wir es mit dem Signal 15 (Aufforderung zum Beenden) ab.
===  Entstehen und Vergehen ===
Ein Prozess entsteht, indem ein Elternprozess mittels des Systemrufes '''fork()''' einen neuen Prozess erzeugt (Ausnahme ist '''init''', der einzige "von Hand generierte" Prozess). Dieser Kindprozess teilt sich alle Ressourcen mit dem Elternprozess, wesentliche Unterschiede sind nur ein eigener Stack und eine eigene '''PID'''.
Anhand des Rückgabewertes von '''fork()''' ist es den beiden Prozessen nun möglich, zu unterscheiden, ob es sich um den Vorfahren oder einen Nachkommen handelt.
In Abhängigkeit hiervon wird nun ein Kindprozess mittels des Systemrufes '''exec()''' ein neues Programm laden.
Irgendwann wird ein Kindprozess seine Arbeit beenden und signalisiert diesen Zustand seinem Elternprozess durch eine entsprechende Nachricht.
Obwohl der Kindprozess bereits jetzt aus Speicher und Prozesstabelle entfernt ist, muss dieses Signal noch verarbeitet werden. Für gewöhnlich zeichnet der Elternprozess dafür verantwortlich.
Zwei Situationen könnten den "normalen Werdegang" durcheinander bringen:
Der Elternprozess ist andersweitig beschäftigt (befindet sich im Zustand D o.a.).
In einem solchen Fall symbolisiert der Zustand '''Z''' das noch zu behandelnde Signal. Genau genommen durchläuft jeder Kindprozess die Laufbahn eines Zombies (Zeitspanne zwischen Ableben und Signalbehandlung), jedoch ist sie meist von so kurzer Dauer, dass man gar nichts davon mitbekommt.
Der Elternprozess existiert nicht mehr (Programmfehler o.a.). Jetzt ist der init-Prozess für der Signalbehandlung verantwortlich
==  Prozesse kontrollieren ==
==  Prozesse kontrollieren ==
===  Prozessstatus (ps) ===
===  Prozessstatus (ps) ===
(''process status'') zeigt die Prozesse mit ihrem Status an


ps [Optionen]  
ps [Optionen]  
 
(''process status'') zeigt die Prozesse mit ihrem Status an


'''Optionen'''
'''Optionen'''


{|class="wikitable" align="center"
{|class="wikitable" align="center"
Zeile 298: Zeile 40:
|-
|-
|}
|}


'''Bedeutung der Spalten '''
'''Bedeutung der Spalten '''


{|class="wikitable"
{|class="wikitable"
Zeile 346: Zeile 86:
| | '''W'''
| | '''W'''
| | nicht mehr im Arbeitsspeicher
| | nicht mehr im Arbeitsspeicher


|-
|-
|}
|}
===  Prozessbaum (pstree) ===
===  Prozessbaum (pstree) ===
 
Das Kommando stellt die aktiven Prozesse in einer Baumstruktur dar, welche die Prozessvererbung symbolisiert.
  pstree    [-a] [-c] [-h|-Hpid] [-l] [-n] [-p] [-u] [-G|-U] [pid|user]
  pstree    [-a] [-c] [-h|-Hpid] [-l] [-n] [-p] [-u] [-G|-U] [pid|user]


Das Kommando stellt die aktiven Prozesse in einer Baumstruktur dar, welche die Prozessvererbung symbolisiert.
==== Beispiel ====
 
<u>Beispiel</u>
 
  pstree
  pstree
   init-+-actived
   init-+-actived
Zeile 379: Zeile 115:
       |-syslogd  
       |-syslogd  


Das Beispiel verdeutlicht, dass '''init''' der Elternprozess aller Prozesse ist. '''pstree''' versucht per Voreinstellung identische Prozesse in der Darstellung zusammen zu fassen, so bedeutet '''2*[mingetty]''', dass 2 Prozesse das Kommando '''mingetty''' ausführen.  
* Das Beispiel verdeutlicht, dass '''init''' der Elternprozess aller Prozesse ist. '''pstree''' versucht per Voreinstellung identische Prozesse in der Darstellung zusammen zu fassen, so bedeutet '''2*[mingetty]''', dass 2 Prozesse das Kommando '''mingetty''' ausführen.  
 
* Mit der Option '''-c''' wird diese Zusammenfassung abgeschaltet:
Mit der Option '''-c''' wird diese Zusammenfassung abgeschaltet:
...
 
...
   |-in.identd---in.identd-+-in.identd
   |-in.identd---in.identd-+-in.identd
       |                      |-in.identd
       |                      |-in.identd
Zeile 389: Zeile 123:
       |                      |-in.identd
       |                      |-in.identd
       |                      `-in.identd
       |                      `-in.identd
  ...  
  ...


===  Taskmanager (top) ===
===  Taskmanager (top) ===
 
'''top''' listet Prozesse, sortiert nach ihrem Anteil an CPU-Zeit, auf.
 
 
  top [-] [d delay] [q] [c] [S] [s] [i] [n] [b]  
  top [-] [d delay] [q] [c] [S] [s] [i] [n] [b]  


[[Image:Grafik1.png|right]]'''top''' listet Prozesse, sortiert nach ihrem Anteil an CPU-Zeit, auf.
* Nach Voreinstellung wird diese Liste aller 5 Sekunden aktualisiert, mit der Option '''-d Zeit''' kann ein anderes Intervall eingestellt werden.  
 
* Eine Option '''-q''' lässt das Kommando die Liste so oft wie möglich aktualisieren, mit '''-n Anzahl''' kann die Anzahl der Refreshes eingeschränkt werden. Anschließend wird '''top''' seine Arbeit beenden.
Nach Voreinstellung wird diese Liste aller 5 Sekunden aktualisiert, mit der Option '''-d Zeit''' kann ein anderes Intervall eingestellt werden.  
* Als Überschrift zeigt '''top''' die [http://sysinfo.htm/#uptime Uptime], die Anzahl der Prozesse, eingeteilt nach ihrem Status, die Auslastung von CPU, Speicher und Swap an.  
 
* Es folgen die Informationen zu den einzelnen Prozessen (die Auflistung enthält nur die Beschreibung der Standard-Informationen)
Eine Option '''-q''' lässt das Kommando die Liste so oft wie möglich aktualisieren, mit '''-n Anzahl''' kann die Anzahl der Refreshes eingeschränkt werden. Anschließend wird '''top''' seine Arbeit beenden.
 
Als Überschrift zeigt '''top''' die [http://sysinfo.htm/#uptime Uptime], die Anzahl der Prozesse, eingeteilt nach ihrem Status, die Auslastung von CPU, Speicher und Swap an. Es folgen die Informationen zu den einzelnen Prozessen (die Auflistung enthält nur die Beschreibung der Standard-Informationen)
 


{|class="wikitable"
{|class="wikitable"
Zeile 445: Zeile 173:
|-
|-
|}
|}
'''Interaktive Arbeit mit top'''
'''Interaktive Arbeit mit top'''
 
* Während das Kommando in periodischen Abständen das Terminal mit neuen Informationen überschwemmt, lassen sich verschiedenste Aktionen vornehmen.  
Während das Kommando in periodischen Abständen das Terminal mit neuen Informationen überschwemmt, lassen sich verschiedenste Aktionen vornehmen.  
* Folgende Eingaben (Auswahl) bewirken folgende Reaktion:
 
Folgende Eingaben (Auswahl) bewirken folgende Reaktion:
 


{|class="wikitable"
{|class="wikitable"
Zeile 459: Zeile 185:
| | '''f'''
| | '''f'''
| | Hierüber kann die Anzeige der Informationen eingestellt werden.  
| | Hierüber kann die Anzeige der Informationen eingestellt werden.  
 
* Es erscheint eine Auflistung aller Informationsfelder, wobei ausgewählte Felder mit einem Stern '''*''' gekennzeichnet sind.  
Es erscheint eine Auflistung aller Informationsfelder, wobei ausgewählte Felder mit einem Stern '''<nowiki>*</nowiki>''' gekennzeichnet sind.  
* Vor jedem Feld steht ein Bezeichner (Buchstabe), durch dessen Eingabe die Auswahl umgeschalten wird. Rückkehr zur Ausgabe von top durch [Enter].
 
Vor jedem Feld steht ein Bezeichner (Buchstabe), durch dessen Eingabe die Auswahl umgeschalten wird. Rückkehr zur Ausgabe von top durch [Enter].
|-
|-
| | '''h bzw. ?'''
| | '''h bzw.&nbsp;?'''
| | Anzeige einer Kurzhilfe zu den verschiedenen Kommandos
| | Anzeige einer Kurzhilfe zu den verschiedenen Kommandos
|-
|-
Zeile 470: Zeile 194:
| | Zum Senden von Signalen an einen Prozess. Es wird zur Angabe der PID und des zu sendenden Signals aufgefordert.
| | Zum Senden von Signalen an einen Prozess. Es wird zur Angabe der PID und des zu sendenden Signals aufgefordert.
|-
|-
| | '''n bzw. #'''
| | '''n bzw.&nbsp;#'''
| | Zum Ändern der Anzahl angezeigter Prozesse. Man wird zur Eingabe der neuen Anzeige aufgefordert.
| | Zum Ändern der Anzahl angezeigter Prozesse. Man wird zur Eingabe der neuen Anzeige aufgefordert.
|-
|-
| | '''o'''
| | '''o'''
| | Ändern der Reihenfolge der Darstellung der Felder.  
| | Ändern der Reihenfolge der Darstellung der Felder.  
 
* In der oberen Zeile der erscheinenden Ausgabe ist die Reihenfolge symbolisch dargestellt, wobei ein gewähltes Feld durch einen Großbuchstaben markiert ist.  
In der oberen Zeile der erscheinenden Ausgabe ist die Reihenfolge symbolisch dargestellt, wobei ein gewähltes Feld durch einen Großbuchstaben markiert ist.  
* Durch Eingabe des entsprechenden Feldbezeichners als Kleinbuchstabe, wird der Eintrag in der Liste "nach hinten" befördert; mittels des Großbuchstaben nach vorn. Rückkehr zur Ausgabe von top durch [Enter]
 
Durch Eingabe des entsprechenden Feldbezeichners als Kleinbuchstabe, wird der Eintrag in der Liste "nach hinten" befördert; mittels des Großbuchstaben nach vorn. Rückkehr zur Ausgabe von top durch [Enter]


'''Current Field Order: bAcDgHIjklMnoTPrqsuzVYEFWX
'''Current Field Order: bAcDgHIjklMnoTPrqsuzVYEFWX
  Upper case characters move a field to the left, lower case to the right
  Upper case characters move a field to the left, lower case to the right
   
   
  <nowiki>* A: PID</nowiki>       <nowiki>= Process Id</nowiki>
  * A: PID        = Process Id
   B: PPID      <nowiki>= Parent Process Id</nowiki>
   B: PPID      = Parent Process Id
   C: UID        <nowiki>= User Id</nowiki>
   C: UID        = User Id
  <nowiki>* D: USER </nowiki>      <nowiki>= User Name</nowiki>
  * D: USER       = User Name
  <nowiki>* E: %CPU </nowiki>      <nowiki>= CPU Usage</nowiki>
  * E: %CPU       = CPU Usage
  <nowiki>* F: %MEM </nowiki>      <nowiki>= Memory Usage</nowiki>
  * F: %MEM       = Memory Usage
   G: TTY        <nowiki>= Controlling tty</nowiki>
   G: TTY        = Controlling tty
  <nowiki>* H: PRI </nowiki>      <nowiki>= Priority</nowiki>
  * H: PRI       = Priority
  <nowiki>* I: NI </nowiki>        <nowiki>= Nice Value</nowiki>
  * I: NI         = Nice Value
  ...'''  
  ...'''  
|-
|-
Zeile 499: Zeile 221:
| | '''q'''
| | '''q'''
| | Beendet top
| | Beendet top


|-
|-
|}
|}
===  nice - Prozess mit anderer Priorität ===
===  nice - Prozess mit anderer Priorität ===
nice [OPTION]... [COMMAND [ARG]...]
* Ein zu startendes Kommando kann durch '''nice''' eine andere als die voreingestellte Priorität gegeben werden. D.h. im Vergleich zur "normalen Priorität" erhält ein solcher Prozess prozentual weniger/mehr Rechenzeit zugeteilt.
* Ein Wert von -20 bedeutet dabei die höchste Priorität; ein Wert von 20 die geringste.
* Ein normaler Nutzer darf die Priorität eines Prozesses nur verringern (also den Wert erhöhen), nur Root kann diese erhöhen (den Wert verringern).


nice [OPTION]... [COMMAND [ARG]...]
==== Beispiel ====
 
Ein zu startendes Kommando kann durch '''nice''' eine andere als die voreingestellte Priorität gegeben werden. D.h. im Vergleich zur "normalen Priorität" erhält ein solcher Prozess prozentual weniger/mehr Rechenzeit zugeteilt.
 
Ein Wert von -20 bedeutet dabei die höchste Priorität; ein Wert von 20 die geringste.
 
Ein normaler Nutzer darf die Priorität eines Prozesses nur verringern (also den Wert erhöhen), nur Root kann diese erhöhen (den Wert verringern).
 
<u>Beispiel</u>
 
  nice -n 19 gcc bigprogram.c
  nice -n 19 gcc bigprogram.c
   root@sonne> nice -n -10 inetd
   root@sonne> nice -n -10 inetd
 
* Mit renice kann die Priorität eines laufenden Prozesses beeinflusst werden.
Mit renice kann die Priorität eines laufenden Prozesses beeinflusst werden.


===  renice - Prozesspriorität ändern ===
===  renice - Prozesspriorität ändern ===
 
  renice priority [[-p] pid ...] [[-g] pgrp ...] [[-u] user ...]
  <nowiki>renice priority [[-p] pid ...] </nowiki><nowiki>[[-g] pgrp ...] [[-u] user ...]</nowiki>
* Prozessen kann mittels '''renice''' nachträglich eine andere Priorität zugeteilt werden. Wie auch bei '''nice''' gilt, dass einzig Root die Priorität erhöhen darf.  
 
Prozessen kann mittels '''renice''' nachträglich eine andere Priorität zugeteilt werden. Wie auch bei '''nice''' gilt, dass einzig Root die Priorität erhöhen darf.  


<u>Beispiel</u>
<u>Beispiel</u>
Zeile 532: Zeile 246:
   renice -10 23258
   renice -10 23258
   renice: 23258: setpriority: Keine Berechtigung
   renice: 23258: setpriority: Keine Berechtigung
 
* Das Kommando erlaubt das gleichzeitige Verändern der Prioritäten mehrerer Prozesse. Mögliche Angaben sind: Mehrere Process-IDs, '''-g GID''' Die Gruppennummer von Prozessen, '''-u Nutzer''' Der Besitzer der Prozesse
Das Kommando erlaubt das gleichzeitige Verändern der Prioritäten mehrerer Prozesse. Mögliche Angaben sind: Mehrere Process-IDs, '''-g GID''' Die Gruppennummer von Prozessen, '''-u Nutzer''' Der Besitzer der Prozesse


===  nohup - Prozess abnabeln ===
===  nohup - Prozess abnabeln ===
  nohup    COMMAND [ARG]...  
  nohup    COMMAND [ARG]...  
 
* Das von '''nohup''' gestartete Kommando läuft unabhängig von der aktiven Shell. D.h. ein so gestartetes Kommando arbeitet auch nach dem Beenden der Sitzung ('''logout''') weiter.  
Das von '''nohup''' gestartete Kommando läuft unabhängig von der aktiven Shell. D.h. ein so gestartetes Kommando arbeitet auch nach dem Beenden der Sitzung ('''logout''') weiter.  
* Die Ausgaben von '''nohup''' werden ggf. in eine Datei '''nohup.out''' umgeleitet. Kann diese im aktuellen Verzeichnis nicht erzeugt werden, wird sie im Heimatverzeichnis angelegt.  
 
* Scheitert auch dies, beendet '''nohup''' seine Tätigkeit.
Die Ausgaben von '''nohup''' werden ggf. in eine Datei '''nohup.out''' umgeleitet. Kann diese im aktuellen Verzeichnis nicht erzeugt werden, wird sie im Heimatverzeichnis angelegt.  
* Ein über '''nohup''' gestartetes Kommando erhält eine um 5 erhöhte Priorität.
 
Scheitert auch dies, beendet '''nohup''' seine Tätigkeit.
 
Ein über '''nohup''' gestartetes Kommando erhält eine um 5 erhöhte Priorität.


  bash
  bash
Zeile 552: Zeile 260:
   exit
   exit
   ps eax | grep spleepproc
   ps eax | grep spleepproc
   user@sonne>
    
   bash
   bash
   nohup ./sleepproc&
   nohup ./sleepproc&
Zeile 561: Zeile 269:


'''Anmerkung'''
'''Anmerkung'''
* Im Beispiel wird in einer Subshell ein Skript "sleepproc" gestartet und die Shell beendet.
* Wie zu erwarten war, wurde der in der Shell gestartete Prozess mit dem Ende der Shell beendet.
* In einem zweiten Schritt wird das Skript "sleepproc" unabhängig von der Shell gestartet... es existiert auch nach Beendigung der Shell weiter.


Im Beispiel wird in einer Subshell ein Skript "sleepproc" gestartet und die Shell beendet.  
2.7 Konfiguration neu laden
 
Ein typisches Beispiel für einen Systemdienst ist der Apache-HTTP-Server. Dies besteht aus einer Reihe von Hintergrundprozessen (Daemons), die beim Starten des Computers gestartet und beim Herunterfahren gestoppt werden. Der Betrieb des Dienstes wird durch eine Reihe von Konfigurationsdateien geregelt, die beim Starten des Dienstes gelesen werden.
Wie zu erwarten war, wurde der in der Shell gestartete Prozess mit dem Ende der Shell beendet.
Änderungen an der Konfiguration eines Dienstes werden nicht unbedingt sofort wirksam: Möglicherweise muss ein SIGHUP gesendet oder die entsprechenden Prozesse beendet und anschließend neu gestartet werden.
 
Zum Zeitpunkt des Schreibens (Januar 2011) sind zwei Mechanismen für die Verwaltung von Systemdiensten gebräuchlich: Init-Skripte im System V-Stil und Upstart. Die meisten der wichtigsten GNU / Linux-Distributionen werden derzeit von der ersteren auf die letztere migriert.
In einem zweiten Schritt wird das Skript "sleepproc" unabhängig von der Shell gestartet... es existiert auch nach Beendigung der Shell weiter.
====  Bestimmen Sie den Namen des Dienstes ====
 
* Jeder Dienst hat einen Namen, mit dem er identifiziert wird. Dies ist nicht unbedingt derselbe wie der Name des Pakets, von dem es installiert wurde, oder eines der Hintergrundprozesse, die es möglicherweise erzeugt. Unterschiedliche Distributionen können unterschiedliche Namen für denselben Dienst auswählen.
===  Configuration reload ===
* In der folgenden Tabelle sind die Namen aufgeführt, die Debian (Lenny), Ubuntu (Lucid), CentOS (5.5) und SUSE (11.3) für einige der Dienste verwenden, auf die Sie am wahrscheinlichsten stoßen:
 
A typical example of a system service is the Apache HTTP server. This consists of a set of background processes (daemons) which are started when the machine boots and stopped when it is shut down. The operation of the service is governed by a set of configuration files which are read when the service is started.
 
Changes made to the configuration of a service do not necessarily take effect immediately: it may be necessary for a SIGHUP to be sent, or for the relevant processes to be killed then restarted.
 
At the time of writing (January 2011) there are two mechanisms in common use for managing system services: System&nbsp;V-style init scripts and Upstart. Most of the major GNU/Linux distributions are in the process of migrating from the former to the latter.
 
====  Determine the name of the service ====
 
Every service has a name that is used to identify it. This is not necessarily the same as the name of the package from which it was installed, or any of the background processes it may spawn. Different distributions may choose different names for the same service.
 
The following table lists the names used by Debian (Lenny), Ubuntu (Lucid), CentOS (5.5) and SUSE (11.3) for some of the services you are most likely to encounter:
 


{|class="wikitable"
{|class="wikitable"
Zeile 664: Zeile 362:
|-
|-
|}
|}
If you know the name of the package that provides the service then you can find the service name by listing the files in that package and searching for ones with a pathname starting with /etc/init.d/, /etc/rc.d/init.d/ or /etc/init/.  
* Wenn Sie den Namen des Pakets kennen, das den Dienst bereitstellt, können Sie den Dienstnamen finden, indem Sie die Dateien in diesem Paket auflisten und nach Dateien mit einem Pfadnamen suchen, der mit /etc/init.d/, /etc/rc.d beginnt /init.d/ oder / etc / init /.
 
* Auf Debian-basierten Systemen kann dies mit dpkg erfolgen, zum Beispiel:
On Debian-based systems this can be done using dpkg, for example:


  dpkg --listfiles openssh-server | grep "/init"
  dpkg --listfiles openssh-server | grep "/init"
 
* and on Red Hat-based systems using rpm:
and on Red Hat-based systems using rpm:


  rpm -ql openssh-server-4.3p2 | grep "/init"
  rpm -ql openssh-server-4.3p2 | grep "/init"


'Be aware that the top-level package used to install the service may not be the one that contains the control script: it could be provided by a dependency. '
Beachten Sie, dass das zur Installation des Dienstes verwendete Paket der obersten Ebene möglicherweise nicht das Steuerungsskript enthält, das möglicherweise von einer Abhängigkeit bereitgestellt wird. '
* Wenn Sie den Paketnamen nicht kennen, können Sie versuchen, in /etc/init.d und / etc / init nach einem wahrscheinlich aussehenden Dateinamen zu suchen.


If you do not know the package name then you could try searching /etc/init.d and /etc/init for a likely-looking filename.
==== Überprüfen Sie optional die neue Konfiguration ====
 
* Einige Dienste bieten eine Möglichkeit, die Konfiguration vor dem Laden zu überprüfen. Dies ist sehr wünschenswert, wenn ein geschäftskritischer Server ausgeführt wird. Wenn beim Laden ein Fehler auftritt, bleibt möglicherweise kein Dienst verfügbar, bis dieser behoben ist.
==== Optionally, validate the new configuration ====
* Die Methode zum Anfordern einer Validierung hängt von der jeweiligen Software ab, sofern diese überhaupt verfügbar ist. Für Apache auf Debian-basierten Systemen können Sie den Befehl apache2ctl verwenden:
 
Some services provide a means to validate the configuration before loading it. This is highly desirable when running a mission-critical server, because if an error is encountered while loading then you may be left with no service until it is fixed.
 
The method for requesting validation will depend on the software in question, if it is available at all. For Apache on Debian-based systems you can use the apache2ctl command:


  apache2ctl -t
  apache2ctl -t


====  Forcibly reload the configuration ====
====  Forcibly reload the configuration ====
 
* If the service command is available then use it to forcibly reload the configuration. For example, if you have determined that the service name is apache2:
If the service command is available then use it to forcibly reload the configuration. For example, if you have determined that the service name is apache2:


  service apache2 force-reload
  service apache2 force-reload
 
* Otherwise, invoke the init.d script directly:
Otherwise, invoke the init.d script directly:


  /etc/init.d/apache2 force-reload
  /etc/init.d/apache2 force-reload
 
* The meaning of force-reload is that the configuration should be reloaded without restarting the service if possible, but with a restart if necessary. It is preferable to reload or restart because:* reload will fail if it cannot be achieved without restarting the service.  
The meaning of force-reload is that the configuration should be reloaded without restarting the service if possible, but with a restart if necessary. It is preferable to reload or restart because:* reload will fail if it cannot be achieved without restarting the service.  
* restart should work for any well-behaved service, but it causes a short period of downtime which may be unnecessary.  
* restart should work for any well-behaved service, but it causes a short period of downtime which may be unnecessary.  


====  Troubleshooting ====
====  Troubleshooting ====
=====  The service cannot be stopped =====
=====  The service cannot be stopped =====
 
* If force-reload equates to restart then the control script will need to kill any running processes before starting new ones. Sometimes this fails, in which case you will need to identify and kill the running processes yourself.
If force-reload equates to restart then the control script will need to kill any running processes before starting new ones. Sometimes this fails, in which case you will need to identify and kill the running processes yourself.
* Most likely the control script will have attempted a graceful termination using SIGTERM. It is worth trying that again, in case the script did not send the signal for some reason:
 
Most likely the control script will have attempted a graceful termination using SIGTERM. It is worth trying that again, in case the script did not send the signal for some reason:


  killall apache2
  killall apache2
 
* Be patient waiting for processes to exit, because some (such as Squid) can take tens of seconds. However if it is clear that SIGTERM has not worked then you can issue a SIGKILL with a clear conscience:
Be patient waiting for processes to exit, because some (such as Squid) can take tens of seconds. However if it is clear that SIGTERM has not worked then you can issue a SIGKILL with a clear conscience:


  killall -KILL apache2
  killall -KILL apache2


=====  The service does not restart =====
=====  The service does not restart =====
 
* This probably indicates an error in the configuration file. Alternative possibilities include:* failure to stop the service, or  
This probably indicates an error in the configuration file. Alternative possibilities include:* failure to stop the service, or  
* leaving a socket in the TIME_WAIT state.  
* leaving a socket in the TIME_WAIT state.  
 
* A well-written init script should check that a process has died after sending it a SIGTERM, but some do not. If the service listens on a specific port number (as most do) or needs to exclusively lock files then failure to terminate the old instance will prevent a new instance from starting.
 
* Even if the previous instance has stopped, if it has left a server socket in the TIME_WAIT state then it may still prevent a new instance from starting for a short period (typically 2 minutes on Linux).  
 
* The condition occurs when the server terminates an active connection (gracefully or otherwise). Servers can be written to disregard TIME_WAIT, but not without risk. Some do this, some do not.
A well-written init script should check that a process has died after sending it a SIGTERM, but some do not. If the service listens on a specific port number (as most do) or needs to exclusively lock files then failure to terminate the old instance will prevent a new instance from starting.
 
Even if the previous instance has stopped, if it has left a server socket in the TIME_WAIT state then it may still prevent a new instance from starting for a short period (typically 2 minutes on Linux).  
 
The condition occurs when the server terminates an active connection (gracefully or otherwise). Servers can be written to disregard TIME_WAIT, but not without risk. Some do this, some do not.


====  Alternatives ====
====  Alternatives ====
=====  Reboot the machine =====
=====  Reboot the machine =====
 
* It should rarely be necessary to reboot a machine running GNU/Linux, and it certainly isn't necessary to perform the task described here. However there is one advantage to rebooting after a configuration change: it provides assurance that the changes you have made are persistent, and will not break unexpectedly when a reboot is eventually needed.
It should rarely be necessary to reboot a machine running GNU/Linux, and it certainly isn't necessary to perform the task described here. However there is one advantage to rebooting after a configuration change: it provides assurance that the changes you have made are persistent, and will not break unexpectedly when a reboot is eventually needed.


=====  Signal the process directly =====
=====  Signal the process directly =====
 
* If a daemon supports reloaded without restarting then the conventional method for signalling this is to send a SIGHUP, for example:
If a daemon supports reloaded without restarting then the conventional method for signalling this is to send a SIGHUP, for example:


  kill -HUP 29964
  kill -HUP 29964
 
* Do not assume that SIGHUP necessarily has this meaning: in principle it could do anything. You should also exercise caution if there are several copies of the server process running. For example, sending SIGHUP to all copies of sshd would cause one of them to reload the configuration file and the others to terminate the active connections they were handling.
Do not assume that SIGHUP necessarily has this meaning: in principle it could do anything. You should also exercise caution if there are several copies of the server process running. For example, sending SIGHUP to all copies of sshd would cause one of them to reload the configuration file and the others to terminate the active connections they were handling.


==  Interprozesskommunikation  ==
==  Interprozesskommunikation  ==
 
* Signale sind eine Möglichkeit zur Interprozesskommunikation. Vom Kernel verwendet, dienen sie dazu, Prozesse über bestimmte Ereignisse zu informieren; der Nutzer bedient sich ihrer, um hängen gebliebene Prozesse abzubrechen oder diese anzuweisen, ihre Konfigurationsdateien neu einzulesen.  
Signale sind eine Möglichkeit zur Interprozesskommunikation. Vom Kernel verwendet, dienen sie dazu, Prozesse über bestimmte Ereignisse zu informieren; der Nutzer bedient sich ihrer, um hängen gebliebene Prozesse abzubrechen oder diese anzuweisen, ihre Konfigurationsdateien neu einzulesen.  
* Die Nutzersignale unterliegen bestimmten Restriktionen, sie dürfen nur an dem Nutzer zugeordnete Prozesse versandt werden. Nicht einmal '''root''' hat dem init-Prozess etwas zu sagen.  
 
Die Nutzersignale unterliegen bestimmten Restriktionen, sie dürfen nur an dem Nutzer zugeordnete Prozesse versandt werden. Nicht einmal '''root''' hat dem init-Prozess etwas zu sagen.  
 


{|class="wikitable"
{|class="wikitable"
Zeile 777: Zeile 448:
| | '''SIGFPE'''
| | '''SIGFPE'''
| | '''8'''
| | '''8'''
| | Fließkommafehler (z.B. Division durch Null)
| | Fließkommafehler (z.&nbsp;B.&nbsp;Division durch Null)
|-
|-
| | '''SIGKILL'''
| | '''SIGKILL'''
Zeile 816: Zeile 487:
|-
|-
|}
|}
Die genaue Zuordnung zwischen symbolischem Signal und Nummer ist in Linux in der Datei  
* Die genaue Zuordnung zwischen symbolischem Signal und Nummer ist in Linux in der Datei  


  '''/usr/include/linux/asm/signal.h '''
  '''/usr/include/linux/asm/signal.h '''
* zu finden.
* Zum manuellen Versenden von Signalen dienen die beiden Kommandos '''kill''' und '''killall'''. '''kill''' erwartet im Argument die ID des Prozesses, während '''killall''' den Namen des Programms verlangt.
* Beide Kommandos verstehen die Signalangabe in numerischer ('''1''' für '''SIGHUP''',..., '''9''' für '''SIGKILL''',...) als auch in symbolischer ('''HUP''' für '''SIGHUP''',..., '''KILL''' für '''SIGKILL''',...) Form.
* Als Beispiel nehmen wir an, der "Netscape" reagiere nicht mehr (was leider keine hypothetische Annahme darstellt). Also werden wir den entsprechenden Prozess per Hand beenden:


zu finden.
# mittels killall auf die höfliche Tour
 
Zum manuellen Versenden von Signalen dienen die beiden Kommandos '''kill''' und '''killall'''. '''kill''' erwartet im Argument die ID des Prozesses, während '''killall''' den Namen des Programms verlangt.
 
Beide Kommandos verstehen die Signalangabe in numerischer ('''1''' für '''SIGHUP''',..., '''9''' für '''SIGKILL''',...) als auch in symbolischer ('''HUP''' für '''SIGHUP''',..., '''KILL''' für '''SIGKILL''',...) Form.
 
Als Beispiel nehmen wir an, der "Netscape" reagiere nicht mehr (was leider keine hypothetische Annahme darstellt). Also werden wir den entsprechenden Prozess per Hand beenden:
 
<nowiki># m</nowiki>ittels killall auf die höfliche Tour
  killall -15 netscape
  killall -15 netscape
   
   
  <nowiki># reagiert Netscape immer noch nicht, dann auf die harte Tour</nowiki>
  # reagiert Netscape immer noch nicht, dann auf die harte Tour
  killall -KILL netscape
  killall -KILL netscape
   
   
  <nowiki># mittels kill</nowiki>
  # mittels kill
  ps ax | grep netscape     
  ps ax | grep netscape     
  887 tty1    S      2:12 /opt/netscape/netscape
  887 tty1    S      2:12 /opt/netscape/netscape
Zeile 840: Zeile 507:


===  Prozesse beenden mit kill ===
===  Prozesse beenden mit kill ===
  kill·[-s Signal]·[-p]·[-a]·[-l·[Signalnummer]]· Prozess-ID ...
  kill·[-s Signal]·[-p]·[-a]·[-l·[Signalnummer]]· Prozess-ID ...
 
* beendet außer Kontrolle geratene („aufgehängte“) Prozesse und sendet Signale an Prozesse.
beendet außer Kontrolle geratene („aufgehängte“) Prozesse und sendet Signale an Prozesse.
* Das Signal kann mit Namen oder Nummer angegeben werden. Ist kein Signal angegeben, wird '''SIGTERM''' (15) gesendet.
 
* Der Prozess wird kann durch seine Prozessnummer oder seinen Namen angegeben
Das Signal kann mit Namen oder Nummer angegeben werden. Ist kein Signal angegeben, wird '''SIGTERM''' (15) gesendet.
* Signale können ohne Root-Privilegien nur an die eigenen Prozesse gesendet werden.
 
* Prozesse reagieren unterschiedlich auf diese Signale:# Wenn das Anwendungsprogramm eine Funktion zur Behandlung eines Signals bereitstellt kann dieses Signal abgefangen werden. Signale können damit zur asynchronen Fehler- bzw.&nbsp;Ausnahmebehandlung sowie zu einer primitiven Prozesskommunikation genutzt werden.
Der Prozess wird kann durch seine Prozessnummer oder seinen Namen angegeben
 
Signale können ohne Root-Privilegien nur an die eigenen Prozesse gesendet werden.
 
Prozesse reagieren unterschiedlich auf diese Signale:# Wenn das Anwendungsprogramm eine Funktion zur Behandlung eines Signals bereitstellt kann dieses Signal abgefangen werden. Signale können damit zur asynchronen Fehler- bzw. Ausnahmebehandlung sowie zu einer primitiven Prozesskommunikation genutzt werden.
# Das Signal kann ignoriert werden. Das ist der Regelfall für alle Signale die nicht abgefangen werden.
# Das Signal kann ignoriert werden. Das ist der Regelfall für alle Signale die nicht abgefangen werden.
# Die Signale '''SIGKILL''' und '''SIGSTOP''' können nicht abgefangen werden, sie werden direkt vom Kernel behandelt. Mit '''SIGKILL''' (9) wird der Prozess sofort beendet.
# Die Signale '''SIGKILL''' und '''SIGSTOP''' können nicht abgefangen werden, sie werden direkt vom Kernel behandelt. Mit '''SIGKILL''' (9) wird der Prozess sofort beendet.


<u>Optionen</u>
<u>Optionen</u>


{|class="wikitable"
{|class="wikitable"
Zeile 870: Zeile 528:
| | '''-l'''
| | '''-l'''
| | gibt eine Namensliste aller Signale aus; eine Signalnummer als Argument wird in den entsprechenden Signalnamen übersetzt
| | gibt eine Namensliste aller Signale aus; eine Signalnummer als Argument wird in den entsprechenden Signalnamen übersetzt


|-
|-
|}
|}
===  killall - Prozessen Signale senden ===
===  killall - Prozessen Signale senden ===
 
* killall [-egiqvw] [-signal] name ...  
killall [-egiqvw] [-signal] name ...  
* Der wesentlichste Unterschied zum Kommando kill ist die Spezifizierung der Prozesse über den Namen der Kommandos, die sie ausführen oder mittels ihrer Gruppennummer (-g GID).
 
Der wesentlichste Unterschied zum Kommando kill ist die Spezifizierung der Prozesse über den Namen der Kommandos, die sie ausführen oder mittels ihrer Gruppennummer (-g GID).


'''killall''' sendet allen Prozessen Signale, die das Kommando ausführen, mit der Option '''-i''' kann aber eine nochmalige Rückfrage vor dem tatsächlichen Senden erzwungen werden:
'''killall''' sendet allen Prozessen Signale, die das Kommando ausführen, mit der Option '''-i''' kann aber eine nochmalige Rückfrage vor dem tatsächlichen Senden erzwungen werden:
Zeile 888: Zeile 543:
   Kill bash(352) ? (y/n) n
   Kill bash(352) ? (y/n) n
   bash: no process killed  
   bash: no process killed  
* Mit der Option -w wartet '''killall''' so lange, bis der letzte der angegebene Prozess seine Arbeit beendet hat. Das Kommando schickt hierzu periodisch (jede Sekunde) erneut das Signal.


Mit der Option -w wartet '''killall''' so lange, bis der letzte der angegebene Prozess seine Arbeit beendet hat. Das Kommando schickt hierzu periodisch (jede Sekunde) erneut das Signal.
==  Wiederkehrende Abläufe (cron) ==
 
* Schon die Standardinstallation von Linux birgt für manchen Benutzer Überraschungen.  
==  Wiederkehrende Abläufe mit cron ==
* Da fährt man nichts ahnend sein System hoch, freut sich auf eine gute Performance und wundert sich, dass die CPU am Limit kreiselt, obwohl man doch nur seine Mails begutachtet.  
 
* Geht man der Ursache auf den Grund, findet man heraus, dass »'''nobody'''« das Kommando »find« ausführt und sämtliche Ressourcen zu verschlingen scheint.  
Schon die Standardinstallation von Linux birgt für manchen Benutzer Überraschungen.  
* Wer ist dieser »'''nobody'''«? Und wie kommt er dazu, meinen Dateibaum zu durchstöbern?
 
* Erst einmal sei der Leser beruhigt; in jenem Fall ist es unwahrscheinlich, dass sich hinter »'''nobody'''« ein arglister Eindringling verbirgt.  
Da fährt man nichts ahnend sein System hoch, freut sich auf eine gute Performance und wundert sich, dass die CPU am Limit kreiselt, obwohl man doch nur seine Mails begutachtet.  
* Hier ist vermutlich irgend ein Systemprogramm am werkeln, das irgend eine Datenbank aktualisiert.
 
* Und wer rief das Programm?  
Geht man der Ursache auf den Grund, findet man heraus, dass »'''nobody'''« das Kommando »find« ausführt und sämtliche Ressourcen zu verschlingen scheint.  
* Mit ziemlicher Sicherheit identifiziert man den '''cron''' als den Übeltäter.  
 
* Und »Übeltäter« ist für diesen Pünklichkeitsfanatiker sicher die unpassendste Bezeichnung, er verrichtet schließlich nur gewissenhaft die ihm angetragenen Aufgaben.
Wer ist dieser »'''nobody'''«? Und wie kommt er dazu, meinen Dateibaum zu durchstöbern?
* Beim '''cron''' handelt es sich um einen Dämonen, auch wenn sein Name nicht mit dem sonst üblichen »d« endet. Warum dieser Name?  
 
* Wer weiß... schieben wir es seinem Entwickler ''Paul Vixie'' in die Schuhe. Dieser '''cron''' sollte schon während des Systemstarts aktiviert werden.  
Erst einmal sei der Leser beruhigt; in jenem Fall ist es unwahrscheinlich, dass sich hinter »'''nobody'''« ein arglister Eindringling verbirgt.  
* Fortan wird er minütlich zum Leben erwachen und in seinen Terminkalendern nachschlagen, ob etwas zu erledigen ist.  
 
* Wenn nicht, versetzt er sich für eine weitere Minute in den Schlaf.
Hier ist vermutlich irgend ein Systemprogramm am werkeln, das irgend eine Datenbank aktualisiert.
 
Und wer rief das Programm?  
 
Mit ziemlicher Sicherheit identifiziert man den '''cron''' als den Übeltäter.  
 
Und »Übeltäter« ist für diesen Pünklichkeitsfanatiker sicher die unpassendste Bezeichnung, er verrichtet schließlich nur gewissenhaft die ihm angetragenen Aufgaben.
 
Beim '''cron''' handelt es sich um einen Dämonen, auch wenn sein Name nicht mit dem sonst üblichen »d« endet. Warum dieser Name?  
 
Wer weiß... schieben wir es seinem Entwickler ''Paul Vixie'' in die Schuhe. Dieser '''cron''' sollte schon während des Systemstarts aktiviert werden.  
 
Fortan wird er minütlich zum Leben erwachen und in seinen Terminkalendern nachschlagen, ob etwas zu erledigen ist.  
 
Wenn nicht, versetzt er sich für eine weitere Minute in den Schlaf.


===  Der Start des Dämonen ===
===  Der Start des Dämonen ===
 
* In den meisten Fällen sollte nach der Linuxinstallation der Dämon bereits mit dem Start des Systems aktiv werden.  
In den meisten Fällen sollte nach der Linuxinstallation der Dämon bereits mit dem Start des Systems aktiv werden.  
* Die verschiedenen Distributionen regeln das über ein Skript, das in allen Runleveln gestartet wird. Debian speichert das Skript unter »'''/etc/init.d/cron'''«, bei RedHat liegt es als »'''/etc/rc.d/init.d/cron'''« auf der Platte und SuSE hält »'''/sbin/init.d/cron'''« für das richtige Konzept.  
 
* Sollte bei Ihnen der '''cron''' nicht aktiv sein, so überprüfen Sie, ob in den jeweiligen Runlevel-Verzeichnissen ein Link auf das Skript existiert.
Die verschiedenen Distributionen regeln das über ein Skript, das in allen Runleveln gestartet wird. Debian speichert das Skript unter »'''/etc/init.d/cron'''«, bei RedHat liegt es als »'''/etc/rc.d/init.d/cron'''« auf der Platte und SuSE hält »'''/sbin/init.d/cron'''« für das richtige Konzept.  
* Mit »'''/usr/sbin/cron'''« vermag der Systemadministrator den Dämon von Hand ins Leben zu berufen, da dessen Arbeit allerdings von unschätzbarem Nutzen ist, sollten ggf. die fehlenden Links erzeugt werden.  
 
* Als Linknamen bieten sich »'''S21cron'''« für das Startskript und »'''K19cron'''« für das Stoppskript an.  
Sollte bei Ihnen der '''cron''' nicht aktiv sein, so überprüfen Sie, ob in den jeweiligen Runlevel-Verzeichnissen ein Link auf das Skript existiert.
* Wo sich die Runlevel-Verzeichnisse befinden und was es mit der Namensgebung auf sich hat, ist Thema des Abschnitts [http://booten.htm/ Bootvorgang].
 
Mit »'''/usr/sbin/cron'''« vermag der Systemadministrator den Dämon von Hand ins Leben zu berufen, da dessen Arbeit allerdings von unschätzbarem Nutzen ist, sollten ggf. die fehlenden Links erzeugt werden.  
 
Als Linknamen bieten sich »'''S21cron'''« für das Startskript und »'''K19cron'''« für das Stoppskript an.  
 
Wo sich die Runlevel-Verzeichnisse befinden und was es mit der Namensgebung auf sich hat, ist Thema des Abschnitts [http://booten.htm/ Bootvorgang].


===  Mehrere Terminkalender ===
===  Mehrere Terminkalender ===
 
* Ist der Geist erst einmal losgelassen, so schaut er als erstes in der Datei »/'''etc/crontab'''« nach, welchen Spuk er im System als nächstes zu treiben hat.  
Ist der Geist erst einmal losgelassen, so schaut er als erstes in der Datei »/'''etc/crontab'''« nach, welchen Spuk er im System als nächstes zu treiben hat.  
* Und beim weiteren Vorgehen scheiden sich die Geister...  
 
* Hier treiben die verschiedenen Distributionen allerlei eigenen »Unsinn« und kompilieren die verschiedensten Suchpfade in den Code des Dämons ein.
Und beim weiteren Vorgehen scheiden sich die Geister...  
* Entsprechend den Richtlinien des Filesystem Hierarchie Standards sollten die benutzereigenen Tabellen im Verzeichnis »'''/var/spool/cron'''« angesiedelt sein, bei Debian und RedHat findet man sie unter »/var/spool/cron/crontabs« und SuSE liegt mit »'''/var/cron/tabs'''« völlig daneben.  
 
* Die letzten Dateien, die zum üblichen Auftragsvolumen des '''cron''' gehören, sind »'''cron.hourly'''«, »'''cron.daily'''«, »'''cron.monthly'''« und »'''cron.weekly'''«, die distributionsabhängig entweder unterhalb von »'''/etc/cron.d'''« oder direkt in »'''/etc'''« (SuSE) liegen.
Hier treiben die verschiedenen Distributionen allerlei eigenen »Unsinn« und kompilieren die verschiedensten Suchpfade in den Code des Dämons ein.
* Zu bemerken ist, dass die Dateien nicht existieren müssen, da alle Aufträge für den Dämon auch in einer einzigen Datei enthalten sein könnten.  
 
* Und außerdem sind die zu überwachenden Dateien und Pfade durch Herumspielen im Quellcode beliebig anpassbar.
Entsprechend den Richtlinien des Filesystem Hierarchie Standards sollten die benutzereigenen Tabellen im Verzeichnis »'''/var/spool/cron'''« angesiedelt sein, bei Debian und RedHat findet man sie unter »/var/spool/cron/crontabs« und SuSE liegt mit »'''/var/cron/tabs'''« völlig daneben.  
 
Die letzten Dateien, die zum üblichen Auftragsvolumen des '''cron''' gehören, sind »'''cron.hourly'''«, »'''cron.daily'''«, »'''cron.monthly'''« und »'''cron.weekly'''«, die distributionsabhängig entweder unterhalb von »'''/etc/cron.d'''« oder direkt in »'''/etc'''« (SuSE) liegen.
 
Zu bemerken ist, dass die Dateien nicht existieren müssen, da alle Aufträge für den Dämon auch in einer einzigen Datei enthalten sein könnten.  
 
Und außerdem sind die zu überwachenden Dateien und Pfade durch Herumspielen im Quellcode beliebig anpassbar.


===  Der Eine darf, der Andere nicht... ===
===  Der Eine darf, der Andere nicht... ===
 
* Dem Systemadministrator steht es frei, bestimmte Benutzer von den Diensten des '''cron''' auszuschließen. Hierzu kann er die Benutzerkennzeichen in die Dateien »'''allow'''« und »'''deny'''« aufnehmen.  
Dem Systemadministrator steht es frei, bestimmte Benutzer von den Diensten des '''cron''' auszuschließen. Hierzu kann er die Benutzerkennzeichen in die Dateien »'''allow'''« und »'''deny'''« aufnehmen.  
* Jeder Benutzer, der in der '''allow'''-Datei enthalten ist (ein Benutzer je Zeile), darf eine eigene »'''crontab'''« anlegen. Im Falle einer leeren Datei »'''allow'''« kann also niemand den '''cron''' benutzen.  
 
* Existiert die »'''allow'''«-Datei nicht, kommt »'''deny'''« ins Spiel. Sie enthält genau jene Benutzer, denen der Dienst versagt wird. '''allow''' und '''deny''' sind hier nur beispielhafte Bezeichnungen für die Dateien. SuSE und Debian benennen sie tatsächlich so, im ersten Fall liegen sie im Verzeichnis »'''/var/cron'''« und bei Debian unter »'''/var/spool/cron'''«.  
Jeder Benutzer, der in der '''allow'''-Datei enthalten ist (ein Benutzer je Zeile), darf eine eigene »'''crontab'''« anlegen. Im Falle einer leeren Datei »'''allow'''« kann also niemand den '''cron''' benutzen.  
* RedHat regelt den Zugriff über die beiden Dateien »'''/etc/cron.allow'''« und »'''/etc/cron.deny'''«.
 
Existiert die »'''allow'''«-Datei nicht, kommt »'''deny'''« ins Spiel. Sie enthält genau jene Benutzer, denen der Dienst versagt wird. '''allow''' und '''deny''' sind hier nur beispielhafte Bezeichnungen für die Dateien. SuSE und Debian benennen sie tatsächlich so, im ersten Fall liegen sie im Verzeichnis »'''/var/cron'''« und bei Debian unter »'''/var/spool/cron'''«.  
 
RedHat regelt den Zugriff über die beiden Dateien »'''/etc/cron.allow'''« und »'''/etc/cron.deny'''«.


===  /etc/crontab ===
===  /etc/crontab ===
 
Wie muss nun der Inhalt einer '''crontab'''-Datei aussehen?
[[Image:Grafik7.png|right|top]]Wie muss nun der Inhalt einer '''crontab'''-Datei aussehen?
* Eine Zeile, die nicht mit dem Doppelkreuz (»'''#'''« - Kommentar) beginnt, ist entweder eine Variablenzuweisung oder eine Anweisung der Art: »Starte das Kommando zur dieser Zeit an diesem Datum«.  
 
* Jeder Zeile entspricht einem Eintrag, d.h. eine Anweisung oder Variablenzuweisung darf sich nicht über mehrere Zeilen erstrecken.  
Eine Zeile, die nicht mit dem Doppelkreuz (»'''<nowiki>#</nowiki>'''« - Kommentar) beginnt, ist entweder eine Variablenzuweisung oder eine Anweisung der Art: »Starte das Kommando zur dieser Zeit an diesem Datum«.  
* Auch ist die Zeile auf 1024 Zeichen begrenzt. Beginnt eine Anweisungszeile mit einem Minus »'''-'''«, so wird kein [http://protocol.htm/#sysl syslog]-Eintrag zur Protokollierung des Kommandostarts vorgenommen.
 
* Eine Variablenzuweisung legt Umgebungsvariablen für den '''cron''' neu fest. So lassen sich dem Dämon mit '''PATH''' alternative Pfade angeben, wo er die Kommandos zu suchen hat.  
Jeder Zeile entspricht einem Eintrag, d.h. eine Anweisung oder Variablenzuweisung darf sich nicht über mehrere Zeilen erstrecken.  
* Mit '''SHELL''' kann eine von der »'''/bin/sh'''« abweichende Shell zur Kommandoausführung benannt werden und mit '''MAILTO''' ist es möglich, die Ausgabe, die der '''cron''' per Mail an den Eigentümer der »'''crontab'''« ausliefert, einem anderen Benutzer zukommen zu lassen (oder gar zu unterdrücken »'''MAILTO='''«).
 
* Eine Anweisung besteht aus 7 Feldern (in den privaten Tabellen nur 6), wobei diese durch Leerzeichen oder Tabulatoren getrennt sind.  
Auch ist die Zeile auf 1024 Zeichen begrenzt. Beginnt eine Anweisungszeile mit einem Minus »'''-'''«, so wird kein [http://protocol.htm/#sysl syslog]-Eintrag zur Protokollierung des Kommandostarts vorgenommen.
* Die ersten 5 Felder betreffen die Angabe des Zeitpunkts, wann das Kommando zu starten ist:
 
Eine Variablenzuweisung legt Umgebungsvariablen für den '''cron''' neu fest. So lassen sich dem Dämon mit '''PATH''' alternative Pfade angeben, wo er die Kommandos zu suchen hat.  
 
Mit '''SHELL''' kann eine von der »'''/bin/sh'''« abweichende Shell zur Kommandoausführung benannt werden und mit '''MAILTO''' ist es möglich, die Ausgabe, die der '''cron''' per Mail an den Eigentümer der »'''crontab'''« ausliefert, einem anderen Benutzer zukommen zu lassen (oder gar zu unterdrücken »'''MAILTO='''«).
 
Eine Anweisung besteht aus 7 Feldern (in den privaten Tabellen nur 6), wobei diese durch Leerzeichen oder Tabulatoren getrennt sind.  
 
Die ersten 5 Felder betreffen die Angabe des Zeitpunkts, wann das Kommando zu starten ist:
 


{|class="wikitable"
{|class="wikitable"
Zeile 996: Zeile 611:
|-
|-
|}
|}
Jedes Feld erlaubt auch die Eingabe mehrerer Werte.  
* Jedes Feld erlaubt auch die Eingabe mehrerer Werte.  
 
* Die nachfolgende Tabelle fasst die verschiedenen Syntaxvarianten zusammen, die Beispiele beziehen sich auf Minuten:
Die nachfolgende Tabelle fasst die verschiedenen Syntaxvarianten zusammen, die Beispiele beziehen sich auf Minuten:
 


{|class="wikitable"
{|class="wikitable"
Zeile 1.008: Zeile 621:
|-
|-
| | '''Voller Bereich'''
| | '''Voller Bereich'''
| | <nowiki>* </nowiki>
| | *  
| | 0, 1, 2, ..., 59
| | 0, 1, 2, ..., 59
|-
|-
Zeile 1.024: Zeile 637:
|-
|-
| | '''Schrittweite'''
| | '''Schrittweite'''
| | <nowiki>*/2</nowiki>
| | */2
| | aller zwei Minuten (0, 2, ..., 58)
| | aller zwei Minuten (0, 2, ..., 58)
|-
|-
|}
|}
Tag, Wochentag und Monat können auch als englische Namen (die ersten drei Buchstaben) angegeben werden.  
* Tag, Wochentag und Monat können auch als englische Namen (die ersten drei Buchstaben) angegeben werden.  
 
* Klein- und Großschreibung werden dabei nicht unterschieden. Bereiche sind bei der Verwendung von Namen nicht erlaubt.
Klein- und Großschreibung werden dabei nicht unterschieden. Bereiche sind bei der Verwendung von Namen nicht erlaubt.
* Die Datei »'''/etc/crontab'''« enthält nun als 6. Feld den Benutzer, in dessen Auftrag das Programm auszuführen ist.  
 
* Bei allen anderen Tabellen entfällt der Eintrag, da die enthaltenen Kommandos immer mit den Rechten des Eigentümers der Datei gestartet werden.
Die Datei »'''/etc/crontab'''« enthält nun als 6. Feld den Benutzer, in dessen Auftrag das Programm auszuführen ist.  
* Das letzte Feld beinhaltet in jeder »'''crontab'''« das auszuführende Kommando.  
 
* Ein Prozentzeichen »'''%'''« kann benutzt werden, um einen Zeilenumbruch zu simulieren, alle folgenden Daten werden dem Kommando als Argumente übergeben.
Bei allen anderen Tabellen entfällt der Eintrag, da die enthaltenen Kommandos immer mit den Rechten des Eigentümers der Datei gestartet werden.
* Die Datei »'''/etc/crontab'''« könnte wie folgt ausschauen:
 
Das letzte Feld beinhaltet in jeder »'''crontab'''« das auszuführende Kommando.  
 
Ein Prozentzeichen »'''%'''« kann benutzt werden, um einen Zeilenumbruch zu simulieren, alle folgenden Daten werden dem Kommando als Argumente übergeben.
 
Die Datei »'''/etc/crontab'''« könnte wie folgt ausschauen:


  root@sonne> cat /etc/crontab
  root@sonne> cat /etc/crontab
   SHELL=/bin/sh
   SHELL=/bin/sh
   PATH<nowiki>=/usr/bin:/usr/sbin:/sbin:/bin:/usr/lib/news/bin</nowiki>
   PATH=/usr/bin:/usr/sbin:/sbin:/bin:/usr/lib/news/bin
   MAILTO=root
   MAILTO=root
   <nowiki># Langwierige Jobs sollten besser Nachts ausgeführt werden...</nowiki>
   # Langwierige Jobs sollten besser Nachts ausgeführt werden...
   <nowiki># Um 21.00 Uhr soll die Warteschlange der Faxe bearbeitet und geleert werden</nowiki>
   # Um 21.00 Uhr soll die Warteschlange der Faxe bearbeitet und geleert werden
   0 21 * * *    root  test -x /usr/sbin/faxqclean && /usr/sbin/faxqclean
   0 21 * * *    root  test -x /usr/sbin/faxqclean && /usr/sbin/faxqclean
   <nowiki># Reports über das Faxgeschehen sind um 23.25 Uhr zu generieren</nowiki>
   # Reports über das Faxgeschehen sind um 23.25 Uhr zu generieren
   25 23 * * *    root  test -e /usr/sbin/faxcron && sh /usr/sbin/faxcron | mail FaxMaster
   25 23 * * *    root  test -e /usr/sbin/faxcron && sh /usr/sbin/faxcron | mail FaxMaster
    
    
   <nowiki># check scripts in cron.hourly, cron.daily, cron.weekly and cron.monthly</nowiki>
   # check scripts in cron.hourly, cron.daily, cron.weekly and cron.monthly
   <nowiki>#</nowiki>
   #
   <nowiki># Das nächste Kommando soll aller 15 Minuten starten und nicht protokolliert werden</nowiki>
   # Das nächste Kommando soll aller 15 Minuten starten und nicht protokolliert werden
   -*/15 * * * *  root  test -x /usr/lib/cron/run-crons && /usr/lib/cron/run-crons
   -*/15 * * * *  root  test -x /usr/lib/cron/run-crons && /usr/lib/cron/run-crons
   <nowiki># 0.00 Uhr jeden Tag</nowiki>
   # 0.00 Uhr jeden Tag
   0 0  <nowiki>* * * </nowiki>    root  rm -f /var/cron/lastrun/cron.daily
   0 0  * * *     root  rm -f /var/cron/lastrun/cron.daily
   <nowiki># 0.00 Uhr jeden Sonntag</nowiki>
   # 0.00 Uhr jeden Sonntag
   0 0  <nowiki>* * 6 </nowiki>    root  rm -f /var/cron/lastrun/cron.weekly
   0 0  * * 6     root  rm -f /var/cron/lastrun/cron.weekly
   <nowiki># 0.00 Uhr jeden ersten Tag im Monat</nowiki>
   # 0.00 Uhr jeden ersten Tag im Monat
   0 0  1 * *    root  rm -f /var/cron/lastrun/cron.monthly  
   0 0  1 * *    root  rm -f /var/cron/lastrun/cron.monthly  


===  Benutzereigene crontab ===
===  Benutzereigene crontab ===
 
* Bei all der Pingelichkeit mit der Sicherheit in einem Unix-System wird sich niemand darüber wundern, dass Otto-Normalverbraucher seine '''cron'''-Jobs nicht direkt in das entsprechende Spoolverzeichnis schreiben kann.  
Bei all der Pingelichkeit mit der Sicherheit in einem Unix-System wird sich niemand darüber wundern, dass Otto-Normalverbraucher seine '''cron'''-Jobs nicht direkt in das entsprechende Spoolverzeichnis schreiben kann.  
* Aus diesem Grund steht ihm das Kommando '''crontab''' zur Verfügung.
 
* Dem Systemadministrator steht es zu, die nachfolgenden Optionen mit '''-u Benutzer''' zu koppeln und somit die Datei eines beliebigen Benutzers zu bearbeiten.  
Aus diesem Grund steht ihm das Kommando '''crontab''' zur Verfügung.
* Die simplen Optionen sind '''-l '''zur Anzeige des Inhalts seiner eigenen Tabelle und '''-r '''zum Löschen jener. Zum Editieren der Datei ist das Kommando mit der Option '''-e '''zu starten. Kommt jetzt die Ausgabe:
 
Dem Systemadministrator steht es zu, die nachfolgenden Optionen mit '''-u Benutzer''' zu koppeln und somit die Datei eines beliebigen Benutzers zu bearbeiten.  
 
Die simplen Optionen sind '''-l '''zur Anzeige des Inhalts seiner eigenen Tabelle und '''-r '''zum Löschen jener. Zum Editieren der Datei ist das Kommando mit der Option '''-e '''zu starten. Kommt jetzt die Ausgabe:


  crontab -e
  crontab -e
Zeile 1.079: Zeile 682:


...so trete man seinem Systemadministrator entgegen und frage ihn, warum man von der Benutzung des Dienstes ausgeschlossen wurde.
...so trete man seinem Systemadministrator entgegen und frage ihn, warum man von der Benutzung des Dienstes ausgeschlossen wurde.
 
* Gesetzten Falls, der Aufruf glückte, so findet man sich in einem Editor wieder.  
Gesetzten Falls, der Aufruf glückte, so findet man sich in einem Editor wieder.  
* Welcher das ist, steht in den Shellvariablen '''$VISUAL''' und '''$EDITOR''' (nur wenn erstere nicht gesetzt ist, wird die 2. ausgewertet) und kann nach persönlichen Wünschen angepasst werden.  
 
Welcher das ist, steht in den Shellvariablen '''$VISUAL''' und '''$EDITOR''' (nur wenn erstere nicht gesetzt ist, wird die 2. ausgewertet) und kann nach persönlichen Wünschen angepasst werden.  


Übrigens scheitert ein Kommandoaufruf auch, wenn die Variable nicht oder auf einen nicht installierten Editor gesetzt ist.
Übrigens scheitert ein Kommandoaufruf auch, wenn die Variable nicht oder auf einen nicht installierten Editor gesetzt ist.


'''Beispiel'''
'''Beispiel'''
 
* Einmal pro Woche (Mittwoch) sollten wir ein [http://backup.htm/ Backup] unseres Heimatverzeichnisses in Erwägung ziehen.  
Einmal pro Woche (Mittwoch) sollten wir ein [http://backup.htm/ Backup] unseres Heimatverzeichnisses in Erwägung ziehen.  
* Wir archivieren also alle Dateien und schicken das Archiv per Mail an eine Adresse. Zusätzlich soll die normale Nachricht über die erfolgte Ausführung des Kommandos unterdrückt werden.
 
Wir archivieren also alle Dateien und schicken das Archiv per Mail an eine Adresse. Zusätzlich soll die normale Nachricht über die erfolgte Ausführung des Kommandos unterdrückt werden.


  crontab -e
  crontab -e
   MAIL=
   MAIL=
   0 0 * * 3 tar czvf - /home/user | uuencode backup.tgz | mail user@outside.all -s "Backup"  
   0 0 * * 3 tar czvf - /home/user | uuencode backup.tgz | mail user@outside.all -s "Backup"  
 
* Nach dem Abspeichern der Datei meldet crontab entweder den Vollzug »'''crontab: installing new crontab'''« oder aber einen aufgetretenen Fehler.  
Nach dem Abspeichern der Datei meldet crontab entweder den Vollzug »'''crontab: installing new crontab'''« oder aber einen aufgetretenen Fehler.  
* Wir provozieren einen solchen, indem wir einen Zeilenumbruch angeben:
 
Wir provozieren einen solchen, indem wir einen Zeilenumbruch angeben:


  crontab -e
  crontab -e
   <nowiki>*/30 14-16 * * 1-5 echo "Feier</nowiki>
   */30 14-16 * * 1-5 echo "Feier
   abend"
   abend"
   Speichern der Datei
   Speichern der Datei
Zeile 1.108: Zeile 705:
   errors in crontab file, can't install.
   errors in crontab file, can't install.
   Do you want to retry the same edit?
   Do you want to retry the same edit?
 
* crontab weist auf die mögliche Fehlerursache hin (Zeile 2:bad minute).  
crontab weist auf die mögliche Fehlerursache hin (Zeile 2:bad minute).  
* Klar, dass »abend« keine gültige Minutenangabe ist. Weiterhin verweigert das Kommando das Abspeichern der Datei und bietet ein erneutes Bearbeiten an.  
 
* Durch Eingabe von »y« gelangen wir zurück zum Editor.
Klar, dass »abend« keine gültige Minutenangabe ist. Weiterhin verweigert das Kommando das Abspeichern der Datei und bietet ein erneutes Bearbeiten an.  
 
Durch Eingabe von »y« gelangen wir zurück zum Editor.


==  Job zu bestimmter Zeit starten - at ==
==  Job zu bestimmter Zeit starten - at ==
  at    [-V] [-q queue] [-f file] [-mldbv] ZEIT  
  at    [-V] [-q queue] [-f file] [-mldbv] ZEIT  
 
* Mit '''at''' lassen sich Kommandos zu einem späteren Zeitpunkt ausführen.  
Mit '''at''' lassen sich Kommandos zu einem späteren Zeitpunkt ausführen.  
* Der Zeitpunkt lässt sich in verschiedenen Formaten angeben:
 
Der Zeitpunkt lässt sich in verschiedenen Formaten angeben:
 


{|class="wikitable"
{|class="wikitable"
Zeile 1.155: Zeile 745:
|}
|}
'''at''' liest die zu startenden Kommandos von der Standardeingabe oder aus einer Datei, falls eine solche mit der Option "'''-f'''" angegeben wurde.  
'''at''' liest die zu startenden Kommandos von der Standardeingabe oder aus einer Datei, falls eine solche mit der Option "'''-f'''" angegeben wurde.  
 
* Alle Kommandos werden in eine Warteschlange eingereiht, deren Name aus einem einzelnen Buchstaben besteht. Die Voreinstellung "'''a'''" kann mit der Option "'''-q'''" überschrieben werden.  
Alle Kommandos werden in eine Warteschlange eingereiht, deren Name aus einem einzelnen Buchstaben besteht. Die Voreinstellung "'''a'''" kann mit der Option "'''-q'''" überschrieben werden.  
* Die alphabetische Reihenfolge der Queues gibt die Priorität ihrer Bearbeitung vor.
 
* Nach Beendigung eines Jobs versendet '''at''' die Ausgaben des Kommandos per Mail ('''sendmail''' muss installiert sein!) an den Auftraggeber.  
Die alphabetische Reihenfolge der Queues gibt die Priorität ihrer Bearbeitung vor.
* Für Kommandos, die keine Ausgaben erzeugen, kann mit der Option "'''-m'''" eine Mail-Benachrichtigung über den erfolgten Abschluss der Bearbeitung erzwungen werden.
 
Nach Beendigung eines Jobs versendet '''at''' die Ausgaben des Kommandos per Mail ('''sendmail''' muss installiert sein!) an den Auftraggeber.  
 
Für Kommandos, die keine Ausgaben erzeugen, kann mit der Option "'''-m'''" eine Mail-Benachrichtigung über den erfolgten Abschluss der Bearbeitung erzwungen werden.


  at teatime tomorrow
  at teatime tomorrow
Zeile 1.176: Zeile 762:


===  Start des Dämonen ===
===  Start des Dämonen ===
 
* Für die Bearbeitung der Jobs ist der at-Dämon '''atd''' verantwortlich, der bereits während des Systemstarts aktiviert werden sollte. Mit Hilfe des Kommandos '''ps''' sollte ein Zeichen des Geistes zu erhalten sein:
Für die Bearbeitung der Jobs ist der at-Dämon '''atd''' verantwortlich, der bereits während des Systemstarts aktiviert werden sollte. Mit Hilfe des Kommandos '''ps''' sollte ein Zeichen des Geistes zu erhalten sein:


  ps ax | grep atd
  ps ax | grep atd
Zeile 1.184: Zeile 769:
   4316 ?        S      0:00 /usr/sbin/rpc.kstatd
   4316 ?        S      0:00 /usr/sbin/rpc.kstatd
   1967 pts/8    S      0:00 grep atd  
   1967 pts/8    S      0:00 grep atd  
 
* Fehlt eine den Dämonen betreffende Zeile, kann dieser von Hand gestartet werden.  
Fehlt eine den Dämonen betreffende Zeile, kann dieser von Hand gestartet werden.  
* Die interessanten Optionen sind hierbei '''-l Auslastungsfaktor '''und '''-b Sekunden'''. Der '''atd''' ist so ausgelegt, dass er einen Auftrag nur zur vereinbarten Zeit startet, wenn die Systemauslastung einen bestimmten Wert (0.8) unterschritten hat.  
 
* Ist das System zum Zeitpunkt zu beschäftigt, stellt der '''atd''' den Auftrag solange zurück, bis der Lastwert unter die Schranke gefallen ist.  
Die interessanten Optionen sind hierbei '''-l Auslastungsfaktor '''und '''-b Sekunden'''. Der '''atd''' ist so ausgelegt, dass er einen Auftrag nur zur vereinbarten Zeit startet, wenn die Systemauslastung einen bestimmten Wert (0.8) unterschritten hat.  
* Mit ersterer Option kann ein anderer als der voreingestellte Wert vereinbart werden, dies ist bei Mehrprozessorsystemen zu empfehlen.  
 
* Die momentane Auslastung ermittelt der Dämon anhand der Datei »/'''proc/loadavg'''«. Mit der zweiten genannten Option kann das Zeitintervall variiert werden, in dem der '''atd''' die Auftragswarteschlangen nach fälligen Jobs durchsucht. Voreinstellung ist 60 Sekunden.
Ist das System zum Zeitpunkt zu beschäftigt, stellt der '''atd''' den Auftrag solange zurück, bis der Lastwert unter die Schranke gefallen ist.  
* Um den Dämonen schließlich nicht immer von Hand starten zu müssen, sollten Sie einen Link in allen [http://booten.htm/#runlevel Runleveln] auf ein entsprechendes Skript anlegen.  
 
* Bei den meisten Distributionen sollte das Skript »'''at'''« heißen und im Verzeichnis unterhalb der Runlevel liegen.* Debian und RedHat: Verzeichnis '''/etc/rc.d/init.d'''
Mit ersterer Option kann ein anderer als der voreingestellte Wert vereinbart werden, dies ist bei Mehrprozessorsystemen zu empfehlen.  
 
Die momentane Auslastung ermittelt der Dämon anhand der Datei »/'''proc/loadavg'''«. Mit der zweiten genannten Option kann das Zeitintervall variiert werden, in dem der '''atd''' die Auftragswarteschlangen nach fälligen Jobs durchsucht. Voreinstellung ist 60 Sekunden.
 
Um den Dämonen schließlich nicht immer von Hand starten zu müssen, sollten Sie einen Link in allen [http://booten.htm/#runlevel Runleveln] auf ein entsprechendes Skript anlegen.  
 
Bei den meisten Distributionen sollte das Skript »'''at'''« heißen und im Verzeichnis unterhalb der Runlevel liegen.* Debian und RedHat: Verzeichnis '''/etc/rc.d/init.d'''
 
 


===  Zugangskontrolle ===
===  Zugangskontrolle ===
 
* Der Zugang zum Dienst kann vom Systemverwalter eingeschränkt werden, in dem er die Benutzerkennzeichen in einer der Dateien »'''/etc/at.allow'''« oder »'''/etc/at.deny'''« aufnimmt.  
Der Zugang zum Dienst kann vom Systemverwalter eingeschränkt werden, in dem er die Benutzerkennzeichen in einer der Dateien »'''/etc/at.allow'''« oder »'''/etc/at.deny'''« aufnimmt.  
* Dabei wird die zweite Datei nur ausgewertet, falls erstere fehlt. In »'''at.allow'''« trägt Root genau die Benutzer ein, die den Dienst beanspruchen dürfen.  
 
* Nichterwähnte Benutzer werden somit ausgeschlossen.  
Dabei wird die zweite Datei nur ausgewertet, falls erstere fehlt. In »'''at.allow'''« trägt Root genau die Benutzer ein, die den Dienst beanspruchen dürfen.  
* Sollen jedoch nur einige wenige Personen ausgenommen werden, so ist es einfacher, diese in der Datei »'''at.deny'''« einzutragen.  
 
* Alle dort nicht benannten Benutzer haben dann Zugriff auf '''at'''. Existiert keine Datei, ist der Dienst für jeden nutzbar.
Nichterwähnte Benutzer werden somit ausgeschlossen.  
 
Sollen jedoch nur einige wenige Personen ausgenommen werden, so ist es einfacher, diese in der Datei »'''at.deny'''« einzutragen.  
 
Alle dort nicht benannten Benutzer haben dann Zugriff auf '''at'''. Existiert keine Datei, ist der Dienst für jeden nutzbar.


===  Jobliste anzeigen (atq) ===
===  Jobliste anzeigen (atq) ===
  atq    [-V] [-q queue]
  atq    [-V] [-q queue]
 
* Der Inhalt der Warteschlange ausstehender at-Jobs wird angezeigt.  
Der Inhalt der Warteschlange ausstehender at-Jobs wird angezeigt.  
* Sollen nur die Aufträge einer bestimmten Queue betrachtet werden, muss mit der Option "'''-q'''" der Name der Warteschlange angegeben werden.
 
Sollen nur die Aufträge einer bestimmten Queue betrachtet werden, muss mit der Option "'''-q'''" der Name der Warteschlange angegeben werden.


  atq
  atq
Zeile 1.227: Zeile 795:
   5 2001-01-02 09:12 a
   5 2001-01-02 09:12 a
   6 2000-06-11 10:16 b  
   6 2000-06-11 10:16 b  
 
* Die Informationen sind Jobnummer, Zeitpunkt des Auftrags und Name der Warteschlange. Eine analoge Ausgabe liefert '''at -l'''.
Die Informationen sind Jobnummer, Zeitpunkt des Auftrags und Name der Warteschlange. Eine analoge Ausgabe liefert '''at -l'''.


===  Job abbrechen (atrm) ===
===  Job abbrechen (atrm) ===
  atrm    [-V] job [job...]  
  atrm    [-V] job [job...]  
 
* Aufträge können anhand ihrer Jobnummer gelöscht werden:
Aufträge können anhand ihrer Jobnummer gelöscht werden:


  atrm 3 4 5 6
  atrm 3 4 5 6
Zeile 1.243: Zeile 808:


==  Job bei Inaktivität mit batch starten ==
==  Job bei Inaktivität mit batch starten ==
  batch    [-V] [-q queue] [-f file] [-mv] [ZEIT]  
  batch    [-V] [-q queue] [-f file] [-mv] [ZEIT]  


'''Batch''' arbeitet analog zum Kommando [[#at|at]] mit dem einzigen Unterschied, dass '''batch''' den Start des Kommandos soweit zurückstellt, bis die Auslastung des Systems eine gewisse Grenze (load average < 0.8) unterschritten hat.
'''Batch''' arbeitet analog zum Kommando [[#at|at]] mit dem einzigen Unterschied, dass '''batch''' den Start des Kommandos soweit zurückstellt, bis die Auslastung des Systems eine gewisse Grenze ([[load average]] < 0.8) unterschritten hat.
 
* Das Kommando wird man bspw. dazu benutzen, eine langwierige und ressourcenintensive Berechnung erst nach Feierabend zu starten (wenn normalerweise die Rechner nicht mehr benötigt werden).  
Das Kommando wird man bspw. dazu benutzen, eine langwierige und ressourcenintensive Berechnung erst nach Feierabend zu starten (wenn normalerweise die Rechner nicht mehr benötigt werden).  
* Sollte aber dennoch ein Kollege Überstunden scheffeln (das soll es wohl geben;-) und den Rechner benutzen, wird die Bearbeitung des Jobs zurückgestellt...
 
* Verwendung und Optionen des Kommandos sind exakt wie bei '''at''' beschrieben.
Sollte aber dennoch ein Kollege Überstunden scheffeln (das soll es wohl geben;-) und den Rechner benutzen, wird die Bearbeitung des Jobs zurückgestellt...
 
Verwendung und Optionen des Kommandos sind exakt wie bei '''at''' beschrieben.
 


[[Category:Entwurf]]
[[Kategorie:Linux/Prozesse]]
[[Category:Linux:Prozesse]]

Aktuelle Version vom 28. Mai 2023, 22:00 Uhr

Prozesse kontrollieren

Prozessstatus (ps)

(process status) zeigt die Prozesse mit ihrem Status an 

ps [Optionen]

Optionen

a zeigt alle aktive Prozesse
c zeigt den Namen des Kommandos
l langes Format
m zeigt Speichernutzung
r zeigt nur die laufenden Prozesse
u zeigt die Besitzer und Startzeit der Prozesse
w breite Ausgabe, lange Zeilen werden nicht abgeschnitten
x zeigt Prozesse, die von keinem Terminal kontrolliert werden
S addiert die Prozessorzeit der Kindprozesse zu den Eltern
tTTY > kontrolliert werden

Bedeutung der Spalten

COMMAND der Name des Kommandos; Prozesse, die komplett in den Swapbereich ausgelagert sind, werden in Klammern angezeigt
TIME die verbrauchte Rechenzeit (Summe User- und Kernelmodus) im Format MM:SS
TTY die Nummer des kontrollierenden Terminals
UID die Benutzer-ID des Eigentümers dieses Prozesses
PID die Prozessnummer dieses Prozesses
PPID die Prozessnummer des Elternprozesses
PRI Priorität
TPGID die Prozessgruppe, der z. Z. das kontrollierende Terminal zu diesem Prozess gehört
SID die Session-ID des Prozesses (ID der Login-Shell)
STAT ist der Status des Prozesses; folgende Symbole sind möglich:
R lauffähig
S schlafend
W nicht mehr im Arbeitsspeicher

Prozessbaum (pstree)

Das Kommando stellt die aktiven Prozesse in einer Baumstruktur dar, welche die Prozessvererbung symbolisiert. 

pstree     [-a] [-c] [-h|-Hpid] [-l] [-n] [-p] [-u] [-G|-U] [pid|user]

Beispiel

pstree
 init-+-actived
      |-atd
      |-cron
      |-gpm
      |-httpd---httpd
      |-in.identd---in.identd---5*[in.identd]
      |-inetd
      |-kflushd
      |-klogd
      |-kpiod
      |-kswapd
      |-kupdate
      |-lockd---rpciod
      |-2*[login---bash---ssh]
      |-login---sh
      |-2*[mingetty]
      |-nscd---nscd---5*[nscd]
      |-portmap
      |-syslogd
  • Das Beispiel verdeutlicht, dass init der Elternprozess aller Prozesse ist. pstree versucht per Voreinstellung identische Prozesse in der Darstellung zusammen zu fassen, so bedeutet 2*[mingetty], dass 2 Prozesse das Kommando mingetty ausführen.
  • Mit der Option -c wird diese Zusammenfassung abgeschaltet:
...
 |-in.identd---in.identd-+-in.identd
     |                       |-in.identd
     |                       |-in.identd
     |                       |-in.identd
     |                       `-in.identd
...

Taskmanager (top)

top listet Prozesse, sortiert nach ihrem Anteil an CPU-Zeit, auf. 

top [-] [d delay] [q] [c] [S] [s] [i] [n] [b]
  • Nach Voreinstellung wird diese Liste aller 5 Sekunden aktualisiert, mit der Option -d Zeit kann ein anderes Intervall eingestellt werden.
  • Eine Option -q lässt das Kommando die Liste so oft wie möglich aktualisieren, mit -n Anzahl kann die Anzahl der Refreshes eingeschränkt werden. Anschließend wird top seine Arbeit beenden.
  • Als Überschrift zeigt top die Uptime, die Anzahl der Prozesse, eingeteilt nach ihrem Status, die Auslastung von CPU, Speicher und Swap an.
  • Es folgen die Informationen zu den einzelnen Prozessen (die Auflistung enthält nur die Beschreibung der Standard-Informationen)
PID Prozessnummer
USER Nutzer, mit dessen Rechten der Prozess ausgeführt wird
PRI Priorität, mit der der Prozess läuft
NI Der nice-Faktor, mit dem der Prozess läuft
SIZE Speichergröße des Prozesses inklusive Stack
RSS Verbrauch an physischen Speicher
SHARE Größe des Speichers, der auch von anderen Prozessen genutzt wird
STAT Status des Prozesses
LIB Speicherverbrauch der Bibliotheken des Prozesses (bei ELF-Prozessen wird diese Größe mit bei SHARE aufgeschlagen)
%CPU Verbrauchte CPU-Zeit im letzten Refresh-Intervall (in Prozent)
%MEM Speicherverbrauch (in Prozent)
COMMAND Kommando, das der Prozess ausführt.

Interaktive Arbeit mit top

  • Während das Kommando in periodischen Abständen das Terminal mit neuen Informationen überschwemmt, lassen sich verschiedenste Aktionen vornehmen.
  • Folgende Eingaben (Auswahl) bewirken folgende Reaktion:
[Leertaste] Sofortige Aktualisierung der Anzeige
f Hierüber kann die Anzeige der Informationen eingestellt werden.
  • Es erscheint eine Auflistung aller Informationsfelder, wobei ausgewählte Felder mit einem Stern * gekennzeichnet sind.
  • Vor jedem Feld steht ein Bezeichner (Buchstabe), durch dessen Eingabe die Auswahl umgeschalten wird. Rückkehr zur Ausgabe von top durch [Enter].
h bzw. ? Anzeige einer Kurzhilfe zu den verschiedenen Kommandos
k Zum Senden von Signalen an einen Prozess. Es wird zur Angabe der PID und des zu sendenden Signals aufgefordert.
n bzw. # Zum Ändern der Anzahl angezeigter Prozesse. Man wird zur Eingabe der neuen Anzeige aufgefordert.
o Ändern der Reihenfolge der Darstellung der Felder.
  • In der oberen Zeile der erscheinenden Ausgabe ist die Reihenfolge symbolisch dargestellt, wobei ein gewähltes Feld durch einen Großbuchstaben markiert ist.
  • Durch Eingabe des entsprechenden Feldbezeichners als Kleinbuchstabe, wird der Eintrag in der Liste "nach hinten" befördert; mittels des Großbuchstaben nach vorn. Rückkehr zur Ausgabe von top durch [Enter]

Current Field Order: bAcDgHIjklMnoTPrqsuzVYEFWX 

Upper case characters move a field to the left, lower case to the right

* A: PID        = Process Id
  B: PPID       = Parent Process Id
  C: UID        = User Id
* D: USER       = User Name
* E: %CPU       = CPU Usage
* F: %MEM       = Memory Usage
  G: TTY        = Controlling tty
* H: PRI        = Priority
* I: NI         = Nice Value
...
r Ändern der Priorität eines Prozesses
q Beendet top

nice - Prozess mit anderer Priorität

nice [OPTION]... [COMMAND [ARG]...]
  • Ein zu startendes Kommando kann durch nice eine andere als die voreingestellte Priorität gegeben werden. D.h. im Vergleich zur "normalen Priorität" erhält ein solcher Prozess prozentual weniger/mehr Rechenzeit zugeteilt.
  • Ein Wert von -20 bedeutet dabei die höchste Priorität; ein Wert von 20 die geringste.
  • Ein normaler Nutzer darf die Priorität eines Prozesses nur verringern (also den Wert erhöhen), nur Root kann diese erhöhen (den Wert verringern).

Beispiel

nice -n 19 gcc bigprogram.c
 root@sonne> nice -n -10 inetd
  • Mit renice kann die Priorität eines laufenden Prozesses beeinflusst werden.

renice - Prozesspriorität ändern

renice priority [[-p] pid ...] [[-g] pgrp ...] [[-u] user ...]
  • Prozessen kann mittels renice nachträglich eine andere Priorität zugeteilt werden. Wie auch bei nice gilt, dass einzig Root die Priorität erhöhen darf.

Beispiel 

renice +10 23258
 23258: Alte Priorität: 0, neue Priorität: 10
 renice -10 23258
 renice: 23258: setpriority: Keine Berechtigung
  • Das Kommando erlaubt das gleichzeitige Verändern der Prioritäten mehrerer Prozesse. Mögliche Angaben sind: Mehrere Process-IDs, -g GID Die Gruppennummer von Prozessen, -u Nutzer Der Besitzer der Prozesse

nohup - Prozess abnabeln

nohup    COMMAND [ARG]...
  • Das von nohup gestartete Kommando läuft unabhängig von der aktiven Shell. D.h. ein so gestartetes Kommando arbeitet auch nach dem Beenden der Sitzung (logout) weiter.
  • Die Ausgaben von nohup werden ggf. in eine Datei nohup.out umgeleitet. Kann diese im aktuellen Verzeichnis nicht erzeugt werden, wird sie im Heimatverzeichnis angelegt.
  • Scheitert auch dies, beendet nohup seine Tätigkeit.
  • Ein über nohup gestartetes Kommando erhält eine um 5 erhöhte Priorität.
bash
 ./sleepproc&
 [1] 776
 exit
 ps eax | grep spleepproc
 
 bash
 nohup ./sleepproc&
 [1] 786
 exit
 ps eax | grep spleepproc
 786 ? S N 0:00 sh ./sleepproc...

Anmerkung

  • Im Beispiel wird in einer Subshell ein Skript "sleepproc" gestartet und die Shell beendet.
  • Wie zu erwarten war, wurde der in der Shell gestartete Prozess mit dem Ende der Shell beendet.
  • In einem zweiten Schritt wird das Skript "sleepproc" unabhängig von der Shell gestartet... es existiert auch nach Beendigung der Shell weiter.

2.7 Konfiguration neu laden Ein typisches Beispiel für einen Systemdienst ist der Apache-HTTP-Server. Dies besteht aus einer Reihe von Hintergrundprozessen (Daemons), die beim Starten des Computers gestartet und beim Herunterfahren gestoppt werden. Der Betrieb des Dienstes wird durch eine Reihe von Konfigurationsdateien geregelt, die beim Starten des Dienstes gelesen werden. Änderungen an der Konfiguration eines Dienstes werden nicht unbedingt sofort wirksam: Möglicherweise muss ein SIGHUP gesendet oder die entsprechenden Prozesse beendet und anschließend neu gestartet werden. Zum Zeitpunkt des Schreibens (Januar 2011) sind zwei Mechanismen für die Verwaltung von Systemdiensten gebräuchlich: Init-Skripte im System V-Stil und Upstart. Die meisten der wichtigsten GNU / Linux-Distributionen werden derzeit von der ersteren auf die letztere migriert.

Bestimmen Sie den Namen des Dienstes

  • Jeder Dienst hat einen Namen, mit dem er identifiziert wird. Dies ist nicht unbedingt derselbe wie der Name des Pakets, von dem es installiert wurde, oder eines der Hintergrundprozesse, die es möglicherweise erzeugt. Unterschiedliche Distributionen können unterschiedliche Namen für denselben Dienst auswählen.
  • In der folgenden Tabelle sind die Namen aufgeführt, die Debian (Lenny), Ubuntu (Lucid), CentOS (5.5) und SUSE (11.3) für einige der Dienste verwenden, auf die Sie am wahrscheinlichsten stoßen:
Service Debian Ubuntu CentOS SUSE
Apache apache2 apache2 httpd apache2
BIND bind9 bind9 named named
cron cron cron crond cron
CUPS cups cups cups cups
DHCP dhcp3-server dhcp3-server dhcpd dhcpd
(X)inetd openbsd-inetd openbsd-inetd xinetd xinetd
MySQL mysql mysql mysqld mysql
NFS nfs-kernel-server nfs-kernel-server nfs nfs
NTP ntp ntp ntpd ntp
PostgreSQL postgresql-8.3 postgresql-8.4 postgresql postgresql
SSH ssh ssh sshd sshd
(r)syslog rsyslog rsyslog syslog syslog
  • Wenn Sie den Namen des Pakets kennen, das den Dienst bereitstellt, können Sie den Dienstnamen finden, indem Sie die Dateien in diesem Paket auflisten und nach Dateien mit einem Pfadnamen suchen, der mit /etc/init.d/, /etc/rc.d beginnt /init.d/ oder / etc / init /.
  • Auf Debian-basierten Systemen kann dies mit dpkg erfolgen, zum Beispiel:
dpkg --listfiles openssh-server | grep "/init"
  • and on Red Hat-based systems using rpm:
rpm -ql openssh-server-4.3p2 | grep "/init"

Beachten Sie, dass das zur Installation des Dienstes verwendete Paket der obersten Ebene möglicherweise nicht das Steuerungsskript enthält, das möglicherweise von einer Abhängigkeit bereitgestellt wird. '

  • Wenn Sie den Paketnamen nicht kennen, können Sie versuchen, in /etc/init.d und / etc / init nach einem wahrscheinlich aussehenden Dateinamen zu suchen.

Überprüfen Sie optional die neue Konfiguration

  • Einige Dienste bieten eine Möglichkeit, die Konfiguration vor dem Laden zu überprüfen. Dies ist sehr wünschenswert, wenn ein geschäftskritischer Server ausgeführt wird. Wenn beim Laden ein Fehler auftritt, bleibt möglicherweise kein Dienst verfügbar, bis dieser behoben ist.
  • Die Methode zum Anfordern einer Validierung hängt von der jeweiligen Software ab, sofern diese überhaupt verfügbar ist. Für Apache auf Debian-basierten Systemen können Sie den Befehl apache2ctl verwenden:
apache2ctl -t

Forcibly reload the configuration

  • If the service command is available then use it to forcibly reload the configuration. For example, if you have determined that the service name is apache2:
service apache2 force-reload
  • Otherwise, invoke the init.d script directly:
/etc/init.d/apache2 force-reload
  • The meaning of force-reload is that the configuration should be reloaded without restarting the service if possible, but with a restart if necessary. It is preferable to reload or restart because:* reload will fail if it cannot be achieved without restarting the service.
  • restart should work for any well-behaved service, but it causes a short period of downtime which may be unnecessary.

Troubleshooting

The service cannot be stopped
  • If force-reload equates to restart then the control script will need to kill any running processes before starting new ones. Sometimes this fails, in which case you will need to identify and kill the running processes yourself.
  • Most likely the control script will have attempted a graceful termination using SIGTERM. It is worth trying that again, in case the script did not send the signal for some reason:
killall apache2
  • Be patient waiting for processes to exit, because some (such as Squid) can take tens of seconds. However if it is clear that SIGTERM has not worked then you can issue a SIGKILL with a clear conscience:
killall -KILL apache2
The service does not restart
  • This probably indicates an error in the configuration file. Alternative possibilities include:* failure to stop the service, or
  • leaving a socket in the TIME_WAIT state.
  • A well-written init script should check that a process has died after sending it a SIGTERM, but some do not. If the service listens on a specific port number (as most do) or needs to exclusively lock files then failure to terminate the old instance will prevent a new instance from starting.
  • Even if the previous instance has stopped, if it has left a server socket in the TIME_WAIT state then it may still prevent a new instance from starting for a short period (typically 2 minutes on Linux).
  • The condition occurs when the server terminates an active connection (gracefully or otherwise). Servers can be written to disregard TIME_WAIT, but not without risk. Some do this, some do not.

Alternatives

Reboot the machine
  • It should rarely be necessary to reboot a machine running GNU/Linux, and it certainly isn't necessary to perform the task described here. However there is one advantage to rebooting after a configuration change: it provides assurance that the changes you have made are persistent, and will not break unexpectedly when a reboot is eventually needed.
Signal the process directly
  • If a daemon supports reloaded without restarting then the conventional method for signalling this is to send a SIGHUP, for example:
kill -HUP 29964
  • Do not assume that SIGHUP necessarily has this meaning: in principle it could do anything. You should also exercise caution if there are several copies of the server process running. For example, sending SIGHUP to all copies of sshd would cause one of them to reload the configuration file and the others to terminate the active connections they were handling.

Interprozesskommunikation

  • Signale sind eine Möglichkeit zur Interprozesskommunikation. Vom Kernel verwendet, dienen sie dazu, Prozesse über bestimmte Ereignisse zu informieren; der Nutzer bedient sich ihrer, um hängen gebliebene Prozesse abzubrechen oder diese anzuweisen, ihre Konfigurationsdateien neu einzulesen.
  • Die Nutzersignale unterliegen bestimmten Restriktionen, sie dürfen nur an dem Nutzer zugeordnete Prozesse versandt werden. Nicht einmal root hat dem init-Prozess etwas zu sagen.
Signal Nummer Aktion
SIGHUP 1 Terminal-Hangup, bei Dämonen verwendet, um ein erneutes Einlesen der Konfigurationsdateien zu erzwingen
SIGINT 2 Tastatur-Interrupt
SIGQUIT 3 Ende von der Tastatur
SIGILL 4 Illegaler Befehl
SIGABRT 5 Abbruch-Signal von abort(3)
SIGFPE 8 Fließkommafehler (z. B. Division durch Null)
SIGKILL 9 Unbedingte Beendigung eines Prozesses
SIGSEGV 11 Speicherzugrifffehler
SIGPIPE 13 Schreiben in eine Pipe, ohne dass ein Prozess daraus liest
SIGTERM 15 Prozess soll sich beenden (default von kill)
SIGCHLD 17 Ende eines Kindprozesses
SIGCONT 18 Prozess fortsetzen
SIGSTOP 19 Prozess anhalten
SIGSTP 20 Ausgabe wurde angehalten
SIGUSR1 30 Nutzerdefiniertes Signal
  • Die genaue Zuordnung zwischen symbolischem Signal und Nummer ist in Linux in der Datei
/usr/include/linux/asm/signal.h
  • zu finden.
  • Zum manuellen Versenden von Signalen dienen die beiden Kommandos kill und killall. kill erwartet im Argument die ID des Prozesses, während killall den Namen des Programms verlangt.
  • Beide Kommandos verstehen die Signalangabe in numerischer (1 für SIGHUP,..., 9 für SIGKILL,...) als auch in symbolischer (HUP für SIGHUP,..., KILL für SIGKILL,...) Form.
  • Als Beispiel nehmen wir an, der "Netscape" reagiere nicht mehr (was leider keine hypothetische Annahme darstellt). Also werden wir den entsprechenden Prozess per Hand beenden:
  1. mittels killall auf die höfliche Tour
killall -15 netscape

# reagiert Netscape immer noch nicht, dann auf die harte Tour
killall -KILL netscape

# mittels kill
ps ax | grep netscape    
887 tty1     S      2:12 /opt/netscape/netscape
kill -9 887

Prozesse beenden mit kill

kill·[-s Signal]·[-p]·[-a]·[-l·[Signalnummer]]· Prozess-ID ...
  • beendet außer Kontrolle geratene („aufgehängte“) Prozesse und sendet Signale an Prozesse.
  • Das Signal kann mit Namen oder Nummer angegeben werden. Ist kein Signal angegeben, wird SIGTERM (15) gesendet.
  • Der Prozess wird kann durch seine Prozessnummer oder seinen Namen angegeben
  • Signale können ohne Root-Privilegien nur an die eigenen Prozesse gesendet werden.
  • Prozesse reagieren unterschiedlich auf diese Signale:# Wenn das Anwendungsprogramm eine Funktion zur Behandlung eines Signals bereitstellt kann dieses Signal abgefangen werden. Signale können damit zur asynchronen Fehler- bzw. Ausnahmebehandlung sowie zu einer primitiven Prozesskommunikation genutzt werden.
  1. Das Signal kann ignoriert werden. Das ist der Regelfall für alle Signale die nicht abgefangen werden.
  2. Die Signale SIGKILL und SIGSTOP können nicht abgefangen werden, sie werden direkt vom Kernel behandelt. Mit SIGKILL (9) wird der Prozess sofort beendet.

Optionen

-s Signal sendet das Signal anstelle von SIGTERM (15)
-a veranlasst kill auch Prozesse anderer Benutzer einzubeziehen
-l gibt eine Namensliste aller Signale aus; eine Signalnummer als Argument wird in den entsprechenden Signalnamen übersetzt

killall - Prozessen Signale senden

  • killall [-egiqvw] [-signal] name ...
  • Der wesentlichste Unterschied zum Kommando kill ist die Spezifizierung der Prozesse über den Namen der Kommandos, die sie ausführen oder mittels ihrer Gruppennummer (-g GID).

killall sendet allen Prozessen Signale, die das Kommando ausführen, mit der Option -i kann aber eine nochmalige Rückfrage vor dem tatsächlichen Senden erzwungen werden: 

killall -i -15 bash
 Kill bash(280) ? (y/n) n
 Kill bash(350) ? (y/n) n
 Kill bash(351) ? (y/n) n
 Kill bash(352) ? (y/n) n
 bash: no process killed
  • Mit der Option -w wartet killall so lange, bis der letzte der angegebene Prozess seine Arbeit beendet hat. Das Kommando schickt hierzu periodisch (jede Sekunde) erneut das Signal.

Wiederkehrende Abläufe (cron)

  • Schon die Standardinstallation von Linux birgt für manchen Benutzer Überraschungen.
  • Da fährt man nichts ahnend sein System hoch, freut sich auf eine gute Performance und wundert sich, dass die CPU am Limit kreiselt, obwohl man doch nur seine Mails begutachtet.
  • Geht man der Ursache auf den Grund, findet man heraus, dass »nobody« das Kommando »find« ausführt und sämtliche Ressourcen zu verschlingen scheint.
  • Wer ist dieser »nobody«? Und wie kommt er dazu, meinen Dateibaum zu durchstöbern?
  • Erst einmal sei der Leser beruhigt; in jenem Fall ist es unwahrscheinlich, dass sich hinter »nobody« ein arglister Eindringling verbirgt.
  • Hier ist vermutlich irgend ein Systemprogramm am werkeln, das irgend eine Datenbank aktualisiert.
  • Und wer rief das Programm?
  • Mit ziemlicher Sicherheit identifiziert man den cron als den Übeltäter.
  • Und »Übeltäter« ist für diesen Pünklichkeitsfanatiker sicher die unpassendste Bezeichnung, er verrichtet schließlich nur gewissenhaft die ihm angetragenen Aufgaben.
  • Beim cron handelt es sich um einen Dämonen, auch wenn sein Name nicht mit dem sonst üblichen »d« endet. Warum dieser Name?
  • Wer weiß... schieben wir es seinem Entwickler Paul Vixie in die Schuhe. Dieser cron sollte schon während des Systemstarts aktiviert werden.
  • Fortan wird er minütlich zum Leben erwachen und in seinen Terminkalendern nachschlagen, ob etwas zu erledigen ist.
  • Wenn nicht, versetzt er sich für eine weitere Minute in den Schlaf.

Der Start des Dämonen

  • In den meisten Fällen sollte nach der Linuxinstallation der Dämon bereits mit dem Start des Systems aktiv werden.
  • Die verschiedenen Distributionen regeln das über ein Skript, das in allen Runleveln gestartet wird. Debian speichert das Skript unter »/etc/init.d/cron«, bei RedHat liegt es als »/etc/rc.d/init.d/cron« auf der Platte und SuSE hält »/sbin/init.d/cron« für das richtige Konzept.
  • Sollte bei Ihnen der cron nicht aktiv sein, so überprüfen Sie, ob in den jeweiligen Runlevel-Verzeichnissen ein Link auf das Skript existiert.
  • Mit »/usr/sbin/cron« vermag der Systemadministrator den Dämon von Hand ins Leben zu berufen, da dessen Arbeit allerdings von unschätzbarem Nutzen ist, sollten ggf. die fehlenden Links erzeugt werden.
  • Als Linknamen bieten sich »S21cron« für das Startskript und »K19cron« für das Stoppskript an.
  • Wo sich die Runlevel-Verzeichnisse befinden und was es mit der Namensgebung auf sich hat, ist Thema des Abschnitts Bootvorgang.

Mehrere Terminkalender

  • Ist der Geist erst einmal losgelassen, so schaut er als erstes in der Datei »/etc/crontab« nach, welchen Spuk er im System als nächstes zu treiben hat.
  • Und beim weiteren Vorgehen scheiden sich die Geister...
  • Hier treiben die verschiedenen Distributionen allerlei eigenen »Unsinn« und kompilieren die verschiedensten Suchpfade in den Code des Dämons ein.
  • Entsprechend den Richtlinien des Filesystem Hierarchie Standards sollten die benutzereigenen Tabellen im Verzeichnis »/var/spool/cron« angesiedelt sein, bei Debian und RedHat findet man sie unter »/var/spool/cron/crontabs« und SuSE liegt mit »/var/cron/tabs« völlig daneben.
  • Die letzten Dateien, die zum üblichen Auftragsvolumen des cron gehören, sind »cron.hourly«, »cron.daily«, »cron.monthly« und »cron.weekly«, die distributionsabhängig entweder unterhalb von »/etc/cron.d« oder direkt in »/etc« (SuSE) liegen.
  • Zu bemerken ist, dass die Dateien nicht existieren müssen, da alle Aufträge für den Dämon auch in einer einzigen Datei enthalten sein könnten.
  • Und außerdem sind die zu überwachenden Dateien und Pfade durch Herumspielen im Quellcode beliebig anpassbar.

Der Eine darf, der Andere nicht...

  • Dem Systemadministrator steht es frei, bestimmte Benutzer von den Diensten des cron auszuschließen. Hierzu kann er die Benutzerkennzeichen in die Dateien »allow« und »deny« aufnehmen.
  • Jeder Benutzer, der in der allow-Datei enthalten ist (ein Benutzer je Zeile), darf eine eigene »crontab« anlegen. Im Falle einer leeren Datei »allow« kann also niemand den cron benutzen.
  • Existiert die »allow«-Datei nicht, kommt »deny« ins Spiel. Sie enthält genau jene Benutzer, denen der Dienst versagt wird. allow und deny sind hier nur beispielhafte Bezeichnungen für die Dateien. SuSE und Debian benennen sie tatsächlich so, im ersten Fall liegen sie im Verzeichnis »/var/cron« und bei Debian unter »/var/spool/cron«.
  • RedHat regelt den Zugriff über die beiden Dateien »/etc/cron.allow« und »/etc/cron.deny«.

/etc/crontab

Wie muss nun der Inhalt einer crontab-Datei aussehen?

  • Eine Zeile, die nicht mit dem Doppelkreuz (»#« - Kommentar) beginnt, ist entweder eine Variablenzuweisung oder eine Anweisung der Art: »Starte das Kommando zur dieser Zeit an diesem Datum«.
  • Jeder Zeile entspricht einem Eintrag, d.h. eine Anweisung oder Variablenzuweisung darf sich nicht über mehrere Zeilen erstrecken.
  • Auch ist die Zeile auf 1024 Zeichen begrenzt. Beginnt eine Anweisungszeile mit einem Minus »-«, so wird kein syslog-Eintrag zur Protokollierung des Kommandostarts vorgenommen.
  • Eine Variablenzuweisung legt Umgebungsvariablen für den cron neu fest. So lassen sich dem Dämon mit PATH alternative Pfade angeben, wo er die Kommandos zu suchen hat.
  • Mit SHELL kann eine von der »/bin/sh« abweichende Shell zur Kommandoausführung benannt werden und mit MAILTO ist es möglich, die Ausgabe, die der cron per Mail an den Eigentümer der »crontab« ausliefert, einem anderen Benutzer zukommen zu lassen (oder gar zu unterdrücken »MAILTO=«).
  • Eine Anweisung besteht aus 7 Feldern (in den privaten Tabellen nur 6), wobei diese durch Leerzeichen oder Tabulatoren getrennt sind.
  • Die ersten 5 Felder betreffen die Angabe des Zeitpunkts, wann das Kommando zu starten ist:
Feld 1: Minute 0-59
Feld 2: Stunde 0-23
Feld 3: Tag 0-31
Feld 4: Monat 0-12, jan, feb, ..., dec
Feld 5: Wochentag 0-7, sun (entspricht 0 oder 7), mon, ..., sat
  • Jedes Feld erlaubt auch die Eingabe mehrerer Werte.
  • Die nachfolgende Tabelle fasst die verschiedenen Syntaxvarianten zusammen, die Beispiele beziehen sich auf Minuten:
Syntax Beispiel/Bemerkung
Voller Bereich * 0, 1, 2, ..., 59
Ausgewählte Bereiche 1-5 1, 2, 3, 4, 5
Liste 2,3,11,12 Nur an den angegebenen Werten
2,3,30-40 Kombination aus Liste und Bereich
Schrittweite */2 aller zwei Minuten (0, 2, ..., 58)
  • Tag, Wochentag und Monat können auch als englische Namen (die ersten drei Buchstaben) angegeben werden.
  • Klein- und Großschreibung werden dabei nicht unterschieden. Bereiche sind bei der Verwendung von Namen nicht erlaubt.
  • Die Datei »/etc/crontab« enthält nun als 6. Feld den Benutzer, in dessen Auftrag das Programm auszuführen ist.
  • Bei allen anderen Tabellen entfällt der Eintrag, da die enthaltenen Kommandos immer mit den Rechten des Eigentümers der Datei gestartet werden.
  • Das letzte Feld beinhaltet in jeder »crontab« das auszuführende Kommando.
  • Ein Prozentzeichen »%« kann benutzt werden, um einen Zeilenumbruch zu simulieren, alle folgenden Daten werden dem Kommando als Argumente übergeben.
  • Die Datei »/etc/crontab« könnte wie folgt ausschauen:
root@sonne> cat /etc/crontab
 SHELL=/bin/sh
 PATH=/usr/bin:/usr/sbin:/sbin:/bin:/usr/lib/news/bin
 MAILTO=root
 # Langwierige Jobs sollten besser Nachts ausgeführt werden...
 # Um 21.00 Uhr soll die Warteschlange der Faxe bearbeitet und geleert werden
  0 21 * * *    root  test -x /usr/sbin/faxqclean && /usr/sbin/faxqclean
 # Reports über das Faxgeschehen sind um 23.25 Uhr zu generieren
 25 23 * * *    root  test -e /usr/sbin/faxcron && sh /usr/sbin/faxcron | mail FaxMaster
 
 # check scripts in cron.hourly, cron.daily, cron.weekly and cron.monthly
 #
 # Das nächste Kommando soll aller 15 Minuten starten und nicht protokolliert werden
 -*/15 * * * *   root  test -x /usr/lib/cron/run-crons && /usr/lib/cron/run-crons
 # 0.00 Uhr jeden Tag
  0 0  * * *     root  rm -f /var/cron/lastrun/cron.daily
 # 0.00 Uhr jeden Sonntag
  0 0  * * 6     root  rm -f /var/cron/lastrun/cron.weekly
 # 0.00 Uhr jeden ersten Tag im Monat
  0 0  1 * *     root  rm -f /var/cron/lastrun/cron.monthly

Benutzereigene crontab

  • Bei all der Pingelichkeit mit der Sicherheit in einem Unix-System wird sich niemand darüber wundern, dass Otto-Normalverbraucher seine cron-Jobs nicht direkt in das entsprechende Spoolverzeichnis schreiben kann.
  • Aus diesem Grund steht ihm das Kommando crontab zur Verfügung.
  • Dem Systemadministrator steht es zu, die nachfolgenden Optionen mit -u Benutzer zu koppeln und somit die Datei eines beliebigen Benutzers zu bearbeiten.
  • Die simplen Optionen sind -l zur Anzeige des Inhalts seiner eigenen Tabelle und -r zum Löschen jener. Zum Editieren der Datei ist das Kommando mit der Option -e zu starten. Kommt jetzt die Ausgabe:
crontab -e
 You (user) are not allowed to use this program (crontab)
 Contact your sysadmin to change /var/cronallow or /var/crondeny
 See crontab(1) for more information

...so trete man seinem Systemadministrator entgegen und frage ihn, warum man von der Benutzung des Dienstes ausgeschlossen wurde.

  • Gesetzten Falls, der Aufruf glückte, so findet man sich in einem Editor wieder.
  • Welcher das ist, steht in den Shellvariablen $VISUAL und $EDITOR (nur wenn erstere nicht gesetzt ist, wird die 2. ausgewertet) und kann nach persönlichen Wünschen angepasst werden.

Übrigens scheitert ein Kommandoaufruf auch, wenn die Variable nicht oder auf einen nicht installierten Editor gesetzt ist.

Beispiel

  • Einmal pro Woche (Mittwoch) sollten wir ein Backup unseres Heimatverzeichnisses in Erwägung ziehen.
  • Wir archivieren also alle Dateien und schicken das Archiv per Mail an eine Adresse. Zusätzlich soll die normale Nachricht über die erfolgte Ausführung des Kommandos unterdrückt werden.
crontab -e
 MAIL=
 0 0 * * 3 tar czvf - /home/user | uuencode backup.tgz | mail user@outside.all -s "Backup"
  • Nach dem Abspeichern der Datei meldet crontab entweder den Vollzug »crontab: installing new crontab« oder aber einen aufgetretenen Fehler.
  • Wir provozieren einen solchen, indem wir einen Zeilenumbruch angeben:
crontab -e
 */30 14-16 * * 1-5 echo "Feier
 abend"
 Speichern der Datei
 ccrontab: installing new crontab
 "/tmp/crontab.2171":2: bad minute
 errors in crontab file, can't install.
 Do you want to retry the same edit?
  • crontab weist auf die mögliche Fehlerursache hin (Zeile 2:bad minute).
  • Klar, dass »abend« keine gültige Minutenangabe ist. Weiterhin verweigert das Kommando das Abspeichern der Datei und bietet ein erneutes Bearbeiten an.
  • Durch Eingabe von »y« gelangen wir zurück zum Editor.

Job zu bestimmter Zeit starten - at

at     [-V] [-q queue] [-f file] [-mldbv] ZEIT
  • Mit at lassen sich Kommandos zu einem späteren Zeitpunkt ausführen.
  • Der Zeitpunkt lässt sich in verschiedenen Formaten angeben:
17:23 17.23 Uhr des heutigen Tages
midnight 0.00 Uhr
noon 12.00 Uhr
teatime 16.00 Uhr
10:30pm 22.30 Uhr, mit dem Suffix am anstatt »pm« 10:30 Uhr
Am dieses Jahres, alternative Angaben sind und
Am , alternative Angaben sind und .
Zeitpunkt + Zeitspanne Als Zeitpunkt kann jede oben beschriebene Angabe stehen und now (»jetzt«), als Zeitspanne kommt ein Wert gefolgt von minutes (Minuten), hours (Stunden), days (Tage) und weeks (Wochen) in Frage.
tomorrow, today Spezifizieren den Zeitpunkt »Morgen« und »heute«.

at liest die zu startenden Kommandos von der Standardeingabe oder aus einer Datei, falls eine solche mit der Option "-f" angegeben wurde.

  • Alle Kommandos werden in eine Warteschlange eingereiht, deren Name aus einem einzelnen Buchstaben besteht. Die Voreinstellung "a" kann mit der Option "-q" überschrieben werden.
  • Die alphabetische Reihenfolge der Queues gibt die Priorität ihrer Bearbeitung vor.
  • Nach Beendigung eines Jobs versendet at die Ausgaben des Kommandos per Mail (sendmail muss installiert sein!) an den Auftraggeber.
  • Für Kommandos, die keine Ausgaben erzeugen, kann mit der Option "-m" eine Mail-Benachrichtigung über den erfolgten Abschluss der Bearbeitung erzwungen werden.
at teatime tomorrow
 at> echo "Wieder mal Feierabend"
 at> [Ctrl]-[D] <EOT>
 warning: commands will be executed using /bin/sh
 job 3 at 2000-06-07 16:00
 
 at now +30 weeks
 at> mail -s "Wunschliste" Weihnachtsmann@weissnicht.wo < liste.txt at> [Ctrl]-[D] <EOT>
 warning: commands will be executed using /bin/sh
job 5 at 2001-01-02 09:12

Start des Dämonen

  • Für die Bearbeitung der Jobs ist der at-Dämon atd verantwortlich, der bereits während des Systemstarts aktiviert werden sollte. Mit Hilfe des Kommandos ps sollte ein Zeichen des Geistes zu erhalten sein:
ps ax | grep atd
   232 ?        S      0:00 /usr/sbin/atd
   518 ?        S      0:00 /usr/sbin/rpc.rstatd
  4316 ?        S      0:00 /usr/sbin/rpc.kstatd
  1967 pts/8    S      0:00 grep atd
  • Fehlt eine den Dämonen betreffende Zeile, kann dieser von Hand gestartet werden.
  • Die interessanten Optionen sind hierbei -l Auslastungsfaktor und -b Sekunden. Der atd ist so ausgelegt, dass er einen Auftrag nur zur vereinbarten Zeit startet, wenn die Systemauslastung einen bestimmten Wert (0.8) unterschritten hat.
  • Ist das System zum Zeitpunkt zu beschäftigt, stellt der atd den Auftrag solange zurück, bis der Lastwert unter die Schranke gefallen ist.
  • Mit ersterer Option kann ein anderer als der voreingestellte Wert vereinbart werden, dies ist bei Mehrprozessorsystemen zu empfehlen.
  • Die momentane Auslastung ermittelt der Dämon anhand der Datei »/proc/loadavg«. Mit der zweiten genannten Option kann das Zeitintervall variiert werden, in dem der atd die Auftragswarteschlangen nach fälligen Jobs durchsucht. Voreinstellung ist 60 Sekunden.
  • Um den Dämonen schließlich nicht immer von Hand starten zu müssen, sollten Sie einen Link in allen Runleveln auf ein entsprechendes Skript anlegen.
  • Bei den meisten Distributionen sollte das Skript »at« heißen und im Verzeichnis unterhalb der Runlevel liegen.* Debian und RedHat: Verzeichnis /etc/rc.d/init.d

Zugangskontrolle

  • Der Zugang zum Dienst kann vom Systemverwalter eingeschränkt werden, in dem er die Benutzerkennzeichen in einer der Dateien »/etc/at.allow« oder »/etc/at.deny« aufnimmt.
  • Dabei wird die zweite Datei nur ausgewertet, falls erstere fehlt. In »at.allow« trägt Root genau die Benutzer ein, die den Dienst beanspruchen dürfen.
  • Nichterwähnte Benutzer werden somit ausgeschlossen.
  • Sollen jedoch nur einige wenige Personen ausgenommen werden, so ist es einfacher, diese in der Datei »at.deny« einzutragen.
  • Alle dort nicht benannten Benutzer haben dann Zugriff auf at. Existiert keine Datei, ist der Dienst für jeden nutzbar.

Jobliste anzeigen (atq)

atq     [-V] [-q queue]
  • Der Inhalt der Warteschlange ausstehender at-Jobs wird angezeigt.
  • Sollen nur die Aufträge einer bestimmten Queue betrachtet werden, muss mit der Option "-q" der Name der Warteschlange angegeben werden.
atq
 1 2000-06-06 16:00 a
 3 2000-06-07 16:00 a
 4 2001-01-02 09:07 a
 5 2001-01-02 09:12 a
 6 2000-06-11 10:16 b
  • Die Informationen sind Jobnummer, Zeitpunkt des Auftrags und Name der Warteschlange. Eine analoge Ausgabe liefert at -l.

Job abbrechen (atrm)

atrm    [-V] job [job...]
  • Aufträge können anhand ihrer Jobnummer gelöscht werden:
atrm 3 4 5 6
 atq
 1 2000-06-06 16:00 a

at -r arbeitet analog.

Job bei Inaktivität mit batch starten

batch    [-V] [-q queue] [-f file] [-mv] [ZEIT]

Batch arbeitet analog zum Kommando at mit dem einzigen Unterschied, dass batch den Start des Kommandos soweit zurückstellt, bis die Auslastung des Systems eine gewisse Grenze (load average < 0.8) unterschritten hat.

  • Das Kommando wird man bspw. dazu benutzen, eine langwierige und ressourcenintensive Berechnung erst nach Feierabend zu starten (wenn normalerweise die Rechner nicht mehr benötigt werden).
  • Sollte aber dennoch ein Kollege Überstunden scheffeln (das soll es wohl geben;-) und den Rechner benutzen, wird die Bearbeitung des Jobs zurückgestellt...
  • Verwendung und Optionen des Kommandos sind exakt wie bei at beschrieben.
Abgerufen von „https://wiki.foxtom.de/index.php?title=Linux/Prozesse&oldid=71614“